Container Security – A New Frontier (Part 2)

A two-part blog series on considerations for keeping container use secure.

Container security, with a new dimension

We have outlined the security challenges that containers can present in our first blog post. This leaves us with questions about how we should think about container security. 

We feel we should start with (and build upon) Kubernetes' advice of using a layered, defense-in-depth approach that accounts for four C’s: cloud, clusters, containers, and code. We also feel we should consider how to contain threats that compromise containers, done by segmentation.

This being the case, we propose containment as a fifth C. 

We discussed previously the need to not only secure the containers but ensure they could not be exploited and used as a beachhead to move laterally inside a data center. That is where the need for containment comes into play. 

Let’s examine initial Kubernetes guidance on the 4 C’s and then we’ll discuss containment.

Containers

To run software in Kubernetes, it must be in a container. Because of this, there are certain general security considerations Kubernetes outlines:

• Scan: Scan your containers for known vulnerabilities. Tools like with CoreOS’s Clair can be helpful.
• Sign container images: Maintain trust for the container content using Docker Content Trust, built into the Docker Engine. IBM’s Portieris project can be used as an admission controller for enforcing content trust for properly signed images.
• Control user privileges: Seek to create users inside of the containers that have the least level of operating system privilege necessary in order to carry out the goal of the container. 

Code

Examining the application code level, Kubernetes guidance hits on a few points:

• Allow access over TLS only: Make default encrypting everything in transit, even between network services behind the firewall.
• Limit port ranges of communication: Only expose the ports on your service that are absolutely essential.
• Analyze static code: Analyze code for any potentially unsafe coding practices.
• Test for dynamic probing attacks: Use OWASP tools to automate common attacks like SQL injection, CSRF, etc.

Cloud

Each cloud provider provides extensive recommendations on how to run container workloads on their cloud infrastructure. Security offerings may be different for different cloud providers and users must be meticulous in following these recommendations. Links to popular cloud providers and security recommendations are found in https://kubernetes.io/docs/concepts/security/#the-4c-s-of-cloud-native-security.

General guidance includes:

• Restrict network access: Most cloud security providers provide network security using access control lists – for example, AWS provides security groups which allow workloads to be segmented into groups and allows ACLs to be configured per group.
• Restrict API access: Ideally, only the servers required to administer a cluster should have access to API servers.
• Restrict access to Kubernetes cluster APIs: It is best to provide the cluster with cloud provider access that follows the principle of least privilege for the resources it needs to administer. An example for Kops in AWS can be found here: https://github.com/kubernetes/kops/blob/master/docs/iam_roles.md#iam-roles.
• Restrict access to ‘etcd’: This directory is where the cloud configuration files for Kubernetes exist. Always use TLS to access and make modifications to these files.
• Encrypt all drives especially etcd drives: Stop unauthorized users from viewing critical configuration files and data stores belonging to your Kubernetes cluster.

Clusters

• Restrict access to the Kubernetes API to the cluster using RBAC.
• Authenticate all access to the API that controls the cluster.
• Encrypt all secret keys used by the cluster including all data in etcd.
• Control security aspects of pods: Pod security objects define a set of conditions that a pod must run with in order to be accepted into the system.
• Control resource utilization: The Kubernetes nodes that run your application depend on each other for reliability and resource balancing. So, there should be policies that restrict the amount of resources used by these nodes.
• Control all network policies to pods using access control lists. This is North-South security policies. For intra-data center policies, see Containment below.
• Restrict all ingress access to be over TLS.

Containment

This brings us to the fifth C of containment that prevents the spread of breaches that are initiated from a container. Containment should account for a few things for it to be its most effective:

• Discover containers that are newly created in real time.
• Allow for automated segmentation for new container workloads so security is automatically present "at birth."
• Centralize visibility of containers alongside other compute environments for a single view across containerized workloads and bare-metal, virtual machines, private and public cloud – because you can’t protect what you can’t see.
• Enforce uniform policy across containers – and everything else – so you segment with unified policy, regardless of the environment. This avoids multiple point tools for segmentation for VMs, bare-metal servers, clouds, and containers.

With a broad defense-in-depth approach for containers, organizations can be assured of the security viability of containers to deploy them with even greater confidence.