forge a request to the metadata endpoint The workload is made to fetch a link-local address instead of the URL it expected.
Nothing about this is a Kubernetes operation, so no permission is consulted and no audit entry exists.
Precondition. The metadata service is reachable from pod network. Concealment and workload identity are the controls that remove this, and both are network configuration.
Break the chain. Deny pod egress to the link-local metadata range, and require the metadata service version that refuses requests without a signed header.
take the node cloud credentials The endpoint returns a live credential for the node's own cloud identity.
That identity exists to pull images and attach volumes, and it is routinely granted a good deal more.
Break the chain. Keep node identities to the minimum the kubelet needs, and enforce the hop limit so a pod cannot reach the endpoint at all.
use the credential against cloud APIs Reach is whatever the node identity was granted.
In practice that commonly includes the registry the cluster pulls from and the secret store the workloads read.
Break the chain. Scope the node role, and keep cluster secrets in a store the node identity cannot read.
reach the Kubernetes API as the cloud identity Managed offerings let a cloud principal obtain cluster credentials through a cloud API call.
That call is authorised by cloud policy, so a Kubernetes RBAC review of the cluster never shows it.
Break the chain. Audit who holds the cloud permissions that grant cluster access, and treat that list as part of the cluster's RBAC review.
T0 map an attacker principal into a privileged group The mapping object in kube-system decides which cloud principals authenticate as which cluster identities.
Write access to it adds a principal that the cluster then trusts, and the addition looks like ordinary configuration.
EKS aws-auth configMap takeover
T0
EKS aws-auth configMap takeover This is EKS-specific and requires the cluster's authentication mode to be CONFIG_MAP or API_AND_CONFIG_MAP. A cluster fully migrated to API mode ignores this ConfigMap entirely. If aws-auth doesn't exist yet (self-managed clusters, or a fresh EKS cluster before it's applied), create it directly instead of patching. Patch or create the aws-auth ConfigMap in kube-system, mapping your AWS IAM ARN to the system:masters group Authenticate via AWS CLI as cluster-admin Any IAM principal whose ARN is mapped can use it, including one from another AWS account, and it needs no AWS permissions of its own to do so The bearer token is a locally signed GetCallerIdentity request, an API that requires no allow policy, so a zero-permission identity still authenticates Editing the node role own entry is tempting but fails wherever that role has an access entry, since access entries override aws-auth for the same principal Removing the mapping revokes access at once, unlike the certificate paths where an issued credential cannot be recalled Console clusters using Auto Mode are created in API mode where this is inert, while a raw CreateCluster call with no accessConfig defaults to CONFIG_MAP where it is live ↗ Kubernetes documentation docs.aws.amazon.com/eks/latest/userguide/auth-configmap.html Break the chain. Move to the provider's API-based access entries so the mapping is not a mutable in-cluster object, and keep write on kube-system ConfigMaps to the control plane.
Sources: www.sysdig.com, securitylabs.datadoghq.com