Skip to main content

More Info:

Scan images being deployed to Amazon EKS for vulnerabilities.

Risk Level

High

Address

Security

Compliance 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

Manual Steps

  1. 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.
  2. 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.
  3. 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.
  4. 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) or ecr:* on that repo.
      • Confirm that principals listed match the expected roles/users from step 3.
  5. 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 (from aws ecr describe-repositories).
      • Prefer attaching policies to IAM roles used by EKS nodes/IRSA/CI, not directly to users.
    • 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.
  6. Verify minimized access and ongoing monitoring
    • Re-run IAM and ECR policy inspection to confirm no broad ecr:* or Resource: "*" 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.
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.

Additional Reading: