Help improve this page
To contribute to this user guide, choose the Edit this page on GitHub link that is located in the right pane of every page.
Grant additional Kubernetes RBAC to EKS Auto Mode managed controllers
Amazon EKS Auto Mode manages the following controllers on your behalf: load balancing, networking, compute, block storage, and cluster insights. These controllers run on the EKS control plane. They authenticate to your cluster as the AWSServiceRoleForAmazonEKS service-linked role, and their in-cluster permissions come from Amazon managed access policies attached to that access entry.
You can extend a managed controller’s Kubernetes RBAC yourself. This is useful when the managed policy does not yet grant a required permission — for example, get on a specific Secret.
On Amazon EKS Auto Mode clusters, the auto-created access entry for AWSServiceRoleForAmazonEKS also declares the Kubernetes group eks:managed. Kubernetes RBAC is additive. A RoleBinding (or ClusterRoleBinding) whose subjects: name the eks:managed group grants the managed controllers extra permissions on top of the managed access policies.
How it works
-
The EKS Auto Mode managed controllers connect to your cluster as the service-linked role
AWSServiceRoleForAmazonEKS. -
The auto-created access entry for that role declares
kubernetesGroups: ["eks:managed"]. -
You author a
Role(namespaced) orClusterRole(cluster-wide) that describes the additional permission, and aRoleBinding/ClusterRoleBindingwhosesubjects:name theeks:managedgroup. -
Kubernetes RBAC combines your binding with the managed access policies, so the managed controllers receive both sets of permissions.
To confirm the group is present, run:
CLUSTER=<your-cluster> REGION=<your-region> ACCT=$(aws sts get-caller-identity --query Account --output text) aws eks describe-access-entry \ --cluster-name "$CLUSTER" --region "$REGION" \ --principal-arn "arn:aws:iam::${ACCT}:role/aws-service-role/eks.amazonaws.com/AWSServiceRoleForAmazonEKS" \ --query 'accessEntry.kubernetesGroups'
Expected output:
[ "eks:managed" ]
Scope the grant tightly
The eks:managed group applies to all EKS Auto Mode managed controllers. Scope the extra grant as narrowly as your use case allows so you only expose exactly what a managed controller needs:
-
Prefer
Role+RoleBinding(namespaced) overClusterRole+ClusterRoleBinding(cluster-wide). -
Restrict
resources,resourceNames, andverbsto the smallest set that unblocks your use case. For example, grantgeton a single namedSecretrather thanlist, watchon allSecretobjects. -
Delete the
RoleandRoleBindingwhen they are no longer needed.
Considerations for Amazon EKS Auto Mode
-
This mechanism only extends the Kubernetes RBAC of the EKS Auto Mode managed controllers. It does not change the Amazon IAM permissions granted by the managed access policies.
-
The
eks:managedgroup is present on EKS Auto Mode clusters whose service-linked role isAWSServiceRoleForAmazonEKS. -
A binding to
eks:managedapplies to every EKS Auto Mode managed controller. To keep the practical blast radius small, useresourceNamesand namespacedRoleobjects. This exposes only the resources you name, and only through the verbs you grant. -
This is a bridging pattern intended for cases where a managed access policy does not yet cover a permission you need. Where an Amazon managed policy already covers the permission, use the managed policy instead.
Example
For a step-by-step walkthrough that grants the EKS Auto Mode load balancer controller get on a named OIDC Secret — unblocking the alb.ingress.kubernetes.io/auth-type: oidc annotation on an ALB Ingress — see Grant the EKS Auto Mode load balancer controller access to a specific Secret.