More Info:
Scan images being deployed to Amazon EKS for vulnerabilities.Risk Level
HighAddress
SecurityCompliance Standards
- APRA CPS 234 (Australia)
- BSI C5 (Germany)
- Brazil LGPD
- CCPA / CPRA (California)
- CIS Critical Security Controls v8
- CIS EKS
- CMMC 2.0
- CSA Cloud Controls Matrix v4
- DPDPA
- Digital Operational Resilience Act (EU)
- Essential 8
- ISO/IEC 27017
- ISO/IEC 27018
- ISO/IEC 27701
- KSA PDPL
- MAS Technology Risk Management (Singapore)
- MITRE ATT&CK (Cloud)
- NIS2 Directive
- NIST SP 800-171
- NYDFS 23 NYCRR 500
- SWIFT Customer Security Controls Framework
- Sarbanes-Oxley IT General Controls
- UK NCSC Cyber Assessment Framework
Triage and Remediation
- Remediation
Remediation
Manual Steps
Manual Steps
-
Inventory who can access ECR (users, roles, groups, policies)
- On any machine with AWS CLI configured for the account:
- In the AWS Console, go to IAM → Access analyzer → Policy analyzer and search for policies containing
ecr:actions.
-
Identify all IAM principals with ECR permissions and evaluate scope
- For each relevant IAM user, role, and group, on any machine with AWS CLI:
- For each policy found, retrieve and inspect it for
ecr:*or broad permissions:
- Flag policies that:
- Use
Action: "ecr:*"instead of specific actions. - Use
Resource: "*"instead of specific repositories. - Are attached directly to users instead of roles or groups.
- Use
-
Map ECR access to EKS usage and expected personas
- On any machine with kubectl access to the cluster, list namespaces and service accounts that pull images from ECR (assuming standard IAM roles for service accounts (IRSA) or node roles):
- In AWS Console, go to EKS → Clusters →
<your-cluster>→ Configuration → Compute and note:- Node instance profile IAM role(s).
- IAM roles used via IRSA (under Configuration → Access and by inspecting service account annotations).
- Verify that only:
- Node IAM roles and IRSA roles used by workloads require
ecr:GetAuthorizationToken,ecr:BatchCheckLayerAvailability,ecr:GetDownloadUrlForLayer,ecr:BatchGetImage. - Human users or CI roles with push rights are limited to specific repos and least-privilege actions.
- Node IAM roles and IRSA roles used by workloads require
-
Review ECR repository policies and public access
- On any machine with AWS CLI:
- In AWS Console, go to ECR → Repositories →
<REPO>→ Permissions and:- Ensure no public access unless explicitly required.
- Ensure repository policies do not grant wildcard principals (
"*"or wide account ranges) orecr:*on that repo. - Confirm that principals listed match the expected roles/users from step 3.
-
Tighten IAM and repository permissions (IaC/CLI/Console)
- For any over-privileged policies you identified:
- Replace
ecr:*with only the required actions. - Replace
Resource: "*"with specific ECR repository ARNs (fromaws ecr describe-repositories). - Prefer attaching policies to IAM roles used by EKS nodes/IRSA/CI, not directly to users.
- Replace
- Example of a read-only ECR policy document (adapt and apply via Console or IaC):
- Ensure only CI/CD or designated operators have push (
ecr:PutImage,ecr:InitiateLayerUpload, etc.) and that it is scoped to required repositories.
- For any over-privileged policies you identified:
-
Verify minimized access and ongoing monitoring
- Re-run IAM and ECR policy inspection to confirm no broad
ecr:*orResource: "*"remain except where justified:
- Optionally, enable or review AWS CloudTrail and Access Analyzer to:
- Confirm ECR is not accessed by unexpected principals.
- Detect unintended public or cross-account access.
- Re-run IAM and ECR policy inspection to confirm no broad
Using kubectl
Using kubectl
kubectl cannot be used to change Amazon ECR IAM permissions or access policies because this finding is entirely in the AWS cloud/provider configuration surface. Make the necessary changes using AWS IAM/ECR configuration via the AWS Console, CLI, or IaC, and refer to the Manual Steps section for detailed guidance.
Automation
Automation

