What is containerization?
Containerization technologies share a computer kernel in order to run one or more applications. Each app includes – or “contains” – its own libraries and dependencies, which enables environmental agnosticism. Environmental agnosticism means that a container works without the need to manage each application’s dependencies on a specific operating system on the local host. Dependencies such as conflicting software versions or installed libraries plague developers and users alike, but they no longer pose an issue with containerization.
Docker is the most common containerization software. Other examples include Microsoft Hyper-V™ and Windows™ containers, Podman, and OpenVZ or cloud container services such as Amazon Elastic Container Service or Microsoft Azure Container Instances™.
Technologies in context
Many technologies form crucial links in the container security chain, including container image registries and continuous integration and continuous development pipelines. Container clusters are another approach, and they’re typically managed through container orchestration technologies such as Kubernetes or Docker Swarm, which automate deployment, scaling, and management of containerized applications.
Security integration points are another link in the container security chain. They act as checks and balances along the journey from development to production and help guard against attacks all along the supply chain. Admission checks, policy enforcement, runtime checks such as state analysis, manifest scanning engines, infrastructure-as-code (IaC) checks in the integrated development environment, and privilege management are all critical pieces of the puzzle.
Why container security is critical
While containerization can increase efficiency, it also can increase risk. Container technologies can be exploited to gain access to the host running the containers, which can expose entire organizations. But the presence of security risks does not mean containers should be discarded entirely. Like any other technology, containerization and its risks can be understood and managed effectively.
Container system administrators and DevSecOps teams can use open-source tools to evaluate and tighten security controls. At the same time, investing in cybersecurity assessments and penetration testing is an invaluable way to identify weaknesses and potential attack vectors. Doing so can help organizations better understand and mitigate risks associated with containers.
The ins and outs of container security
So what should system administrators focus on, potentially even before bringing in third-party specialists? Container-specific security details that system administrators should be aware of when implementing containers in their environment include:
- Least privilege access management. This aspect of securing technologies is often missed or misconfigured, which holds true for containerization. To apply least privilege specifically to containers, system administrators should:
- Restrict root access.
- Because containers share a kernel with the host operating system, any attacker that can gain root access within a misconfigured container will be able to directly affect the host.
- System administrators should avoid running containers as the root user and instead use a service account user with the minimum privileges necessary to run containers.
- Root access within a container should be treated as if it were root access on the container host.
- Protect the container platform’s application programming interface (API) sockets.
- An attacker can easily use access to the API to arbitrarily access and run commands on both the host and containers. Access should not be given to containers nor to any users other than root users unless absolutely necessary.
- Avoid installing or running any extraneous services.
- Libraries on deployed container images can allow an attacker to use one application to gain access to another and might introduce additional vulnerabilities.
- Resource management. System administrators should manage the risk of denial-of-service attacks by limiting resources such as memory, central processing units, and the number of processes available to a container in order to prevent attackers from maximizing resource usage and disabling the host.
- Network segmentation. Enforcing network segmentation by limiting or disabling intercontainer communication can hinder an attacker’s ability to move laterally between containers.
- Secret management. Secrets should be secured by encrypting passwords, API tokens, certificates, and private keys. An orchestration vault or cloud solution for secure access management, storage, transmission, and rotation can be used to manage secrets.
- Supply chain management. An IaC linter can help inspect image misconfigurations that might expose sensitive information. Examples include Buddy.Works, RedCoolBeans, and Hadolint. Containers should be run with a read-only file system when possible in order to prevent an attacker from compromising the integrity of the file system within a container or from establishing persistence. Only tested, approved, and signed images from trusted sources that verify integrity in transit and in use should be installed. Vulnerable source containers affect the entire platform either through human error or through malicious changes, so system administrators should regularly scan, encrypt, and use HTTPS for transfers for container images to prevent tampering.
- Image hardening. The default security profile for containers should not be disabled. System administrators might consider creating a security profile for each container using Linux’s secure computing mode (seccomp), AppArmor, or SELinux modules. Code should be run in containers only if it was present when the image was built and if the image that was scanned in the vulnerability management process is the same code that is executing in deployment. If code is being updated, the container should be rebuilt with the updated code and then redeployed.
- Logging and monitoring. Logging and monitoring can provide audit trails and can identify security incidents to minimize attacker dwell time, so system administrators should make sure applications have access logging enabled.
- Patch and vulnerability management. All software – both on the host and within the containers – must be kept up to date to protect against known vulnerabilities. Using tagged container images can assist with version control.
- Behavioral analytics. Behavioral analytics tools such as Falco can help identify dynamic security flaws and risks on running containers.
Getting proactive about container security
Containerization is an attractive option for deploying applications, thanks to container portability and resource efficiency, but it also can create an additional attack surface. Attacks against containers have become increasingly common as containerization becomes mainstream. Organizations should incorporate container security best practices to properly secure this technology and protect their assets.
