KubernetesCluster

CreateAccessEntry + AssociateAccessPolicy with AmazonEKSClusterAdminPolicy maps an IAM principal to Kubernetes cluster-admin (system:masters) RBAC. The principal can then exec into any pod and execute as its IAM role.

CreateAccessEntry + AssociateAccessPolicy with AmazonEKSClusterAdminPolicy also grants the principal ability to modify cluster access configuration, enabling chaining to downstream cluster-auth-mode control paths.

A principal with Kubernetes cluster-admin RBAC (system:masters binding or equivalent ClusterRole: cluster-admin) can exec into any pod in any namespace via pods/exec. This gives OS-level code execution and access to the pod's mounted SA token / IRSA credential. Matches CanModifyConfiguration on the cluster (indicating cluster-admin access establishment).

eks:CreateNodegroup combined with iam:PassRole (for a role trusting ec2.amazonaws.com or eks.amazonaws.com) allows an attacker to create a new managed node group with an attacker-controlled AMI or launch template. Every node in the group executes the attacker's code, and the attacker can escalate to the node group's IAM role.

eks:CreatePodIdentityAssociation lets an IAM principal link any namespace:SA to any IAM role it can pass (iam:PassRole). An attacker with this permission can reroute an existing SA to a more-privileged role, or add a new association for a SA they can run pods as, gaining that role's credentials at the next pod startup.

eks:UpdateClusterConfig allows changing the cluster's authenticationMode, endpoint access settings (public/private), and upgrade policy. An attacker with this permission can enable API authenticationMode to allow access entry creation, or change endpoint access to make the API server reachable, enabling follow-on access entry cluster-admin escalation.

eks:UpdateNodegroupConfig allows modifying an existing node group's launch template and scaling configuration. An attacker with this permission can supply a custom launch template with an attacker-controlled AMI or user-data, gaining CanModifyCode on nodes that cycle through the new template.

runCommand/action can kubectl-apply attacker manifests - new/patched Deployments - changing what code runs as each workload identity.

managedClusters/agentPools/write + assign on a target MI allows swapping the kubelet MI, binding all nodes to a more-privileged identity.

Submit a job to an AKS cluster attached as an AML compute target; the job runs inside the AKS cluster as a Kubernetes workload, enabling lateral movement to non-AML K8s resources.

The Cloud Deploy execution SA's GKE deployment permissions (container.developer) give it CanDeploy to a GKE cluster.

container.clusters.update allows modifying cluster-wide security configuration: disabling Workload Identity, changing master auth networks, disabling Binary Authorization, or enabling EXPOSE_ALL_SCOPES metadata - each is a misconfiguration that opens downstream escalation paths.

container.clusters.getCredentials + cluster-admin ClusterRoleBinding (or system:masters group) => pods/exec create on all pods => CanExecuteCommand fan-out.

container.clusters.getCredentials yields a kubeconfig (endpoint + CA) authenticated with the caller's GCP token; k8s RBAC then governs what actions are permitted.

container.nodePools.update + iam.serviceAccounts.actAs on a privileged SA allows changing an existing node pool's service account - converts existing pod workloads to run as the new (more privileged) SA via legacy metadata access.