# Ensure ECR repository policies do not allow public access - Source: https://support.icompaas.com/support/solutions/articles/a_1793292208591755-ensure-ecr-repository-policies-do-not-allow-public-access - Section: [Solutions](https://support.icompaas.com/support/solutions) › [AWS_Checks_v5.39.1](https://support.icompaas.com/support/solutions/c_1793285913477877) › [AWS Checks](https://support.icompaas.com/support/solutions/folders/f_1793287194371224) - Last updated: 2026-10-29 - Publisher: iCompaas, Inc. (https://www.icompaas.com) **Description** Ensure that no Amazon Elastic Container Registry (ECR) private repository has a repository policy that grants access to anonymous or public principals, such as "Principal": "\*" or "Principal": {"AWS": "\*"}. Such statements allow anyone to list, pull or even push and delete images in the repository. **Rationale** A repository policy that allows public access exposes container images, which may contain proprietary code, configuration or embedded secrets, to anyone. If push or delete actions are also allowed, attackers can replace images with malicious ones and compromise every workload that pulls them. Unrestricted pulls can also increase data transfer costs. Repository policies should grant only the minimum actions to specific AWS accounts, roles or users. **Impact** - Prevents anonymous users from pulling, pushing or deleting images - Protects image contents and the software supply chain from tampering - External accounts or services that currently pull images through the public statement lose access until they are granted access explicitly **Default Value** A new ECR repository has no repository policy. Access is then limited to IAM principals in the same account that are allowed by their own IAM policies. **Pre-Requisites** - IAM permissions: ecr:DescribeRepositories, ecr:GetRepositoryPolicy, ecr:SetRepositoryPolicy and ecr:DeleteRepositoryPolicy - A list of the AWS accounts, roles or users that legitimately need access to each repository **Remediation** **Test Plan** **Console:** 1. Sign in to the AWS Management Console at [https://console.aws.amazon.com](https://console.aws.amazon.com/). 2. Open the Amazon ECR console and select **Repositories** under **Private registry**. 3. Select a repository and open **Permissions** in the left menu. 4. Check for any statement with **Effect** Allow whose principal is \* or {"AWS": "\*"} and that has no condition limiting access to specific accounts, organizations or networks. 5. Repeat for each repository in each region in use. 6. If such a statement exists, follow the implementation steps. **CLI:** List the repositories in the region: aws ecr describe-repositories --region --query "repositories\[\].repositoryName" Show the policy of a repository: aws ecr get-repository-policy --region --repository-name --query policyText --output text A repository fails if its policy has an Allow statement with principal \* or {"AWS": "\*"} that is not restricted by a condition (for example aws:SourceAccount, aws:PrincipalOrgID, or aws:SourceIp with a private or trusted address range). Repositories without a policy (the command returns RepositoryPolicyNotFoundException) pass, because they have no statement granting public access. **Implementation Steps** **Console:** 1. Sign in to the AWS Management Console at [https://console.aws.amazon.com](https://console.aws.amazon.com/). 2. Open the Amazon ECR console and select **Repositories** under **Private registry**. 3. Select the repository and open **Permissions** in the left menu. 4. Choose **Edit policy JSON** (or **Edit**). 5. Remove each statement whose principal is \*, or replace the principal with the specific AWS account, role or user ARNs that need access, for example arn:aws:iam:::root. 6. Choose **Save**. 7. Repeat for each affected repository in each region in use. **CLI:** Remove the whole repository policy. This also removes any legitimate cross-account access granted in the policy, so use it only if no other statement is needed: aws ecr delete-repository-policy --region --repository-name To keep access for specific principals instead, save a policy such as the following as policy.json: {"Version":"2012-10-17","Statement":\[{"Sid":"AllowAccountPull","Effect":"Allow","Principal":{"AWS":"arn:aws:iam:::root"},"Action":\["ecr:BatchGetImage","ecr:GetDownloadUrlForLayer","ecr:BatchCheckLayerAvailability"\]}\]} Apply it to the repository (this replaces the existing policy): aws ecr set-repository-policy --region --repository-name --policy-text file://policy.json **Backout Plan** Before making changes, save the current repository policy: aws ecr get-repository-policy --region --repository-name --query policyText --output text > repository-policy-backup.json To roll back: 1. Sign in to the AWS Management Console at [https://console.aws.amazon.com](https://console.aws.amazon.com/). 2. Open the Amazon ECR console and select the repository. 3. Open **Permissions** and choose **Edit policy JSON** (or **Edit**). 4. Paste the policy from the saved backup. 5. Choose **Save**. **CLI:** aws ecr set-repository-policy --region --repository-name --policy-text file://repository-policy-backup.json Note: rolling back makes the repository publicly accessible again. Use it only as a temporary measure. **Reference** - [https://docs.aws.amazon.com/AmazonECR/latest/userguide/repository-policies.html](https://docs.aws.amazon.com/AmazonECR/latest/userguide/repository-policies.html) - [https://docs.aws.amazon.com/AmazonECR/latest/userguide/repository-policy-examples.html](https://docs.aws.amazon.com/AmazonECR/latest/userguide/repository-policy-examples.html) - [https://docs.aws.amazon.com/cli/latest/reference/ecr/set-repository-policy.html](https://docs.aws.amazon.com/cli/latest/reference/ecr/set-repository-policy.html) - [https://docs.aws.amazon.com/cli/latest/reference/ecr/delete-repository-policy.html](https://docs.aws.amazon.com/cli/latest/reference/ecr/delete-repository-policy.html) ## Related compliance guidance - [SOC 2 compliance: a practical implementation guide for cloud-native SaaS teams](https://support.icompaas.com/compliance/soc-2-trust-services-criteria): Configuration checks like this one are the technical half of a SOC 2 / ISO 27001 programme — the guide shows where they fit, what else an auditor expects, and how to evidence them. - [ISO/IEC 27001:2022 compliance: a practical implementation guide](https://support.icompaas.com/compliance/iso-27001-2022): ISO 27001 Annex A.8 (technological controls) is where cloud hardening evidence lands; the guide shows how to run the ISMS around it.