If your organization runs a multi-tenant Amazon Elastic Kubernetes Service (Amazon EKS) cluster, you likely need to scope access to Amazon Elastic Container Registry (Amazon ECR) container image repositories per team. Each team needs access only to their own repositories, blocked from pulling other teams’ images. By default, Amazon EKS configures image pull permissions for Amazon ECR at the node level. Pods running on the same node share the same node credentials and the same access to ECR repositories, regardless of which team owns them.
Each team might own their own ECR repositories, but the shared node role gives pods in the cluster equal access to Amazon ECR. For platform teams that want to assign repository permissions at the pod level, giving each team’s applications their own scoped access to specific repositories, this has been a challenge. It required custom admission policies, third-party policy engines, or per-team node groups. Starting with Kubernetes 1. 34, Kubernetes Enhancement Proposal (KEP) 4412 introduces per-pod credential support for kubelet image pulls, making pod-level repository permissions possible with AWS native controls.
AWS added full support for this feature on Amazon EKS v1. This post shows how to scope Amazon ECR image pull permissions to individual Kubernetes pods using the ecr-credential-provider and ECR repository policies on Amazon EKS. In an Amazon EKS cluster, each node is assigned a node AWS Identity and Access Management (IAM) role. The kubelet process on each node uses this role to execute operations required for provisioning containers, such as pulling container images from Amazon ECR. Image pull authentication is handled by provider-specific binaries, called credential providers.
When a pod is being provisioned, the kubelet matches the image URI against its CredentialProviderConfig and invokes the corresponding credential provider binary. EKS nodes include the ecr-credential-provider with a baseline configuration that allows the kubelet to authenticate with ECR and pull container images using the node’s IAM role. Because the node IAM role includes ECR pull permissions by default, all pods on the node share the same access to ECR repositories.