Containers and Kubernetes have revolutionized the way many teams deploy applications. But with the many benefits that these technologies provide come new challenges.
Key among those challenges is security. By adding more layers and complexity to application environments, containers and Kubernetes create new opportunities for attackers and new security threats for Kubernetes admins to address. And although Kubernetes provides certain built-in security features, they are hardly enough to stop all attacks on their own.
The following is an overview of Kubernetes security essentials, including the main types of security risks that exist in a Kubernetes-based environment, why securing Kubernetes is harder than securing non-containerized environments, and best practices that teams can follow for maximizing Kubernetes security.
The main reason why securing Kubernetes is challenging is that Kubernetes is a sprawling platform composed of many different parts. Each of those components carries its own security risks.
Here’s a rundown of the key parts of a Kubernetes environment and the most common security risks that affect them:
- Containers: Containers can contain malicious code that was included in their container images. They can also be subject to misconfigurations that allow attackers to gain unauthorized access under certain conditions.
- Host operating systems: Vulnerabilities or malicious code within the operating systems installed on Kubernetes nodes can provide attackers a path into Kubernetes clusters.
- Container runtimes: Kubernetes supports a variety of container runtimes. All of them could potentially contain vulnerabilities that allow attackers to take control of individual containers, escalate attacks from one container to another, and even gain control of the Kubernetes environment itself.
- Network layer: Kubernetes relies on internal networks to facilitate communication between nodes, pods, and containers. It also typically exposes applications to public networks so that they can be accessed over the Internet. Both network layers could allow attackers to gain access to the cluster or to escalate attacks from one part of the cluster into others.
- API: The Kubernetes API, which plays a central role in allowing components to communicate and applying configurations, could contain vulnerabilities or misconfigurations that enable attacks.
- Kubectl (and other management tools): Kubectl, Dashboard, and other Kubernetes management tools might be subject to vulnerabilities that allow abuse on a Kubernetes cluster.