Containers are transforming how enterprises deploy and use applications. In traditional virtualization, the server runs a hypervisor, and then virtual machines with entire guest operating systems and software run on top of the hypervisor. They allow more versatility than traditional physical servers since they simplify management and provide faster provisioning of applications and resources, but they still have significant limitations. The files are large, often on the scale of multiple gigabytes. They’re not very portable.
This leads me to two of the biggest draws of containers: increased efficiency and portability. With containers, you can run software without worrying about operating systems or dependencies. An operating system runs underneath the containerization platform. Then, instead of having to build a production environment with the right settings and libraries, the container already has that build in. Because containers do not depend on the underlying OS, they are more portable than traditional virtual machines. You do not have to package the container with an entire OS: the files you need to run an instance add up to mere megabytes, not gigabytes.
Common Container Security Risks
However, as with any exciting new technology, there are inevitably security risks that come along with it. That doesn’t mean avoiding containers. Instead, by keeping the risks and container security best practices in mind, you can protect your business while gaining the benefits. As you plan how to adopt and expand containers in your environment, here’s what to keep in mind.
As with isolation between instances in traditional virtualization, the isolation between containers helps make them attractive from a security standpoint. However, isolation capabilities do not make containers safe by default: there is a level of risk. After all, just like your security team, attackers also know that finding a container escape flaw in the platform can grant access to sensitive data in other containers.
Also remember to consider isolation from a network perspective. Despite the fact that modern containerization platforms offer network segmentation, real-world implementations of container platforms often do not take advantage of those network segmentation features. Security teams may assume the containers are secure enough by default. But without network segmentation, it becomes a lot easier for an attacker to traverse from one compromised container to other vulnerable ones on the same network.
Containers are attractive because they are so portable and so easy to set up. We are seeing that attackers are leveraging these features of containers to get into environments. Attackers will create their own malware-laden containers and upload them to public repositories such as Docker Hub. Before running containers, your team will need to consider the source and assess the security of a container to make sure you are running trustworthy software and not giving data thieves or crypto miners an invitation to your network.
Insecure Configuration of Other Components
Apart from the security of individual containers, you must also consider the other components in the environment. You must update and securely configure the host OS, harden the containerization layers and any orchestration software, and configure accounts based on the principles of least privilege. After all, not only can machines running containers be vulnerable to OS-level attacks, but real-world attackers are already focusing on insecurely configured containerization layers.
Financially motivated attackers, in particular, have seen the opportunities. Here are a couple recent examples. Last year a cryptocurrency mining group looked for Docker instances that allowed Docker commands to be run without a password. The attackers then ran commands to make Docker set up an Ubuntu Linux container that they could then use to turn off security features, stop any competing cryptomining ransomware, and run Kinsing. Kinsing is a strain of cryptomining malware that also has the ability to steal credentials and keys, look through previously run commands, and identify other vulnerable machines on the network. Earlier in 2021, another cryptocurrency-mining group was identified that was looking for open Docker management ports and stealing API keys in order to put malware in Docker containers. Both of these examples underline the importance of proper configuration.
Just as with traditional computing and OS-level virtualization, securing and protecting secrets remains a prime security concern when using containers. In the context of containers, you need to think about protecting sensitive information such as credentials, API keys, and tokens at every level: the containerization platform, orchestration platforms like Kubernetes, and the content of individual containers.
Secret management flaws can emerge in many ways. Developers may hard-code credentials in scripts placed in containers. Secrets may be saved in an insecurely configured key management system. They not be rotated regularly. Any of these kinds of flaws could lead to an attacker gaining access to things they shouldn’t, or being able to cause a more extensive or expensive consequence than they could have otherwise.
Securing Your Container Environment
So, how can you stay secure while taking advantage of the portability and flexibility of containers? I recommend the following steps as a starting point.
Hardening a Container Environment
The first step is to assess what containers your business is using. Ensure that your environment is only using trusted containers from known sources. Next, accurately document all containers in the environment. This can be a challenge, due to how easy containers are to set up and how portable they are. But like any physical assets, knowing your attack surface is a fundamental step toward keeping the network secure. Furthermore, ensure that containers are on properly segmented networks. Even if you are taking every precaution with container security, segmenting containers at the network layer can help mitigate the effects of a compromise in a single container.
Configuration and patching also matter, both in containers and the systems underlying them. Host operating systems should be configured securely and patched regularly, as should the containerization layer. Containers should also be part of the patching schedule. Containers are immutable objects, so software updates take the form of replacing the previous version with an updated one. Those updates are equally important to traditional software updates.
Both the foundation layers that the container sits on as well as the container itself require ongoing monitoring and regular security testing. Even the most knowledgeable and security-conscious businesses can benefit from penetration testing. Even in environments where knowledgeable security teams have taken pains to secure container infrastructure at every level, a small misconfiguration in security policy can lead to a complete compromise of a container environment. With so much at stake, I can’t emphasize enough the prioritization of regular penetration testing.
Additional Resources for Container Security Best Practices
Though containers are a relatively new technology, enough enterprises have adopted them that trusted sources publish hardening guidance for container infrastructure. This includes CIS, which publishes security benchmarks for both Docker and Kubernetes, as well as OWASP, which has released a Docker security cheat sheet. You can use these to help develop your baseline for checking or planning container environments.
Your Partner in Container Security
For many organizations, containers and container security are something of a new frontier. There is some guidance out there on best practices, but there are still many unknowns, and, rightfully so, questions about the secure deployment of containers. It’s an important topic, and one the team at Kroll, including myself, have been digging into and researching for years now with the goal of helping enterprises make the most of the technology.
Our team has a deep bench of penetration testers who not only have broad-based penetration testing experience but are experienced with both using and testing container technologies like Docker and Kubernetes. If you’re interested in talking to a consultant about how to strengthen your container security, our team would be glad to help. Contact our team here.