# Ensure there are no ECR repositories set as Public

- Source: https://support.icompaas.com/support/solutions/articles/62000236267-ensure-there-are-no-ecr-repositories-set-as-public
- Section: [Solutions](https://support.icompaas.com/support/solutions) › [AWS Checks New Version](https://support.icompaas.com/support/solutions/62000112673) › [AWS New Checks](https://support.icompaas.com/support/solutions/folders/62000169206)
- Last updated: 2026-05-29
- Publisher: iCompaas, Inc. (https://www.icompaas.com)

**Profile Applicability:**  
Level 1  
  

**Description:**  
This control ensures that Amazon Elastic Container Registry (ECR) repositories are not publicly accessible. Publicly accessible ECR repositories allow anyone on the internet to pull container images without authentication, which can expose sensitive application components, proprietary software, or configuration data. Restricting repository access to authorized users and AWS accounts helps maintain the confidentiality and integrity of container images.  
  

**Rationale:**  
Container images often contain sensitive data such as proprietary code, internal configurations, credentials, or dependencies with specific vulnerabilities. If repositories are made public, attackers can access these images, analyze them for weaknesses, and exploit potential security flaws. Ensuring ECR repositories are private aligns with the principle of least privilege and reduces the risk of supply-chain attacks, data breaches, and unapproved software distribution.  

**Impact:  
Positive Impact:**

-   Prevents unauthorized public access to container images.
    
-   Protects intellectual property and sensitive data.
    
-   Reduces the risk of supply-chain compromise or image tampering.  
    Negative Impact:
    
-   Developers or partners who legitimately require access must use proper IAM or cross-account permissions.  
      
    

**Default Value:**  
By default, ECR repositories are private when created. Public access must be explicitly configured using the AWS CLI, SDK, or console.  
  

**Pre-Requisite:**

-   IAM permissions required: `ecr:DescribeRepositories`, `ecr:GetRepositoryPolicy`, and `ecr:SetRepositoryPolicy`.
    
-   Awareness of which repositories require cross-account access to avoid unnecessary restriction.  
      
    

**Test Plan** **Using AWS Console:**

1.  Sign in to the AWS Management Console.
    
2.  Navigate to Amazon ECR → Repositories.
    
3.  Check the Visibility column for each repository.
    
4.  Ensure that all repositories display Private under Visibility.
    
5.  For detailed review:
    
    -   Select a repository and open the Permissions tab.
        
    -   Review the Repository policy.
        
    -   Confirm that no statements allow public access (e.g., `"Principal": "*"`, `"Effect": "Allow"`).
        
6.  If any repository is marked as Public, or if its policy includes unrestricted access, it is non-compliant.  
      
    

**Implementation Plan** **Using AWS Console:**

1.  Navigate to Amazon ECR → Repositories.
    
2.  Select the repository that is public or has an overly permissive policy.
    
3.  Click Edit and set Visibility to Private.
    
4.  Under the Permissions tab, review the Repository policy.
    
5.  Remove any statements that include `"Principal": "*"`.
    
6.  Restrict access using IAM users, roles, or AWS account IDs that require it.  
    `   `
    

**Backout Plan:**

1.  If removing public access disrupts legitimate workflows (e.g., partner integrations or public container distributions):
    
    -   Revert visibility to Public temporarily while implementing scoped access using signed URLs or IAM role-based permissions.
        
2.  Document and review all exceptions through your organization’s change management process.  
      
    

References:

-   Amazon ECR Repository Policies
    
-   Amazon ECR Security Best Practices
    
-   CIS AWS Foundations Benchmark v2.0.0 – Control 3.37
    
-   AWS Security Best Practices Whitepaper

## 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.