Security teams should start with least privilege and grant the service account only the permissions required for image pull and deployment. For EKS workloads, that usually means read-only access to Amazon ECR rather than broader registry or cluster rights. Limiting scope reduces the blast radius if credentials are exposed, reused, or abused outside the intended workload.
Why Kubernetes service accounts for pull-only EKS workloads should stay narrow
A pull-only workload should not be treated like a general cluster actor. If the pod only needs to fetch images, the service account should be scoped to that narrow use case and separated from broader runtime, deployment, or cluster-admin permissions. The practical goal is to keep image access functional while preventing that identity from becoming a path to wider platform reach.
For container-platform readers, the important distinction is between container registry and runtime risk and ordinary application permissions. Image pull is a tightly bounded operation, so permissions should reflect repository read access, token scope, and only the minimum AWS IAM relationship needed for EKS to authenticate to Amazon ECR.
That narrow design matters because service accounts are often copied, reused, or inherited across environments. A permission set that is harmless for pulling a public or internal image can become a general-purpose credential if it also reaches unrelated APIs, deployment actions, or other AWS resources. Keeping the scope small also makes it easier to reason about who can change the workload’s access path.
What “read-only” really means for EKS to ECR access
In practice, “read-only” means the workload can obtain an authorization token and pull the specific images it needs, but cannot push, mutate repository settings, or act beyond the registry boundary. On AWS, that usually points to a role or policy designed for ECR read actions, attached through the EKS identity path you use for pods, rather than granting a broader IAM policy to a namespace or cluster role.
If the workload only needs to start successfully, it does not need registry administration, broad AWS account permissions, or Kubernetes permissions unrelated to image retrieval. The service account should not be the mechanism for application deployment rights, cluster object modification, or cross-environment access. That separation keeps the image-pull function narrowly tied to the workload’s runtime need.
At the identity layer, the same principle appears in workload identity guidance: a pod identity should be specific to the workload and constrained to the audience, resource, and action it actually requires. A good control is to verify that the credential or role used by the pod can only support image retrieval and nothing else. See also SPIFFE workload identity specification for the broader idea of tightly scoped workload identity and trust boundaries.
How teams should enforce the boundary in EKS
The cleanest pattern is to give the pod only the identity needed to authenticate for ECR pulls, then validate that the kubernetes service account does not inherit extra cluster privileges. If the cluster uses IRSA or a comparable workload-identity approach, the trust relationship should be constrained so the pod can assume only the intended AWS role, and that role should contain only the ECR read actions required for image access.
Teams should also keep the workload identity path separate from deployment automation. A system that pulls an image at runtime does not need the ability to update the deployment object, read unrelated secrets, or modify node-level configuration. The smaller the permission surface, the easier it is to detect when something unusual happens, such as the same identity being used from a different namespace or for a different repository.
This is where Kubernetes NHI Security Guide is useful for the pod-identity and token-boundary view, and Cloud Workload Identity Guide is useful for the AWS-side role and temporary-credential model. Together they reinforce the same practitioner rule: keep the workload’s identity tightly coupled to the specific access path it actually needs.
Risk and Threat Considerations
Pull-only credentials are attractive because they are often treated as low risk and then quietly reused. If that identity is overprivileged, stolen from the pod, or exposed through misconfiguration, an attacker can use it to pivot beyond image retrieval into broader AWS or Kubernetes actions. The danger is not the image pull itself, but the fact that the same identity may become a reusable foothold.
Failure mechanism: The service account or linked AWS role is granted more than ECR read-only access, or the same identity is reused across workloads and environments, so compromise of the pod credential opens a wider blast radius than intended.
Impact: Attackers or accidental misuse can reach repositories, cluster resources, or adjacent AWS services that were never required for the workload, which increases exposure, weakens traceability, and makes containment harder.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 addresses the attack and risk surface, while NIST SP 800-53 Rev 5 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | IA-9 — Service Identification and Authentication | EKS pod-to-AWS authentication for image pulls depends on service/workload identity. |
| AC-6 — Least Privilege | The question is fundamentally about restricting permissions to only what image pull requires. | |
| IA-5 — Authenticator Management | Pull access depends on credentials, tokens, or trust material that must be constrained and managed. | |
| Recommendation — Use IA-9 to scope pod authentication to the minimum AWS role needed for ECR pulls. Apply AC-6 to remove nonessential cluster and AWS permissions from the workload identity. Use IA-5 to limit, rotate, and tightly manage the credential path used for registry access. | ||
| CIS Controls v8 | CIS-6 — Access Control Management | Restricting a workload to read-only registry access is an access-control problem. |
| Recommendation — Use CIS-6 to enforce the smallest feasible access set for the workload identity. | ||
| OWASP Non-Human Identity Top 10 | NHI-05 — Overprivileged NHI | A pull-only service account becomes risky when granted broader permissions than image retrieval needs. |
| NHI-07 — Long-Lived Secrets | Registry access often fails when static credentials persist longer than the workload needs. | |
| Recommendation — Remove nonessential permissions so the workload identity cannot act beyond image pull. Prefer temporary, narrowly scoped credentials over long-lived registry secrets. | ||
Practitioner Guidance
What to verify: Confirm the pod’s identity can only pull the specific images it needs and cannot push, administer repositories, or call unrelated AWS or Kubernetes APIs. Check the effective permissions, not just the intended policy, because inheritance and cross-role trust often create the real exposure.
Common mistake: Teams often grant a broad registry or cluster role “just to make the deployment work,” then leave it in place after the workload stabilises. That shortcut usually creates the exact overreach that least-privilege design was meant to avoid.
What good looks like: The workload has a distinct service account, a narrowly scoped AWS role, and observable evidence that image-pull activity is the only successful use case. If the same credential can be used outside that narrow path, the boundary is already too loose.
Practitioner takeaway: Treat pull-only access as a bounded runtime capability, not a general-purpose workload identity, and keep the identity narrow enough that compromise does not turn image retrieval into platform control.
Related resources from NHI Mgmt Group
- How should security teams reduce the risk of Kubernetes service account tokens?
- How should security teams replace static service account keys in cloud workloads?
- How should security teams restrict Vertex AI service agents without breaking workloads?
- Why do Kubernetes environments with ephemeral workloads and service account sprawl create more security risk?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 29, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
