Software containers have become more popular in recent years as many organizations have discovered the benefits of containerization. Kubernetes is the most widely used container orchestrator in the market, and Kubernetes adoption – especially in production environments – is taking off. According to Gartner, “by 2022, more than 75% of global organizations will be running containerized applications in production.”
However, the explosion in Kubernetes adoption hasn’t been without its share of security concerns. In fact, according to a recent research, nearly half of all companies surveyed (44%) have delayed moving an application into production because of concerns over security of containers or Kubernetes. This is a bit ironic – companies are adopting containers to move fast but they’re slowing down application releases because of security concerns.
Security concerns are propelled by real-life security incidents. 94% of the survey respondents admitted to experiencing a security incident in the last 12 months. The fact that nearly everyone has had a security problem helps explain the previous finding, that nearly half of respondents had delayed an application deployment because of security concerns. In the majority of the security incidents it was due to a misconfiguration (69%), and only 27% of respondents had a runtime incident. This data highlights how hard it is to get security right with this tech stack.
Kubernetes Security Challenges
While Kubernetes orchestrated containers are replacing some more traditional cloud-based services because they are effective in running applications from one environment to another (public cloud, private data center, etc.), they introduce several security challenges and risks that make the task of managing them securely quite demanding.
Lack of Visibility
Challenges around secure containerization begin with a lack of visibility. Containers are everywhere, and despite their benefits, their expansion creates security blind spots and increases the company’s attack surface. As more containers are deployed, maintaining adequate visibility into critical cloud-native infrastructure components becomes more difficult. The distributed nature of containerized apps makes it difficult to quickly investigate who has developed an application and whether this app is secure or not. How do you know if the applications were tested to find and fix high-risk vulnerabilities that an attacker may exploit? Unless security was integrated into the process and documented as part of the project, you likely don’t know. Without knowing who developed the applications and how, it is nearly impossible to understand their security posture.
To make matters worse, containers tend to be “deploy and forget” assets, which could mean that no one is monitoring them for suspicious activities, outdated applications, lack of tooling and other security components. This lack of visibility into their security posture means fewer eyes on security gaps. When assessing the security of containers, security teams find security deficiencies, such as misconfigurations, overly permissive access rights and insecure application logic, libraries, middleware and frameworks, to name a few.
Misuse of Images
For those familiar with containers, they will attest to the fact that the technology is dependent on images. They serve as the building blocks for containers. The technology enables developers to easily create their own images or download public files from providers such as Kubernetes.
However, images are not always easy to trust from a security perspective. The images must be signed and originate from a trusted registry to ensure high-quality protection. They also must get properly vetted and the code validated. Otherwise, the images are vulnerable to cyberthreats.
Organizations need a strong governance policy around using trusted image registries. Ensuring that only images from whitelisted image registries are being pulled in the business environment can be challenging and must be part of any container and Kubernetes security strategy along with security best practices, such as vulnerability scanning.
Communication and Network Policies
Containers and pods need to communicate with each other within the deployment as well as to other endpoints to accomplish their goals. As a result, businesses must monitor all traffic, north-south and east-west traffic. If a container is breached, the attack surface is directly related to how broadly it can communicate with other containers and pods. In a sprawling container environment, implementing network segmentation can be prohibitively difficult given the complexity of configuring such policies.
Therefore, developing and implementing network policies adhering to the least privilege principle might be challenging but it is highly recommended. Network policies specify how groups of pods are allowed to communicate with each other and other network endpoints. We can think of them as the Kubernetes equivalent of a firewall. The goal of such policies should be to allow containers to communicate to only those containers that are absolutely required in order to minimize the attack surface.
Default Configuration Settings are not Secure
Kubernetes offers rich configuration options, but default settings are usually the least secure. Being in accordance with the DevOps principles, Kubernetes is designed to speed application development, not to isolate its components. For example, the default network policies allow every asset to talk to every other asset in a Kubernetes environment. Another configuration risk relates to how secrets such as cryptographic keys are stored and accessed, a discipline called secrets management. Businesses must ensure that secrets are not being loaded as environment variables but are instead mounted into read-only volumes in their containers, for example.
Runtime Monitoring Challenges
One of the advantages of containers and Kubernetes is their immutable design. Whatever is running should never be patched or changed but rather destroyed and recreated from a common template when new updates are needed. However, other properties of containerization pose unique challenges, including the difficulty in monitoring containers due to their ephemeral nature.
The rapid churn of containers makes it near impossible for humans to monitor which container processes are running at any given time, let alone identify unnecessary or malicious processes. And when a potential threat is detected in a running container, such as an active breach or vulnerability, IT teams must be able to not only kill that container and replace it with a non-compromised version but also integrate that information into your CI/CD pipeline to inform future build and deploy cycles.
Conclusion
Containers have given rise to microservices and DevOps practices, leading to faster development and release cycles. They’ve increased collaboration between developers and security teams. Properly securing containers comes down to following known security best practices and ensuring that security is embedded into the container life cycle rather than treated as an afterthought.
About the Author
The opinions expressed in this post belongs to the individual contributors and do not necessarily reflect the views of Information Security Buzz.
