On a managed Kubernetes cluster two permission systems decide what any identity can do, and most cluster takeovers exploit the seam between them rather than a flaw in either. Cloud IAM governs the cluster as a cloud resource, who can fetch credentials for it and, increasingly, what callers can do inside the Kubernetes API. Kubernetes RBAC governs objects inside the cluster: pods, secrets, roles and service accounts. A third path, workload identity, lets pods act on cloud APIs. This guide maps which layer controls what on Amazon EKS, Azure Kubernetes Service (AKS) and Google Kubernetes Engine (GKE), the threats that cross the layers, the failure modes, and how to decide where each grant should live. It is for platform engineers, cloud security architects and identity teams who own cluster access.
Platforms are listed alphabetically by provider name throughout (Amazon, Azure, Google); order is not a ranking.
Key takeaways
- There are three layers, not two. Cloud resource permissions, Kubernetes API authorisation and workload identity are separate decisions, and a gap in any one undoes the others.
- Cloud IAM can grant cluster-admin. On all three platforms a cloud role assignment or mapping can give full Kubernetes API control without a single RoleBinding appearing in the cluster.
- Kubernetes RBAC is still where workload permissions live. Service accounts, controllers and operators are authorised by Roles and RoleBindings, and permissions such as creating pods or reading secrets escalate quietly.
- Pick one source of truth per audience. Humans are usually best managed through cloud IAM and the IdP; in-cluster workloads through RBAC; pods calling cloud APIs through workload identity.
- Reviews must join both layers. An access review that reads only cloud IAM or only RBAC misses duplicated grants and stale mappings in the other.
The short answer
Cloud IAM answers "who may reach and administer this cluster as a cloud resource?" and, where the provider supports it, "what may this cloud identity do in the Kubernetes API?". Kubernetes RBAC answers "what may this authenticated subject do to which objects in which namespace?". Use cloud IAM for human and cross-cluster access because it inherits joiner, mover and leaver processes, MFA and central review. Use Kubernetes RBAC for in-cluster service accounts, operators and fine-grained namespace permissions that cloud roles cannot express. Use workload identity, not node credentials or static keys, when pods need cloud APIs. The live Kubernetes RBAC Guide covers RBAC objects in depth; this page covers the boundary.
The three layers side by side
| Layer | Question it answers | Where it is configured | Typical subjects | Audit trail |
|---|---|---|---|---|
| Cloud resource IAM | Who can create, change, delete or get credentials for the cluster? | Cloud IAM policies and role assignments on the cluster resource, project or subscription | Platform admins, CI pipelines, cloud automation | Cloud control plane logs |
| Kubernetes API authorisation | What can this caller do to Kubernetes objects? | Kubernetes RBAC objects, and on some platforms cloud IAM mappings or cloud role assignments evaluated by the API server | Engineers, operators, controllers, service accounts | Kubernetes audit log |
| Workload identity | Which cloud permissions does a pod get? | A binding between a Kubernetes service account and a cloud identity | Application pods, operators calling cloud APIs | Cloud control plane logs, attributed to the cloud identity |
Kubernetes itself has no deny rules in RBAC: permissions are purely additive. When a cloud authoriser is added, a caller is allowed if either system allows the request, so the effective permission set is the union of both layers.
How each platform joins the layers
Amazon EKS
EKS authenticates IAM principals to the Kubernetes API. AWS describes access entries as "the best way to grant users access to the Kubernetes API": an access entry associates Kubernetes permissions with an IAM identity such as an IAM role. Permissions attach in two ways. An access policy is an AWS-maintained, read-only permissions template, for example AmazonEKSClusterAdminPolicy (all verbs on all resources), AmazonEKSAdminPolicy, AmazonEKSEditPolicy and AmazonEKSViewPolicy (which excludes Secrets), associated with either a cluster or a namespace access scope. Alternatively an access entry names a Kubernetes group, and ordinary RBAC bindings grant that group permissions. The older mechanism is the aws-auth ConfigMap. To use access entries the cluster's authentication mode must be API_AND_CONFIG_MAP or API; API disables the ConfigMap method permanently, and AWS states the mode cannot be changed back to one that removes the access entry API. When access entries are enabled on a cluster that used aws-auth, only the cluster creator's entry is created automatically; other roles in the ConfigMap must be recreated by hand. For pods, EKS Pod Identity maps one IAM role to one service account in one namespace, using a trust policy with the pods.eks.amazonaws.com service principal and a node agent; IAM roles for service accounts (IRSA) is the older OIDC-based option. See the EKS Identity Hardening Guide.
Availability: AWS documents EKS Pod Identity for Linux EC2 worker nodes, with Fargate, Windows nodes, Outposts, EKS Anywhere and self-managed clusters served by other options such as IRSA; check the platform version requirements for your Kubernetes version.
Azure Kubernetes Service
Microsoft separates AKS identity into control plane authentication, control plane authorisation, Azure Resource Manager authorisation, cluster identity and workload identity. Fetching a kubeconfig is an ARM operation governed by Azure RBAC on the cluster resource. For the Kubernetes API, Microsoft Entra ID is the recommended authentication method, and authorisation can be Kubernetes RBAC, Azure RBAC for Kubernetes authorisation through an authorisation webhook, or both. Built-in roles are Azure Kubernetes Service RBAC Reader, RBAC Writer, RBAC Admin and RBAC Cluster Admin, assignable at cluster or namespace scope, and assignments at subscription, management group or resource group scope can govern many clusters centrally. Microsoft notes that the RBAC Writer role can read Secrets and run pods as any service account in the namespace. Local accounts provide a built-in cluster admin certificate that bypasses Entra ID, and Microsoft recommends disabling them in production. For pods, Microsoft Entra Workload ID is the current option; the older pod-managed identity is deprecated. See the AKS Identity Hardening Guide and the AKS Workload Identity Guide.
Availability: Microsoft documents Azure RBAC for Kubernetes authorisation as preconfigured on AKS Automatic and enabled with a flag on AKS Standard, requiring managed Entra integration; role assignments can take up to five minutes to propagate, and ABAC conditions for custom resources are in preview.
Google Kubernetes Engine
GKE integrates IAM and RBAC so a user can be authorised by either. Google's documentation states that GKE checks for an RBAC policy first and, if there is none, checks IAM permissions. IAM works mainly at project level; RBAC applies to objects in the cluster. The container.clusters.get permission (included in the container.clusterViewer role) is needed to authenticate to a cluster but does not authorise actions inside it. Google recommends granting in-cluster permissions through RBAC rather than IAM and advises against granting the escalate and bind verbs. Google Groups for RBAC lets RoleBindings name Google Workspace groups that are members of gke-security-groups, so group membership managed in the IdP drives RBAC. For pods, Workload Identity Federation for GKE lets IAM policies name a Kubernetes service account directly as a principal in the project's fixed pool, PROJECT_ID.svc.id.goog. See the GKE Identity Hardening Guide and the Google Cloud IAM and Service Accounts Guide.
Availability: Google documents that host network pods do not use Workload Identity Federation for GKE and that nodes keep using the node pool's service account for image pulls and built-in logging and monitoring agents.
Threat model: escalation across the layers
| Threat | Path | ATT&CK | Control at the right layer |
|---|---|---|---|
| Cluster-admin via a cloud role | An over-broad cloud role (or a role trusted by many principals) is mapped to cluster-admin through an access entry, an Azure RBAC Cluster Admin assignment or project-level IAM | T1078.004 Cloud Accounts | Cloud IAM: restrict who can assume the mapped role; scope cluster admin to named break-glass identities |
| Granting new cluster roles | A subject with escalate or bind, or with rights to edit RBAC, grants itself more | T1098.006 Additional Container Cluster Roles | RBAC: no escalate, bind or impersonate outside the platform team; audit RoleBinding changes |
| Service account token abuse | A compromised pod reads its mounted token or creates tokens through serviceaccounts/token, then calls the API | T1552.007 Container API, T1528 Steal Application Access Token | RBAC: narrow per-application service accounts; disable token automount where unused. See the Kubernetes Service Account Token Guide |
| Workload creation as escalation | Permission to create pods implicitly grants access to the namespace's secrets, ConfigMaps, volumes and the API rights of any service account there | T1610 Deploy Container | RBAC plus admission control: restrict pod creation and which service accounts a pod may use |
| Kubelet and exec access | get on nodes/proxy grants Kubelet API access and command execution in pods on the node; pods/exec runs commands in containers | T1609 Container Administration Command | RBAC: treat nodes/proxy and pods/exec as privileged |
| Pod to cloud pivot | A pod reaches node credentials or an over-privileged workload identity and calls cloud APIs | T1078.004 Cloud Accounts | Workload identity with per-service-account roles; block pod access to the node metadata endpoint |
| Reconnaissance | Listing namespaces, roles and bindings to find the next step | T1613 Container and Resource Discovery | RBAC: limit list on cluster-scoped resources; alert on enumeration by workload identities |
The Kubernetes RBAC good practices page lists further escalation paths worth reviewing in any role: list and watch on Secrets reveal their contents just as get does, creating arbitrary PersistentVolumes allows hostPath access to node filesystems, create rights on certificate signing requests plus approval can mint client certificates with arbitrary names, control of admission webhook configurations exposes every admitted object, and patch on Namespace objects can relax Pod Security Admission labels.
Failure modes
- Duplicated grants: the same engineer holds cluster admin through a cloud role mapping and through a ClusterRoleBinding. Removing one in a review leaves the other, and the reviewer believes access is gone.
- Stale mappings: aws-auth entries, access entries, Azure role assignments or RoleBindings that reference deleted IdP groups, departed users or retired pipelines. Kubernetes RBAC bindings reference users and groups by name, so a binding left behind becomes live again if the name is reused.
- Bootstrap identities never removed: the identity that created the cluster, or a local admin credential, keeps super-user rights indefinitely. Membership of system:masters bypasses RBAC entirely and cannot be revoked by deleting bindings.
- Node credentials as workload credentials: pods inherit the node's cloud role because workload identity was never configured.
- Workload identity sameness: on GKE, clusters in one project share a workload identity pool, so identical namespace and service account names in a less trusted cluster receive the same cloud access. Google's mitigations are separate projects, distinct namespace names or conditional IAM policies.
- Logs in one layer only: cloud logs show who fetched credentials, Kubernetes audit logs show what they did; investigations stall when only one is retained.
Controls per layer
| Control | Cloud IAM layer | Kubernetes RBAC layer | Workload identity layer |
|---|---|---|---|
| Least privilege | Separate roles for cluster lifecycle, credential retrieval and Kubernetes API access; namespace-scoped access policies or role assignments where available | RoleBindings over ClusterRoleBindings; no wildcards (they also cover resource types created in future); no cluster-admin for daily work | One cloud identity per application service account; no shared roles across namespaces |
| Source of truth | IdP groups mapped to cloud roles; access entries or role assignments as code | RBAC manifests in Git, applied by a pipeline | Bindings declared with the application's deployment |
| Break-glass | Named emergency identity with alerting on use | No system:masters for people; impersonation from a low-privilege account for admin tasks | Not applicable to workloads; rotate any static fallback keys |
| Review | Quarterly cloud role and mapping review | Quarterly binding review with kubectl auth can-i checks for critical subjects | Inventory of service account to cloud identity bindings with owners |
| Logging | Cloud control plane logs for credential retrieval and access configuration changes | Kubernetes audit logs for RBAC changes, secret reads, exec and token requests | Cloud logs attributed to the workload identity |
For the full review procedure see the Cloud IAM Review Checklist and How to audit Kubernetes cluster admin bindings.
Decision criteria: where should a grant live?
| Situation | Prefer | Why |
|---|---|---|
| Human engineers and administrators | Cloud IAM and IdP groups, mapped to Kubernetes permissions | Inherits MFA, leaver processing and central review |
| Many clusters with the same access model | Cloud IAM at a higher scope (account, project, subscription or management group) or groups mapped consistently | One assignment instead of per-cluster bindings, fewer stale copies |
| Fine-grained in-cluster permissions (specific resources, subresources, CRDs) | Kubernetes RBAC | Cloud built-in roles and templates are coarse; RBAC expresses verbs per resource |
| Controllers, operators, in-cluster service accounts | Kubernetes RBAC | These identities exist only inside the cluster |
| Pods calling cloud APIs | Workload identity | Short-lived, per-service-account cloud credentials instead of node roles or keys |
| Multi-cloud or portable clusters | Kubernetes RBAC bound to IdP groups, with a thin per-cloud mapping | Keeps the permission model identical across providers |
| CI pipelines deploying to clusters | Cloud IAM for credential retrieval plus namespace-scoped RBAC for deployment | Limits a stolen pipeline credential to its namespaces |
Small teams with one or two clusters can use the provider's built-in Kubernetes roles at namespace scope for people and keep RBAC for workloads. Large estates should treat the mapping between IdP groups, cloud roles and Kubernetes groups as code, reviewed and tested, because the number of stale combinations grows with every cluster.
Worked scenario: one engineer, three paths to admin
A platform team runs twelve clusters across two clouds. An access review asks whether a former contractor still has cluster admin anywhere.
- Cloud layer: the contractor's IdP account is disabled, so cloud sign-in fails. But a CI role the contractor once used is still mapped to cluster admin on three clusters through access entries, and the contractor's laptop still holds a long-lived access key for a user allowed to assume that role.
- RBAC layer: a ClusterRoleBinding grants cluster-admin to a Kubernetes group whose name matches an IdP group that was deleted and later recreated for a different team. The new team now has unintended admin.
- Workload layer: a debugging pod the contractor deployed runs with a service account bound to a cloud identity that can read every storage bucket in the project.
- Fix: remove the CI role's admin mapping and grant it namespace-scoped deployment rights; revoke the access key; replace name-based group bindings with bindings to stable group identifiers or managed group features; delete the debugging pod, its service account and its workload identity binding; add all three checks to the quarterly review.
- Lesson: no single layer's review would have found all three paths. The review must start from the person and walk every layer.
How to implement a two-layer access model
- Inventory every path to the API: export cloud role assignments and mappings (access entries and aws-auth, Azure role assignments, project IAM), all ClusterRoleBindings and RoleBindings, local or bootstrap admin credentials and workload identity bindings.
- Decide one source of truth per audience: people through IdP groups, workloads through RBAC, cloud access from pods through workload identity. Write it down as a standard; see the Cloud IAM Role Design Standard Template.
- Enable audit logging in both layers first: you need evidence of what access is used before removing any.
- Migrate in rings: start with non-production clusters; move people from static mappings to IdP-backed groups; on EKS move from aws-auth to access entries using API_AND_CONFIG_MAP until every mapping is recreated, remembering the switch cannot be reversed.
- Reduce cluster admin: replace broad grants with namespace-scoped roles, keep named break-glass identities, and disable local accounts where the platform supports it.
- Move workloads to workload identity: one cloud identity per application service account, then remove node role permissions that pods were using. See the Kubernetes Workload Identity Checklist.
- Roll back safely: keep the previous mapping in code until the new one is verified with kubectl auth can-i for each critical subject; keep a tested break-glass path while changing authentication modes.
Detection and measurement
Log both layers into one place. Kubernetes audit logs should capture changes to Roles, ClusterRoles and bindings, secret reads, pods/exec, serviceaccounts/token requests and impersonation; cloud logs should capture credential retrieval, access entry or role assignment changes and workload identity binding changes. The Kubernetes Audit Log Detection Guide covers rules. Metrics that show the model is working:
- Cluster admin holders: count of subjects with cluster-wide admin across both layers, per cluster, trending down to named break-glass identities.
- Duplicated grants: number of identities with admin through more than one path.
- Stale mappings: mappings and bindings referencing identities or groups that no longer exist in the IdP or cloud.
- Workload identity coverage: percentage of pods calling cloud APIs through workload identity rather than node roles or static keys.
- Wildcard roles: count of Roles and ClusterRoles with wildcard verbs or resources outside system components.
Framework mapping
| Framework | Reference | How it applies |
|---|---|---|
| NIST SP 800-53 Rev. 5 | AC-2 Account Management, AC-3 Access Enforcement, AC-6 Least Privilege, AC-6(5) Privileged Accounts, AC-6(9) Log Use of Privileged Functions | Both layers enforce access; reviews and privileged account limits must cover both |
| NIST SP 800-53 Rev. 5 | IA-9 Service Identification and Authentication, AU-12 Audit Record Generation | Workload identity for pods; audit records in cloud and Kubernetes layers |
| NIST CSF 2.0 | PR.AA-01, PR.AA-05, DE.CM-03 | Identities and credentials managed, permissions reviewed with least privilege, activity monitored |
| CIS Controls v8.1 | Control 5 Account Management, Control 6 Access Control Management | Inventory and review of human and service accounts with cluster access |
| ISO/IEC 27001:2022 Annex A | 5.15 Access control, 5.18 Access rights, 8.2 Privileged access rights | Access policy, provisioning and review across both layers |
| MITRE ATT&CK | T1078.004, T1098.006, T1552.007, T1528, T1609, T1610, T1613 | Techniques that cross the cloud and cluster layers |
Common failure patterns
- Reviewing RBAC only: the cluster shows a tidy set of bindings while a cloud role mapping quietly grants cluster admin to a widely assumable role.
- Pods using the node's cloud role: the Capital One Breach 2019 was not a Kubernetes incident, but it shows the pattern: an attacker obtained a compute role's credentials from the metadata service and used its broad storage access. Pods that inherit node roles create the same exposure; workload identity and metadata restrictions close it.
- Granting create pods as if it were harmless: it carries the namespace's secrets and every service account's API rights with it.
- Treating view roles as safe: list on Secrets, get on nodes/proxy and Writer-style roles that can run pods as any service account are not read-only in effect.
- Leaving bootstrap and local admin paths: the cluster creator's mapping or a local admin certificate outlives the project team.
- Name-based bindings to recycled groups: a binding to a group name grants access to whoever owns that name next.
Practitioner checklist
- Map every path to cluster admin per cluster: cloud mappings, role assignments, bindings, local or bootstrap credentials.
- Choose and document one source of truth for people, workloads and pod-to-cloud access.
- Manage access entries, role assignments, IAM bindings and RBAC manifests as reviewed code.
- Remove escalate, bind, impersonate, nodes/proxy and wildcard rights from all non-platform subjects.
- Give each application its own service account and its own workload identity; disable token automount where unused.
- Disable local admin credentials where supported and keep a named, alerting break-glass identity.
- Collect Kubernetes audit logs and cloud control plane logs together and alert on RBAC and mapping changes.
- Run a joined access review quarterly that starts from each person and pipeline and walks all three layers.
Standards and references
- Kubernetes: Using RBAC Authorization
- Kubernetes: Role Based Access Control Good Practices
- AWS: Grant IAM users access to Kubernetes with EKS access entries
- AWS: Learn how EKS Pod Identity grants pods access to AWS services
- Microsoft: Access and identity options for AKS
- Microsoft: Use Azure RBAC for Kubernetes authorization
- Google Cloud: Authorize actions in clusters using role-based access control
- Google Cloud: About Workload Identity Federation for GKE
Related NHI Mgmt Group resources: Kubernetes RBAC Guide, Cloud Workload Identity Guide, Kubernetes Service Account Token Guide, Cloud IAM Review Checklist.