The security of your information and infrastructure is mostly decided by your actions, even in the cloud. As containers require a different security model to traditional VMs, we will look at some key areas where making the right choices will help support security in your system architecture.
As containers make it easy to encapsulate an application’s runtime requirements, it is possible to keep a container platform’s operating system extremely thin. So called Atomic Linux distributions are one implementation of this idea, using a read-only filesystem, transactional updates and a ‘git like’ os-tree model to provide security and scalability whilst providing the smallest possible surface of attack. With the immutable os-tree filesystem model, it is also possible to roll back directly to a previous system version if required. These characteristics make Atomic systems extremely well suited to be used in large scale Kubernetes distributions to ensure parity of state across nodes. Google itself takes a different approach to container operating systems with their “Container Optimised OS”, based on Chromium, but many of the key features echo Atomic distributions.
Docker is currently the most widely used implementation of container technology, but it comes with a significant downside: it requires a daemon to be running for containers to run. The obvious downside of this architecture is that stopping the daemon will stop all running containers, but there are more subtle issues to consider as well. It is not possible to start containers before the daemon process is running, so you cannot have init containers; containers are descendents of the docker engine and not the docker cli, so cgroups applied to the docker cli will not be inherited by the container, and the parent PID of the container will be the daemon, not the cli. The good news is that any Kubernetes based container orchestration platform has the Container Runtime Interface abstraction, allowing you to use different container runtimes.
One of the most well known runtimes is Gvisor from Google, which takes a similar security approach as User Mode Linux. Gvisor acts as a guest kernel and intercepts system calls, either executing a user space implementation or blocking them. Other notable runtime interfaces are: Frakti - which allows you to use Kata containers, launching a lightweight vm around your pod, isolated completely from the underlying system, and Virtlet - which allows the provisioning of full VM’s on Kubernetes nodes. There are, of course, trade offs around speed or ease of use in each solution that you will need to assess for your use case.
Kubernetes API Objects
If you are using Kubernetes to orchestrate your containers, you have the possibility to use both Role Based Access Control (RBAC) and the ResourceQuota and LimitRange API objects to ensure security and stability.RBAC allows you to define what operations (verbs) different subjects (users or groups) can take on resources (api objects) in the cluster, and it is also possible to implement custom admission webhooks to either provide additional access control or mutate the incoming API requests. ResourceQuotas and LimitRanges allow you to specify the amount of CPU and RAM a namespace/pod/container must be allocated to be scheduled or is allowed to consume, ensuring that containers get the resources they need to run and do not starve others.
Although the concerns around running containers are different from those of traditional servers, there are sensible choices you can make in each layer of your architecture to help ensure security. These concerns remain regardless of running your container on-premises or in the cloud and as always security is most heavily dependent on your application design.
You would like to hear more from us?
This article was also published in the Netzwoche-Special «Cloud & Managed Services 2019»