Over the last five years, the use of containers and container orchestration tools has grown prodigiously. Driven by popular tools such as Docker and Kubernetes, containerized workflows have become commonplace across many organizations.
With this rapid evolution, there is a risk of getting lost in the blizzard of buzzwords and overlooking key security risks, as well as possible security solutions.
Here are container security best practices that will keep your applications more cyber resilient, plus what your team needs to know about container orchestration and tools.
What is a container, really?
An important thing to realize about containers is that, from the perspective of the operating system, they’re just programs like any others running on the host. One of the reasons that using Docker to run applications has low performance overhead, compared to running them in a traditional virtual machine architecture, is that Docker leverages existing operating system features to provide isolation.
The trade-off for leveraging operating system features for isolation is that, from a security standpoint, Docker is essentially command execution as a service. This, combined with its flexible security model, means that allowing access to Docker on a host is the same as allowing root access, which can be demonstrated using "the most pointless Docker command ever." Running the command below with Docker access will just land you in a root shell on the host.
Looking at this command in detail illustrates how Docker uses Linux’s facilities to create its isolation:
docker run -ti
--privileged
--net=host --pid=host --ipc=host
--volume /:/host
busybox
chroot /host
The first notable point is the use of the --privileged switch. This essentially removes most of Docker’s isolation and security controls, which restrict what a process running in a container can do. Then the next line (--net=host --pid=host --ipc=host) provides direct access to the host’s resources, unlike the namespaced version that Docker usually provides. The last set of parameters mounts the host’s root filesystem inside the container, and the last line uses the standard chroot command to switch to that directory. The net effect of all this is you get a full root shell on the host.
Once you know how Docker works, it’s perfectly possible to create a security model for it. For development machines, assuming you usually provide developers with root access, there’s no real security impact, but for test or production systems, it’s important to restrict which users have direct access to run Docker commands.
Add container orchestration to the mix
Of course, in production, most organizations will make use of a container orchestration system to provide additional services that help containers scale to meet their requirements, and the most common of these systems is Kubernetes.
The first thing to note about Kubernetes is that, in most cases, it runs on top of Docker or something that provides similar facilities and works in a similar fashion. That means that, by default, anyone who can create containers can do exactly what the most pointless Docker command does and get root access to the nodes in your Kubernetes cluster. And of course, given that Kubernetes lets you deploy containers to large numbers of machines with one command, it’s possible to create a manifest command (such as this one) that automates the process, allowing root access to many nodes at the same time.
Obviously, this shows up as one of the key areas of Kubernetes security that require focus. It is critical to make sure that any user with rights to create containers in the cluster is not able to gain full access to the underlying machines. The landscape is currently shifting to address this issue. Traditionally, a Kubernetes feature called Pod Security Policy was used to implement the necessary restrictions, but this feature has recently been deprecated, so cluster operators have a range of choices for implementing this class of control.
A planned in-built option will work for straightforward use cases, and for more complex requirements a range of projects, both open source and commercial, can be used to help restrict access for containers deployed to Kubernetes clusters. From the open-source perspective, OPA and Kyverno are the most prominent, and on the commercial side, container security companies should be able to provide this kind of functionality as part of their suites.
Manage user access in Kubernetes
A key difference between single-user systems such as Docker and container orchestrators is the need for multi-user controls such as authentication and authorization. So when adopting Kubernetes, it’s important to understand how this operates.
The first key element to understand about multi-user controls for container orchestrators is that the in-built Kubernetes authentication options are not suitable for production clusters. This means that add-ons, either from the cloud or external services, will be required. Kubernetes does provide client certificate authentication out of the box, but it should be avoided because it does not support revocation of the credentials issued via this method.
Another reason why, when using Kubernetes, you’ll need an external user management/authentication system is that Kubernetes doesn’t have a user database. While the RBAC system provides rights to the various objects in Kubernetes, there’s no in-built record of the users in the system, so external services are needed to ensure that a user database is maintained correctly.
Get up to speed on container security tools
Containers and container orchestration are powerful tools to help scale and automate application deployments, but they require careful consideration from a security standpoint. Getting the controls early in your container journey will make it much smoother and reduce the risk of attackers using your scalable command execution environment against you.
While we’ve touched on some key points and potential surprises in the container security world, there’s a wide array of topics that you should consider as part of your path to adoption. Luckily, there are also plenty of places to get additional information.
If you work in an industry where security compliance standards are important, then the CIS benchmarks are a good place to start. There are CIS benchmarks for both Docker and several distributions of Kubernetes, including Kubeadm, GKE, AKS, and EKS.
As for books, there are good options for Container Security and Kubernetes security, and if you prefer videos, there’s a wide array of options on the CNCF YouTube channel, since they make all the content from Kubecon conferences available a week after the event.
Lastly, it’s worth noting that Kubernetes has a strong open-source community, and one of the best ways to learn more about it is to participate in the project. Kubernetes has a special interest group for security that meets regularly, and there’s also a CNCF Technical Advisory Group for Security, which discusses security in the wider cloud-native world.
Keep learning
The future is security as code. Find out how DevSecOps gets you there with TechBeacon's Guide. Plus: See the SANS DevSecOps survey report for key insights for practitioners.
Get up to speed fast on the state of app sec testing with TechBeacon's Guide. Plus: Get Gartner's 2021 Magic Quadrant for AST.
Get a handle on the app sec tools landscape with TechBeacon's Guide to Application Security Tools 2021.
Download the free The Forrester Wave for Static Application Security Testing. Plus: Learn how a SAST-DAST combo can boost your security in this Webinar.
Understand the five reasons why API security needs access management.
Learn how to build an app sec strategy for the next decade, and spend a day in the life of an application security developer.
Build a modern app sec foundation with TechBeacon's Guide.
