Skip to main content

More Info:

Scan images being deployed to Amazon EKS for vulnerabilities.

Risk Level

Low

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 all registries your EKS workloads pull from
    • On any machine with kubectl access:
    • Extract the registry host for each image (text after // and before the first /, or before / if no //), e.g. 123456789012.dkr.ecr.us-east-1.amazonaws.com, docker.io, gcr.io.
  2. List all AWS ECR registries and repositories in your accounts
    • On any machine with AWS CLI configured:
    • Compare these to the registries found in step 1 to distinguish ECR vs non‑ECR sources.
  3. Define and document “approved registry” criteria and the allowed list
    • With your security/compliance team, decide: which AWS accounts/regions’ ECRs are allowed, and which third‑party registries (if any) are permitted and under what conditions (scanning enabled, private, signed images, etc.).
    • Write a short policy stating: “Only the following registries may be used for EKS workloads: …”.
  4. Evaluate current registry usage against the approved list
    • From the image list in step 1, mark each registry as: approved, candidate (needs review), or disallowed.
    • For AWS ECR registries:
    • Use this to check whether images from candidate/disallowed registries meet your security criteria (scanning, severity levels, etc.).
  5. Implement or tighten controls to enforce only approved registries
    • Using AWS IAM / Organizations (console, CLI, or IaC), adjust policies so that:
      • Only specific AWS accounts/roles can pull from approved ECR registries.
      • Pull/push actions to any non‑approved registries (e.g., internet egress) are restricted via IAM, VPC egress controls, or organizational SCPs.
    • Optionally, add admission controls (e.g., OPA/Gatekeeper, Kyverno) that deny Pods whose image registry is not in your approved list (implemented via your chosen IaC/tooling, not kubectl directly for the control plane).
  6. Verify and periodically review
    • Re-run the workload image inventory:
    • Confirm that all registries now appear on your approved list and that IAM/egress controls prevent use of unapproved registries. Repeat this review on a defined schedule (e.g., quarterly) or when adding new registries.
kubectl cannot be used to restrict or approve container registries for Amazon EKS, because this control is enforced at the cloud provider / managed control plane and IAM/ECR policy layer. Make the required changes in AWS (ECR, IAM, organization policies, and any admission controls configured via cloud tooling) as described in the Manual Steps section.
What output indicates a problem:
  • Any non-zero value for Non-approved image references in the “Summary” section.
  • Any rows printed under “Detailed non-approved image usage” (each row shows a namespace, workload, pod, container type, container name, and image whose registry does not match your approved registry prefixes).

Additional Reading: