As an orchestration platform, Kubernetes impacts many runtime security functions. These include authentication, authorization, logging and resource isolation, as well as more advanced implications such as workload placement and network segmentation.
Because of the orchestrator’s comprehensive reach in the container runtime environment, Kubernetes security is a critical aspect of the security posture of the container infrastructure. In this first part of our new blog series, which is part of our upcoming ebook release on Kubernetes deployment and security patterns, we will talk about threat models for a Kubernetes deployment.
Kubernetes Threat Models
In the Kubernetes environment, there are generally four types of threats that apply regardless of the deployment model (with some edge case exceptions):
- External attacks aiming to compromise Kubernetes controls: This threat exists for all connected systems. In the context of a Kubernetes cluster, this represents attackers gaining access to the system or compromising certain controls that will impact the security of the system.
- Compromised containers or nodes: If there are malicious containers within the Kubernetes-controlled environment, or malicious nodes within a cluster, what is the impact to the rest of the nodes or the cluster? Can you effectively contain the “blast radius” both on the node and within a cluster?
- Compromised credentials: What happens when a Kubernetes administrator’s credential is compromised? How much does that affect the cluster?
- Misuse of legitimate privileges: This could happen when systems are misconfigured, controls are lacking or operations are not closely monitored.
These different threats may result in a multitude of compromises and undesirable scenarios, including elevation of privileges, exfiltration of sensitive data, compromise of operations or breach of compliance policies.
[cycloneslider id=”kubernetes-series-book-2-sponsors”]
One of the attack scenarios that has garnered a fair amount of attention is the concern of “blast radius” — how much damage can a compromised container do to other containers on the same node, or how much damage can a compromised node do to the rest of the cluster? All security considerations for a Kubernetes deployment are motivated by these threat models as well as the need to minimize “blast radius.”
External Attacks
In a Kubernetes environment, the components that are accessible externally will be exposed to external attacks. Those components can include the application programming interface (API) server, kubelet and etcd. (See InApps Technology’s ebook, “The State of the Kubernetes Ecosystem,” to review the components in a Kubernetes node.)
To alleviate the threat of external attacks, ensure that only the necessary Kubernetes services are exposed and no more. Always enforce authentication and configure the right network security policies for any exposed services.
Compromised Containers
Ultimately, Kubernetes manages workloads running in containers. If a container is compromised, the concern is whether the container can escalate privileges to take control of other containers or the cluster.
Kubernetes’ isolation mechanisms, such as namespaces or network segmentation, as well as some of the built-in, OS-level controls regulating what the container can access, can help limit the impact of compromised containers. One other control users should pay attention to is the ability to limit the number of containers that can run in a privileged mode — if a privileged container is compromised, it will be able to do much more harm than a normal container.
Compromised Credentials
When legitimate user credentials have been compromised, you may have a malicious user in the system. It is critical, therefore, to properly regulate and limit a user’s access to cluster resources and to closely monitor user actions.
To reduce the impact of malicious users, you need to enforce least-privilege access, role-based access control or other fine-grained access controls.
Misuse of Privileges
If the system is not configured correctly, it could lead to misuse of user privileges. For instance, if network policies do not restrict access between pods or namespaces, a user might be able to read traffic for other namespaces that he or she should not have access to in the first place.
A major defense against misuse of privileges is proper hardening. Ensure that all the system components, such as containers, pods, namespaces and kubelets, are hardened to significantly reduce the possibility of privilege misuse.
Another important defense is authorization control. Kubernetes supports a plugin architecture, which allows sophisticated authorization logic to be included. Design and implement authorization correctly; it’s one of the most effective weapons against privilege misuses.
With the threat model in mind, next time we will explore Kubernetes security along four major tenets: authentication and authorization; resource isolation; hardening and network security; and logging and auditing.
Feature image by Yannick Pulver on Unsplash.
