This is the continuation of container security: Part 1, in this post we are going to discuss about container runtime protection.
Container runtime protection is key security control because this is where “rubber meets the road”. Container will be serving critical workloads and processing sensitive data. Below are the areas we will exploring in this post
- Container runtime threat detection
- Logging and monitoring
- Secrets management
- Access control
- Workload isolation
- Container networking
Container runtime threat detection
Getting visibility into container and host environment is crucial to detect threats within container. For e.g. malicious container will try to access sensitive files such as /etc/passwd once gets foothold or tries to privilege escalate and laterally move to other containers of the cluster or outside of the cluster. so auditing the activities is key to identify the suspicious behaviour.
Some of the software can help to achieve this control objective which is also container aware:
- Sysdig
- Aquasec
- Twistlock
- Amazon Guardduty
Secrets Management
Containers needs to connect other resource which requires secret e.g. database or API secrets.
containers are immutable and short-lived so it’s challenging to inject secrets in runtime environment. Some of the secret management solutions are Amazon secrets manager or Azure Key vault or Hashicorp vault which can work with orchestrator to inject the secrets in runtime. For e.g. AWS provider of secrets store CSI driver allows to integrate kubernetes and secrets manager to be available in the run-time environment.
Access Control
Access control mainly driven by two scenarios – who can have access to cluster to deploy containers and what container can access ?
For the access to the cluster – Enforce access control who can deploy the containers into a runtime environment. Kubernetes RBAC control allowing only certain principles to deploy authorised container.
For the container to access outside resource – Follow least privilege access containers should have limited access to do the job.
Workload isolation
In containers world, isolations are provided by Linux namespace which is not hardened enough. To secure container workloads further, isolate the sensitive workloads into separate virtual machines. For e.g. internet facing containers should be hosted into separate worker nodes from other container workloads.
The thinking behind is internet facing containers are prone to be exploited by bad actors frequently so getting foothold of internet facing containers shouldn’t give easy access to data store containers.
Container networking
By default, traffic between the containers in a cluster is allowed without any restrictions. So it requires policy enforcement engine (PEP) to enforce the traffic between the containers for e.g. Calico container networking interface also known as CNI provides that functionality to restrict traffic between containers. Traffic outside of the cluster requires some container aware firewall management software.
Conclusion
Operating and securing container workloads is a challenge for many organisation but there are some container aware software tools help to protect the container workloads. However, before spending big on containers consider risk-based and threat modelling approach to introducing controls in the environment and measure the impact.