Amazon EKS Enforces Per-Pod ECR Pull Permissions to Strengthen Multi-Tenant Isolation

AWS announced native support for scoping Amazon Elastic Container Registry (Amazon ECR) image pull permissions directly to individual Kubernetes pods on Amazon EKS v1.35 and later. Historically, the kubelet authenticated with ECR using the underlying EC2 worker node's IAM instance profile. Because this node role required broad pull access to host workloads across multiple namespaces, any pod scheduled on that node could pull container images belonging to different teams or tenants. By operationalizing Kubernetes Enhancement Proposal (KEP) 4412—which brings per-pod projected service account tokens into the kubelet image-pull workflow—and combining it with Amazon ECR repository deny policies, platform administrators can now bind image-pull authorization directly to pod-specific IAM roles. This update solves a persistent operational pain point for platform engineering and enterprise security teams running shared multi-tenant clusters. Previously, enforcing strict image access boundaries required organizations to deploy fragile mutating/validating admission webhooks, maintain third-party Open Policy Agent (OPA) or Kyverno rules, or isolate teams entirely onto dedicated node groups. Dedicated node groups fragmented cluster compute, reduced bin-packing efficiency, and inflated cloud infrastructure spending. Per-pod image pull authentication preserves high node density while cryptographically ensuring that proprietary intellectual property, proprietary AI models, and sensitive enterprise binaries remain strictly accessible only to designated workloads. This shift reflects the broader industry convergence between cloud provider IAM frameworks and cloud-native runtime primitives. As Kubernetes matures into the default enterprise application substrate, coarse infrastructure-level security models (such as instance metadata and shared machine profiles) are systematically being dismantled in favor of fine-grained workload identities. Similar to how IAM Roles for Service Accounts (IRSA) and EKS Pod Identity replaced node-level IAM permissions for in-pod runtime AWS API calls, extending workload identity downward into the container bootstrap phase represents the final bridge toward complete zero-trust multi-tenancy. In practice, engineering teams should evaluate their existing EKS clusters running version 1.35 or newer and begin migrating away from overly permissive node-level ECR policies. Implementation requires configuring the AWS ecr-credential-provider on worker nodes and deploying ECR repository policies that explicitly deny pull actions unless the requesting identity matches the authorized workload's IAM role. Platform teams must account for initial rollout trade-offs: every tenant workload will need properly annotated Kubernetes Service Accounts linked to IAM trust policies, requiring tight coordination with application deployment manifests and GitOps pipelines.