Managed Kubernetes in a cloud assessment: RBAC, workloads and the pivot

Where the line falls in a managed cluster

EKS, AKS and GKE all follow the same split. The provider runs the control plane: the API server, the scheduler, the controller manager and etcd. The customer owns everything expressed through the API and everything running on the nodes: RBAC, namespaces, workloads, service accounts, network policy, admission control, secrets handling, image provenance and the cloud identity attached to the node group.

That puts the interesting surface entirely on the customer side, which is convenient, because provider policy puts the control plane out of reach anyway. Worth noting on AWS specifically: Amazon EKS is not named on the list of services customers may assess without advance permission, although Amazon Elastic Container Service and AWS Fargate are. The workable reading is that workloads, node instances, IAM roles and cluster configuration you own are testable in the ordinary way, and that the managed control plane needs the current AWS policy page read before anyone touches it.

On Azure, the rules of engagement are more expansive: Microsoft explicitly encourages attempting to break out of shared service containers such as Azure App Service or Azure Functions, on condition that you stop on success and disclose responsibly. Google Cloud applies its general condition, which is that the test affects only your own projects.

The ten risks worth scoping against

The OWASP Kubernetes Top Ten is the most useful scoping list available, because it is organised by the way clusters actually fail rather than by component. The 2025 list runs:

• K01 Insecure workload configurations
• K02 Overly permissive authorization configurations
• K03 Secrets management failures
• K04 Lack of cluster level policy enforcement
• K05 Missing network segmentation controls
• K06 Overly exposed Kubernetes components
• K07 Misconfigured and vulnerable cluster components
• K08 Cluster to cloud lateral movement
• K09 Broken authentication mechanisms
• K10 Inadequate logging and monitoring

For an assessment that sits inside a wider cloud engagement, K02 and K08 carry the most weight. K02 is where the escalation primitives live, and K08 is the reason a Kubernetes finding is a cloud finding rather than a container finding.

K02: the permissions Kubernetes itself calls escalation risks

The Kubernetes project documents this directly: within Kubernetes RBAC there are a number of privileges which, if granted, can allow a user or a service account to escalate their privileges in the cluster or affect systems outside the cluster. The list is short, specific and quotable, which makes it excellent finding material.

Creating workloads

The broadest one. Permission to create workloads, either Pods or workload resources that manage Pods, in a namespace implicitly grants access to many other resources in that namespace, such as Secrets, ConfigMaps and PersistentVolumes that can be mounted in Pods. The project then adds the sentence that turns a namespace role into an escalation: since Pods can run as any ServiceAccount, granting permission to create workloads also implicitly grants the API access levels of any service account in that namespace.

In practice this means a developer role with create on Deployments in a shared namespace holds, transitively, everything any service account in that namespace can do. If one of those service accounts is used by a controller with cluster-wide read, so does the developer.

Reading secrets

Obvious once stated, easy to miss when reviewing a Role. The project notes that list and watch access also effectively allow users to reveal the Secret contents, so a role that grants list on secrets without get is not a lesser grant.

Creating persistent volumes

If someone, or some application, is allowed to create arbitrary PersistentVolumes, that access includes the creation of hostPath volumes, which then means that a Pod would get access to the underlying host filesystem or filesystems on the associated node. From the node filesystem, kubelet credentials and other pods’ secrets are usually a short step away.

The node proxy subresource

Users with access to the nodes/proxy sub-resource have rights to the Kubelet API, which allows for command execution. This is a cluster-wide compromise dressed as an observability permission, and it appears in monitoring roles more often than anyone expects.

The verbs

Three RBAC verbs are escalation primitives in themselves, and the project documents each. escalate allows a principal to grant permissions it does not itself hold, bypassing the normal restriction that you cannot create a role more powerful than your own. bind allows attaching an existing, more powerful role to a subject. impersonate allows acting as another user, group or service account outright. Alongside them sit certificate signing request approval, token request, control of validating and mutating admission webhooks, and namespace modification, each of which the project lists as a documented escalation route.

K08: the cluster as a door into the cloud account

This is the item that makes Kubernetes a cloud-assessment topic rather than a platform-engineering one. Nodes in a managed cluster are cloud instances, and cloud instances carry cloud identities: an EC2 instance profile, an Azure managed identity, a Compute Engine service account. Those identities exist so the node can pull images, attach volumes, register with the control plane and write logs, and they are frequently broader than that.

A pod that can reach the cloud metadata endpoint at 169.254.169.254 can retrieve the node identity’s credentials and use them from inside the cluster. Nothing about that is a vulnerability. It is a network permission plus a default. The Kubernetes project puts the control on its own baseline checklist, in plain terms: access from the workloads to the cloud metadata API is filtered.

The proper fix is to give each workload its own scoped cloud identity rather than borrowing the node’s, using the workload identity mechanism each provider offers, and to block pod egress to the metadata address entirely. The assessment question is therefore two-part: can a pod reach the metadata endpoint at all, and if the answer is no, is every workload identity scoped to what its workload actually needs?

The same pivot runs in reverse, and it is worth checking. A cloud principal that can update the node group, modify the cluster’s access configuration or run a command on a node has cluster access without ever presenting a Kubernetes credential. Reviewing the cluster’s RBAC without reviewing who can administer it from the cloud side leaves half the path unexamined.

The baseline: what the project itself asks for

The Kubernetes security checklist is the shortest credible baseline for a cluster review, and the project is candid about its limits: checklists are not sufficient for attaining a good security posture on their own, and Kubernetes security is not one size fits all. Used as a review frame rather than a pass mark, it covers the ground well.

Authentication and authorization

The system:masters group is not used for user or component authentication after bootstrapping, and exists only as a break-glass mechanism. The kube-controller-manager runs with --use-service-account-credentials enabled. The root certificate is protected, either through an offline certificate authority or a managed online one with effective access controls, and intermediate and leaf certificates expire no more than three years out. A process exists for periodic access review, running no more than 24 months apart.

Network

The CNI plugin in use supports network policies, and ingress and egress policies are applied to all workloads. Default policies within each namespace select all pods and deny everything, so the namespace operates as an allow list. The Kubernetes API, the kubelet API and etcd are not exposed publicly on the internet, and etcd uses mutual TLS with a unique certificate authority. Use of LoadBalancer services and ExternalIPs is restricted. And, as above, workload access to the cloud metadata API is filtered.

Workloads

RBAC rights to create, update, patch and delete workloads are granted only where necessary. An appropriate Pod Security Standards policy is applied and enforced for all namespaces. Memory limits are set at or below the request, because the project warns that a memory limit higher than the request can expose the whole node to out-of-memory problems. Where nodes support it, seccomp is enabled with an appropriate syscall profile, and AppArmor or SELinux with an appropriate profile. Since Kubernetes 1.27, RuntimeDefault can be set as the default seccomp profile for all workloads.

What a cluster review covers, and what it does not

Area	In scope	Out of scope
Control plane	Your API server access configuration, audit policy, authorised networks, admission webhooks you have installed	The provider-operated API server, scheduler, controller manager and etcd implementation
Authorization	Every Role, ClusterRole and binding, and the effective permissions they resolve to	The RBAC implementation itself
Workloads	Pod specifications, security contexts, Pod Security Standards enforcement, image sources and secret handling	The container runtime as shipped by the provider
Network	Network policies, service exposure, LoadBalancer and ExternalIP use, egress to the metadata endpoint	The provider’s underlying network fabric
Nodes	The cloud identity attached to node groups, node configuration you control, and what a pod can reach from a node	The managed node image internals where the provider maintains them

Access the assessment needs

Two credentials, in this order. First a read-only ClusterRole for the review pass, which is enough to enumerate roles, bindings, workloads, network policies, admission configuration and namespaces, and to resolve the effective permission graph without changing anything. Then a namespace-scoped service account with the permissions of a realistic persona, so escalation paths can be proven rather than inferred. A cluster review from a cluster-admin credential proves nothing about what a compromised workload could do.

On the cloud side, the same engagement needs the read-only audit role for the surrounding account, because the cluster’s node identities, the cloud principals that can administer the cluster and the storage the workloads reach all live there. Reviewing a cluster in isolation from its cloud account produces a report that stops exactly where the interesting part begins.

Reporting a cluster finding so it gets fixed

Kubernetes findings fail to land for a predictable reason: they are written against the manifest rather than against the control, and the manifest is generated. A finding that says a specific Deployment runs privileged will be fixed in that Deployment; a finding that says no Pod Security Standards policy is enforced on the namespace will be fixed once, for every Deployment that will ever be created there.

The same applies to RBAC. Naming the binding is useful; naming the pattern is what changes the cluster. A finding that reads “the platform ClusterRole grants create on Pods cluster-wide, which transitively grants the API access of every service account in every namespace” is actionable in a way that a list of over-permissive bindings is not, because it explains the mechanism the reader can then apply to the next role they write.

Finally, assign the owner. In most organisations the cluster team owns RBAC and Pod Security Standards, the platform team owns node groups and the cloud identity attached to them, and the application teams own workload specifications. A single unassigned list of cluster findings will be triaged by whoever received it and closed by nobody, which is the most common reason a good cluster review changes nothing.