In this Help Net Security interview, Emily Long, CEO at Edera, discusses the most common vulnerabilities in Kubernetes clusters and effective mitigation strategies.
Long shares insights on emerging isolation technologies that could enhance Kubernetes security and better protect containerized environments.
What are the most common vulnerabilities in Kubernetes clusters today, and how can they be mitigated effectively?
Kubernetes has made significant progress in security since its inception ten years ago. Security isn’t an afterthought in the most widely deployed Kubernetes distributions and managed Kubernetes platforms like Amazon’s EKS, Google’s GKE, and Microsoft’s Azure provide reasonably secure defaults for the control plane. However, the shared responsibility model defining the security responsibilities of the cloud provider and customer still places the onus of workload and multi-tenant security on the customer.
Most organizations are still in the early stages of their Kubernetes security journey and visibility and monitoring have taken precedence over secure defaults. As a result, organizations are adding layers of visibility tooling, and the number of security vendors that focus on visibility continues to rise. Worse, these security tools’ jobs are to passively monitor for breaches after they’ve occurred without actually preventing attacks.
This leaves organizations with significant vulnerability gaps to address, including container image vulnerabilities, out-of-date and unsupported Kubernetes clusters, and, most notably, the lack of container isolation to limit the exposure from a compromised pod.
Mitigating the first two vulnerabilities largely depends on keeping your Kubernetes clusters and container images up-to-date to reduce the impact of known vulnerabilities. Even when mitigating known vulnerabilities with up-to-date CVE-free images, the lack of true isolation for containers means that unknown or vulnerabilities specific to in-house software can still render your entire cluster untrustworthy.
Container isolation requires more than keeping your software up-to-date; considerations include applying pod security practices or using a container runtime with built-in isolation enabled, which has just been introduced as a new technology this year.
How can developers ensure that Kubernetes pods are secured for production workloads, especially when considering network policies and resource limitations?
Securing production pods is a complex topic. Network policy restricts the network traffic a pod can send and receive, a crucial security element. Resource limits prohibit “noisy neighbor” pods from consuming all available resources. While managing networks and resources is vital, it’s not enough to secure production workloads in Kubernetes.
Kubernetes provides layers of sandboxing configuration options that restrict pod privileges. These configurations must be hand-crafted and maintained to lock down each pod’s capabilities. Security teams often have dedicated people working on behavior analysis which requires special tools and a replicated model of the real environment, all to produce a security policy that can be brittle when development changes occur in the application. Restricting privileges aims to mitigate an overly privileged or malicious pod escaping the container to the host system or adjacent pods. In contrast, new technologies that provide true pod security and isolation avoids the need for complex configuration and maintenance.
Kubernetes Secrets management is often highlighted as a critical security measure. What are the best practices for managing Secrets securely in a Kubernetes environment?
The gold standard for protecting secrets is using a Key Management Service (KMS) to enable secret encryption in Kubernetes. While this is a solid security practice, the reality is that “secrets” need to exist in plaintext in the memory of whatever application needs them, where they can (almost) always be stolen by another process on the same node with enough perseverance.
The same pod isolation we discussed in production workloads is also crucial to protect Kubernetes secrets. Isolation technology that doesn’t share plaintext memory between workloads on the same node results in no perseverance and can prevent the theft of database passwords, private keys, or service account credentials.
How should organizations keep their Kubernetes security policies aligned with evolving regulatory requirements?
If you’re running a managed Kubernetes offering from a cloud provider, they’ll handle most compliance configurations like CIS benchmarks and OWASP compliance. Scanning for these frameworks is essential if you run your Kubernetes clusters.
While not covered by most compliance frameworks, having a Pod Security Standards (PSS) Baseline policy is also a good idea.
Looking at recent innovations in Kubernetes security, what technologies or approaches do you believe will shape the future of protecting containerized environments?
Focusing on secure by design kubernetes products that make it easy for security practitioners to use in their infrastructure is going to shape the future of containerized environments. Point solutions today really focus on monitoring, not actually preventing breaches.
New technologies like using a type 1 hypervisor to offer isolation at the container level enables companies to realize the original promise of Kubernetes. Instead of running containers in Linux namespaces, containers are treated like a virtual machine guest. What is novel about this approach is that there is no shared kernel state between containers, and a memory-safe Rust control plane further secures workloads. Because of how this tech is built, it can be used anywhere users run their containers (public cloud, private cloud, and on-premise) and doesn’t require virtualization extensions or custom infrastructure. The simplicity and strength of the security posture is what is so compelling about this approach.
This isolation technology will shape the future of security for production containers.