Introduction
Application container technology has emerged as a mainstream solution in recent years — in fact, it is now approaching $1B in annual revenue. Naturally, with the spike in popularity and adoption comes a corresponding rise in container-related cyberattacks, making containerization security a critical factor in enterprise adoption. In this whitepaper, we explore the challenges associated with container security, as well as best practices for mitigating risks and overcoming those challenges.
Mastering Container Security
In 2020, Gartner projected the growth of container software and services to escalate from a modest base of $465.8 million in 2020 to a robust $944 million by 2024. That same year, Forrester anticipated the adoption of containers to surge from 33% in 2019 to 58% within the following 12 months, raising questions about how security would keep pace. As the adoption of images and containers steadily increases to meet the demands of scalability and agility, organizations face new challenges in securing them. These challenges cannot be addressed using traditional tools and techniques designed for virtual machines and host platforms.
Recent research by RedHat, published April of 2023, reveals that "67% of companies have delayed or slowed down deployment due to a security issue." The study also highlights that security vulnerabilities and systems misconfiguration are the leading security concerns with container and Kubernetes environments. If an organization's digital business and ecosystem heavily rely on running hundreds to thousands of containers and images, managing them and their security can be a complex but crucial part of ensuring security.
Securing containers presents unique challenges
- Containers are stateless and temporary. That means the traditional security tools to detect and identify vulnerabilities and monitor security health will not work reliably.
- Container images stored in the world's largest library, public registry and community — Docker Hub — may contain malicious content or files. An image can contain plain-text passwords or private keys that allow one app component to connect with another. However, anyone with access to the image can find the secret and use it for malicious activities.
- Images can be patched but running containers cannot. An insecure runtime configuration may turn a running container into a drift container, which may allow privilege escalation or container escape. The only way to patch vulnerable containers is to first stop them, run a scan on the image, fix the image and then execute a docker run on the image to run the container.
- Container hosts running the docker daemon may contain package vulnerabilities at the operating system level and configuration flaws that can be exploited.
- Containerized applications may be vulnerable to software flaws, just like traditional web applications.
To implement a layered approach to container security, it's important to understand the lifecycle management of a container. Every application container can exist only in these three phases
| Build | Transfer/Store | Run |
|---|---|---|
| iDeveloper builds the application container image at the time of docker build. | Transfer to Registry/Store in public/private registry at the time of docker pull/push. | Run the container at the time of and after the docker run. |
| Pre-deployment | Post-deployment |
Build Phase
- Maintain an inventory of images
Identifying container hosts with images helps maintain visibility into containerized projects. The security tool should be capable of searching images and containers based on vulnerabilities and misconfigurations. Examples of valid cases for deep diving into image visibility include "container in a specific cluster/master node/namespace," "rogue images running in production," "image in an unprotected private/public registry," "host inventory" and "hosts running without any monitoring control."
- Integrate security into the CI pipeline to scan vulnerabilities in images
A DevSecOps-enabled "shift-left" approach should help developers identify vulnerabilities at an early phase of the SDLC. At a later level of DevSecOps maturity, vulnerable images should be blocked from making their way to production by "failing builds" and not allowing insecure images.
- Use tool capability for sensor/agent deployment on the container engine host
Commercial security tools have the advantage of sensor/agent deployment on host platforms that not only helps with automated discovery of images but also runs static vulnerability scans on images. The compatibility of the security tool within the containerized orchestration environment is always a dependency that needs to be evaluated before procuring the tool.
Transfer/Store Phase
| Regular registry scan | Maintain registry hygiene |
|---|---|
| Over time, the set of images stored in public/private registries can include out-of-date versions. There is a risk of accidentally deploying a known-vulnerable version, which, if exploited, may lead to severe consequences. Registry scanning helps maintain the visibility of the "security state" of images, ensuring proper registry hygiene and that only compliant and secure images are retained in the registry. Scanning can be on-demand or scheduled. | Registry hygiene is an absolute requirement for successful "Application Container Security Posture Management (ACoSPM)." Only secure images should be stored in Public/Private Registries. Out-of-date versions can be removed from the registry. Commercial security tools help by deploying their sensors and agents in hosts that have access to registries. |
Run Phase
- Enable container runtime security
Various aspects are necessary to ensure runtime security, such as avoiding container drift, running containers with minimal permissions with namespaces, file integrity monitoring, image integrity verification, monitoring container events and monitoring and blocking traffic. The behavioral enforcement for running the containers is done by the process of Instrumentation. At an extra cost, this feature is available in commercialized security tools.
- Apply runtime security policy
Some commercialized security tools have an inbuilt feature to apply a security policy to an image to enforce certain behavioral restrictions to secure the container. These can be inbound-outbound network rules, file accessibility/execution by a program or system calls to preserve files.
- Host-level assessment
Policy compliance scans and CIS benchmark scans tailored to the infrastructure standards of an organization are always needed to secure the hosts supporting the container engines and orchestration tools.
Additional considerations
Adequate security tool
To secure the container lifecycle, a security tool needs to first be evaluated in the organization's test environment to identify dependencies and compatibility with the orchestration tool stack. It's important to determine the value the tool brings so that it can justify the procurement of the license and its additional features.
Adequate skillset
As containers and their security aspects are complex, Security analysts should be hired based on their experience in handling false positives rather than the number of vulnerability management scans completed.
Conclusion
With many large organizations today running hundreds and often thousands of containers and images, managing enterprise security is both complex and critical. The first step is understanding the most common risk factors associated with containerization, as well as strategies for container lifecycle management. We explored cybersecurity best practices for each phase of the lifecycle: build, transfer/store and run. And finally, we examined the tools and human skillsets needed to ensure the stability, security and scalability today's enterprises demand.
References
- Revenue Growth for Container Management Software, Gartner, 2020
- Container Adoption Is On The Rise: How Can Security Keep Up? Forrester, 2020
- Kubernetes Adoption, Security, and Market Trends Repo 2023, Red Hat, April 2023
