More Info:
Scan images being deployed to Amazon EKS for vulnerabilities.Risk Level
LowAddress
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 all registries your EKS workloads pull from
- On any machine with
kubectlaccess: - 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.
- On any machine with
-
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.
- On any machine with AWS CLI configured:
-
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: …”.
-
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.).
-
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
kubectldirectly for the control plane).
- Using AWS IAM / Organizations (console, CLI, or IaC), adjust policies so that:
-
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.
- Re-run the workload image inventory:
Using kubectl
Using kubectl
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.
Automation
Automation
- Any non-zero value for
Non-approved image referencesin 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).

