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.

We’ll examine:

1. Who can deploy?

2. How are workloads being deployed?

3. What services are publicly exposed?

4. What services are internally exposed?

5. Do we have visibility into the cluster?

6. 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_lookup

• kubectl rbac_view - starts a web interface to let you explore the different roles and role bindings

• kubectl access_matrix

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 kubectl apply 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 behalf.

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.