Derivation rules

A principal with elasticfilesystem:ModifyMountTargetSecurityGroups can alter security group rules controlling NFS access to mount targets.

A principal with elasticfilesystem:PutFileSystemPolicy can rewrite the EFS file system resource policy.

A principal with elasticfilesystem:ClientMount in the EFS file system policy can mount the file system and read all file data via NFS.

A principal with elasticfilesystem:ClientRootAccess can bypass POSIX root-squash and read all file data including root-owned files.

A principal with elasticfilesystem:ClientWrite in the EFS file system policy can mount the file system and write data via NFS.

An EFS file system policy granting ClientMount to a principal from another AWS account creates a cross-account NFS data path.

An EFS file system with no explicit file system policy (PolicyNotFound) is fully accessible to any same-account IAM principal that can network-reach the mount target.

A principal with elasticfilesystem:ModifyMountTargetSecurityGroups can modify mount target security groups to enable NFS access, converting conditional data-access edges to active.

A principal with elasticfilesystem:PutFileSystemPolicy can self-grant ClientMount and read all file data on the EFS file system.

A principal with elasticfilesystem:PutFileSystemPolicy can self-grant ClientWrite and write all file data on the EFS file system.

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.

Kubernetes write access to the aws-auth ConfigMap in kube-system (obtained after gaining any cluster access) allows adding any IAM ARN to the mapRoles/mapUsers entries with groups: [system:masters], granting cluster-admin to arbitrary IAM principals. This is the legacy (CONFIG_MAP authMode) escalation vector.

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.

A principal holding the full ECR push permission set (BatchCheck + InitiateLayerUpload + UploadLayerPart + CompleteLayerUpload + PutImage) can push a complete new image.

A principal with ecr:PutImage on an ECR repository can overwrite any mutable tag, poisoning every workload that pulls it.

A Kubernetes ServiceAccount annotated with eks.amazonaws.com/role-arn maps to that IAM role; the mapping is realized when the role trust allows the cluster OIDC issuer + sub for this SA.

An IAM role whose trust policy Federated principal matches an EKS cluster OIDC issuer URL trusts that cluster's projected SA tokens.

A Kubernetes ServiceAccount annotated with eks.amazonaws.com/role-arn and a matching IAM role trust policy (Federated = cluster OIDC issuer) lets any pod running as that KSA exchange its projected token for IAM role credentials via sts:AssumeRoleWithWebIdentity. Cites container-chains workload-identity-federates and federation-chains federation-maps-to-identity.

Each EC2 instance in an EKS managed node group runs as the node group IAM role (nodeRole).

Pods on EC2 managed nodes with IMDS hop-limit >= 2 can reach 169.254.169.254 and retrieve temporary credentials for the node group IAM role. Any code execution inside such a pod inherits the node role without any IRSA or Pod Identity annotation.

Exec into a running pod (via cluster-admin or direct pods/exec RBAC) inherits the pod's mounted IRSA or Pod Identity token, executing as the pod's IAM role. Cites container-chains cluster-rbac-exec; dedupes on (CanExecuteAs, principal, role).

A pod whose ServiceAccount has an IRSA annotation executes as the annotated IAM role (credentials delivered by token projection + STS).

A pod whose SA is linked via an EKS Pod Identity Association executes as the associated IAM role (credentials delivered by the pod-identity-agent DaemonSet at 169.254.170.23).

An EKS Pod Identity Association (eks:CreatePodIdentityAssociation) links a Kubernetes namespace:ServiceAccount pair to an IAM role. Pods running as that SA receive IAM credentials from the eks-pod-identity-agent at 169.254.170.23. Whoever can create or modify this association can reroute which IAM role any pod in that namespace:SA binding runs as.

An EKS Pod Identity Association explicitly maps a namespace:SA pair to an IAM role; the mapping is backed by the role trust trusting pods.eks.amazonaws.com.

An IAM role whose trust policy Service principal includes pods.eks.amazonaws.com is eligible for EKS Pod Identity associations.

A Kubernetes RBAC subject (user/group/SA) holding pods/exec create verb on a namespace can exec into any pod in that namespace.

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.

A Kubernetes pod/deployment references (pulls and runs) a container image from an ECR repository. Records the tag/digest for mutability assessment.

elasticache:CreateSnapshot combined with elasticache:CopySnapshot allows creating a fresh Redis RDB snapshot from a running cache and immediately exporting it to an attacker-controlled S3 bucket. The RDB file is a complete serialized dump of all in-memory data at snapshot time, bypassing the need for scheduled snapshots. No live cluster access needed.

elasticache:ModifyReplicationGroup with AuthToken + AuthTokenUpdateStrategy=SET (or AuthTokenEnabled=false) sets or removes the Redis AUTH token to an attacker-controlled value. elasticache:ModifyUser resets ACL user passwords. elasticache:ModifyServerlessCache modifies UserGroup bindings. The principal gains the capability to mutate cache auth configuration; paired with network reachability, this yields data-plane access.

elasticache:ModifyUserGroup can add an attacker-controlled ACL User to a User Group that is already attached to a Redis/Valkey cluster. The attacker then authenticates as that user to the cluster with the user's effective ACL permissions (which may include allcommands/allkeys for full access). This bypasses the AUTH token and grants data-plane access via the ACL user.

A Redis/Valkey cluster with AuthTokenEnabled=false (or absent) or a Memcached cluster is accessible to any VPC-reachable compute resource with an inbound security group rule on the cache port (6379 Redis, 11211 Memcached) - no credential is required. Both read and write operations are permitted without authentication, enabling cache poisoning and lateral movement attacks.

elasticache:CopySnapshot copies an existing Redis RDB snapshot to an S3 bucket. If the destination bucket is attacker-accessible, the RDB file - containing all cached in-memory data including application secrets - is exfiltrated. No live cluster access needed.

A principal with CreateLoadBalancer + CreateListener + CreateTargetGroup + RegisterTargets + EC2 read/write perms can create a new internet-facing ALB or NLB, exposing any registered backend to the public internet. Emit CanCreate(Identity -> LoadBalancer) as a POTENTIAL escalation premise; ExposedToInternet fires on the resulting LB.

Modify an ALB listener whose default action includes authenticate-oidc or authenticate-cognito to remove or replace the authentication action, bypassing application-layer identity enforcement before traffic reaches the backend.

Modify an ALB listener rule whose actions include authenticate-oidc or authenticate-cognito to bypass per-path authentication enforced by that rule.

An ALB or NLB listener with a forward action creates a network path from the LB to its backend targets (instances/IPs/ALBs). This is a CONDITIONAL(network_reachability) fact - the LB SG must allow inbound AND the backend SG must allow inbound from the LB's SG/IP range.

Replace the security groups on an ALB or CLB with a permissive one to open inbound access from any source to the load balancer (network gate weakening).

elasticmapreduce:AddJobFlowSteps lets a principal inject arbitrary executable steps into a running cluster.

An EMR cluster whose instance profile has s3:GetObject on a data lake bucket can read all objects in that bucket.

S3 URI where EMR cluster logs are written; record as a resource reference for data discovery.

Create a new EMR cluster bound to a passable privileged JobFlowRole via RunJobFlow + iam:PassRole.

Submit a step to a running EMR cluster via AddJobFlowSteps; the step executes as the cluster's instance profile role without iam:PassRole.

Create a new EMR cluster with a privileged JobFlowRole via RunJobFlow + iam:PassRole; arbitrary bootstrap/step code executes as that role.

An EMR cluster and every step/application running on it execute as the cluster's EC2 instance profile (JobFlowRole).