On this page: There are a number of factors that influence the exploitability of your cluster. We'll start with reviewing access controls: who can deploy and how are workloads deployed?
In this section of the guide, we’re trying to collect information to help us determine how exploitable our Kubernetes environment might be.
If an attacker had access to the infrastructure, does everything fall over, or are there security controls in place that will make it harder for them to escalate their access?
We’re working here to try to find which attack vectors are most plausible to being exploited.
- Who can deploy?
- How are workloads being deployed?
- What services are publicly exposed?
- What services are internally exposed?
- Do we have visibility into the cluster?
- How vulnerable is my cluster?
We’ll conclude this section by discussing common compromise scenarios: a pod being compromised, a developer compromising a cluster, and a developer being compromised by an attacker.
1. Who is Deploying?
Authentication is a critical control to understand. More often than not, a Kubernetes
cluster will allow individuals to access it using
kubectl and you’ll
need to know who exactly has access.
Furthermore, does anyone have access via SSH to modify Nodes after they’ve been deployed?
If you’re running in a cloud provider, it’s possible that the cluster has been configured with an OIDC integration letting you manage users via the provider. Otherwise, Kubernetes itself may be providing tokens for users to authenticate.
Here are a couple of Krew tools to help you audit RBAC policy:
kubectl who_can get pods
kubectl who_can list secrets -n kube-system
kubectl rbac_view- starts a web interface to let you explore the different roles and role bindings
For more information, see my other blog post with NCC Group: Tools and Methods for Auditing K8s RBAC.
2. How Are Workloads Being Deployed?
The Kubernetes API handles creating and destroying all objects within the
cluster. Most organizations do not manually deploy objects with
but use some kind of tool to abstract it away. This could be Helm, Terraform,
Pulumi, or simple CI/CD integrations that run the
kubectl apply on a user’s
Here you’re looking for weaknesses in the deployment model such as whether it’s using shared resources, how secrets are managed, and who has access to manage the systems.
If a developer is running with console access into the cluster, it’s a high risk scenario.