An Introduction to Container Risks and Security Issues
Keep reading for a breakdown of common container security issues, why they can be challenging to secure, vulnerabilities to look out for, and more.
While undoubtedly powerful, containers present security and compliance risks. Due to their complexity, container environments are more challenging to secure than traditional infrastructure.
This article discusses some common container security issues, the consequences of weak security, and known areas of vulnerability to help you understand how to build secure and compliant containers.
Why Are Containers Challenging to Secure?
There are several reasons why securing containers can present unique challenges, including:
Containers are less familiar to traditional companies that still use on-prem technology and have lower availability of skills compared to older technologies.
Container technologies come with no out-of-the-box security and require significant hardening.
Environments can be highly complex and fast-paced.
There are few container standards, making it challenging to compare technologies objectively.
Compliance frameworks don’t provide prescriptive security controls for container environments.
According to the Portworx 2021 Kubernetes Adoption Survey, security is the number one challenge faced by organizations adopting and using containers—and the top missing skill.
The Consequences of Poor Security
Profit is the objective of most cyberattacks. It’s a primary motivator in 96% of breaches, according to Verizon’s 2022 Data Breach Investigations Report. So, where’s the profit in attacking a container?
Data Theft
The old favorite—personal, financial, and health data is valuable, so criminals are always looking for ways to obtain it. Containers often hold, process, and/or transmit data to and from databases, making them an ideal target.
Ransom Payments
Like any IT system, container environments are susceptible to ransomware and denial of service (DoS) attacks. And, since these environments are often mission-critical—and may access or hold sensitive data—that makes them an ideal vehicle for extortion.
Cryptomining
Cryptomining malware can be snuck into widely used container images or run secretly inside malicious containers if the orchestration platform is compromised. This grants attackers unrestricted access to valuable computing resources.
Cryptomining is No Joke A 2022 Sysdig report found that every dollar an attacker earns from a cryptomining attack in a container environment costs the affected organization $53. |
Poor container security puts your organization at risk of serious security incidents, data breaches, and costly and disruptive ransom scenarios. It can also seriously harm your container strategy's performance and cost profile.
Inadequate Compliance
And there’s another risk: failed compliance audits. Many cloud-first organizations depend on certifications and attestations to prove their commitment to security, not to mention any regulatory obligations.
Failed or unsatisfactory audits are time-consuming and resource-intensive to resolve. They can cost tens of thousands of additional dollars even for non-regulatory frameworks like SOC 2 and ISO 27001.
Meanwhile, the cost of failing to comply with data protection regulations like GDPR, PCI-DSS, and HIPAA is over 2.7 times higher than the cost of compliance and can run to millions of dollars. This figure considers the costs of disruption, lost revenue, productivity losses, and any penalties or settlements.
Where Are Container Environments Vulnerable?
The image below shows a typical worker node. Even in this simplified diagram, it’s apparent that container environments are far from simple. They include several components that are prone to security issues.
In a typical container environment, there are at least seven sources of vulnerabilities:
1. Orchestration Platform
Orchestration platforms, like Kubernetes and Red Hat OpenShift Container Platform (OCP), have massive access and capabilities across container environments. They are also complex and require specialized skills to set up and maintain securely.
A misconfigured, unpatched, or poorly secured orchestration platform can allow attackers complete access to your environment, enabling them to create containers, alter images, and access sensitive data. A 2022 report by Orca Security, found that 62% of containers are currently orchestrated by an outdated version of Kubernetes.
At the same time, orchestration platforms are responsible for setting network policies within the container environment. Misconfigurations can leave your environment vulnerable to threats such as unauthorized access, privilege escalation, lateral movement, and data exfiltration.
2. Container Images
Images are the building blocks of container environments, and they frequently harbor vulnerabilities. These can be due to insecure coding practices, but more often, it’s caused by using outdated versions of open source binaries and libraries during development.
Not all container images are created in-house. For convenience, many organizations deploy ready-made images of popular open source software such as MongoDB. This creates risk. A 2020 study of 2500 publicly available Docker images found well over half contained vulnerabilities—and a 2022 study by Sysdig found that 56% of non-OS images in public registries contained high or critical vulnerabilities.
Many images also ship with poor default access configurations, such as blank root passwords. Since it’s common for images to provide root access within their container, this poses a significant risk. Similarly, internally developed images can be problematic if developers don’t have a secure system for storing and accessing secrets such as passwords and API keys. Hardcoding secrets are poor practice and can make it easy for attackers to escalate privileges and move laterally within a container environment.
3. Image Registry
Image registries, like Docker Registry and Quay, are the “crown jewels” of a container environment. If an attacker compromises your registry, they can alter images to include malware. This could allow them to exfiltrate data and credentials, encrypt data with ransomware, use computing resources for cryptomining, and more.
4. Host OS
The OS installed, like CoreOS or RancherOS, on nodes in your container environment is among the most significant sources of risk. If compromised, the host OS can grant attackers access to your entire application environment. While vulnerabilities in OS images are less common than in open source projects, they do happen—for instance, when official Alpine Linux Docker images shipped for three years with a blank root password.
5. Runtime
Runtimes, like Docker Engine and containerd, are also potentially vulnerable. If compromised, a runtime can be used to achieve various malicious purposes. A critical vulnerability in the popular CRI-O runtime made it possible to escape a container and gain root access to the host, allowing attackers to move between pods, execute malware, and exfiltrate data.
6. Orchestration Platform Agent
While agent software is linked to the orchestration platform, it poses a risk in its own right. Agents like kubelet have been known to house vulnerabilities, mostly related to privilege escalation and lateral movement. However, some vulnerabilities have allowed attackers to access sensitive information, such as memory addresses and configuration details.
7. Network Proxy
Vulnerabilities in network proxies, like kube-proxy, are comparatively rare but not unheard of. For instance, some versions of kube-proxy have been vulnerable to privilege escalation attacks.
Why Aren’t the Actual Containers a Vulnerability? Running containers are frequently the point of entry for attacks, but they aren’t the source of vulnerabilities. Once deployed, a container is immutable—you can’t make changes to code in a running container. Container images are the true source of vulnerabilities, and you can address them by updating the relevant image in your registry. Since containers are short-lived, changing a base image can quickly resolve vulnerabilities across the container environment. |
But Wait… There’s More
Container environments are highly interconnected. Runtimes communicate with registries, orchestration platforms communicate with worker nodes, containers communicate with each other, and outside services and databases. Further, boundaries between container images are resource boundaries defined within the kernel. This is a good solution for isolating system resources, but it’s not a security boundary.
These characteristics create three additional security risks:
An attacker who successfully compromises one component of a container environment has many opportunities for lateral movement, particularly if they can successfully escalate privileges.
Compromising one container may allow an attacker to control others on the same infrastructure.
Once inside an environment, an attacker can access data stored inside containers or intercept/initiate communication between a container and a database.
The last point, in particular, is crucial for compliance. Many regulatory frameworks like PCI-DSS and HIPAA are concerned primarily with sensitive data and include stringent requirements to protect it.
Chained Threats Most successful container attacks involve more than one exploit. For example, an attacker could use an injection attack on a database to achieve Remote Code Execution (RCE) and use it to execute a malware variant like Siloscape. This would allow them to open a backdoor into a misconfigured Kubernetes cluster and start creating malicious containers. |
Book a demo to learn how you can securely scale your cloud-first organization while achieving continuous compliance with SOC 2, ISO 27001, PCI DSS, HIPAA, GDPR, CCPA, and multiple other frameworks.
