AmazonEC2ContainerRegistryReadOnly Policy is an IAM managed policy that grants read-only access to container registry content. It allows listing repositories and pulling images, but not pushing images or changing repository settings, so it is used for workloads and users that only need retrieval access.
What the policy does
AmazonEC2ContainerRegistryReadOnly is an AWS IAM managed policy for read-only interaction with Amazon Elastic Container Registry. It lets a principal discover repositories and pull container images, but it does not allow image pushes or repository administration, which makes it suitable for consumers that only need retrieval access.
Why read-only registry access matters
Read-only registry access is a common way to separate consumption from administration. By limiting a principal to listing and pulling, the policy reduces the blast radius if that principal is compromised and helps preserve registry integrity, because attackers or misconfigured automation cannot use the same access path to publish altered images.
That distinction matters in container supply chains, where a single pushed image can become trusted by downstream build, deployment or runtime systems. A read-only policy is therefore not just a convenience control, it is part of controlling who can introduce software into the registry and who can only consume it.
Where this policy fits in access design
This policy is best understood as a narrow entitlement, not a general container security control. It supports least privilege by giving workloads or users exactly the registry access they need, while leaving write, delete and settings management to separate administrative permissions.
In practice, teams often attach this kind of policy to build agents, deployment tooling, reporting jobs, or developers who need to inspect or pull approved images without changing them. The policy boundary is important because registry permissions are often reused across many automation paths, and overly broad access can quietly turn retrieval-only roles into change-capable roles.
Operational implications for consumers and administrators
Because the policy permits only read operations, failures usually show up as access denials when a principal tries to push or manage repositories. That makes it useful for separating day-to-day consumption from controlled release activity, especially where different teams own image production and image use.
Administrators still need to pair the policy with surrounding controls, such as repository governance, credential hygiene, and monitoring of who is pulling which images. Read-only access does not validate image provenance or trustworthiness, so it should be combined with image review and trusted publishing practices rather than treated as a complete assurance control.
When to use a read-only managed policy
Use a policy like this when a principal must pull container images but should not be able to alter registry content or configuration. That is usually the right choice for runtime consumers, inspection workflows, and other non-production paths where write access would create unnecessary risk.
A useful rule is to grant read-only access by default and add write permissions only where the business process genuinely requires them. That keeps the registry boundary clear, makes privilege reviews simpler, and reduces the chance that automation or human users inherit more authority than they need.
Risk and Threat Considerations
Registry read access becomes risky when it is assumed to imply trust. If an organisation treats “can pull” as “safe to deploy,” a compromised registry namespace, poisoned upstream image, or mistaken repository selection can move a malicious or incorrect image into downstream systems without any push permission on the consumer side.
Failure mechanism: The policy limits mutation of registry content, but it does not by itself verify image integrity, source provenance, or whether the pulled image is the expected one, so downstream systems may still consume harmful artefacts.
Impact: A compromised or incorrect image can propagate into builds, deployments, and runtime environments, creating code execution, persistence, or service disruption even though the consumer only had read-only registry access.
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 | AC-6 — Least Privilege | Limits registry access to retrieval-only use cases and separates read from write authority. |
| IA-5 — Authenticator Management | Registry read access depends on managed credentials or tokens that must be controlled lifecycle-wide. | |
| Recommendation — Apply AC-6 to restrict principals to the minimum registry permissions they need. Manage and rotate the credentials that authorize registry access. | ||
| CIS Controls v8 | CIS-6 — Access Control Management | Use roles and access boundaries to separate image consumption from repository administration. |
| Recommendation — Separate read-only registry access from publishing and administrative access. | ||
| OWASP Non-Human Identity Top 10 | NHI-05 — Overprivileged NHI | Workload and automation identities pulling images should not also hold write privileges. |
| NHI-02 — Secret Leakage | Registry access for consumers still depends on credentials and tokens that can be exposed. | |
| Recommendation — Review non-human identities for unnecessary registry write permissions. Protect the secrets used to authenticate registry pulls. | ||
Practitioner Guidance
Governance implication: Treat this policy as a narrowly scoped consumption entitlement and review it as part of broader registry governance, not as a standalone trust control. The main decision is whether the principal truly needs image retrieval only, or whether a separate workflow should be used for publishing and administration.
What to watch for: Watch for reuse of the policy in automation that later acquires broader registry needs, because read-only access often becomes a hidden default. When that happens, create a separate role for publishing rather than expanding the read-only grant in place.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on November 3, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org