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 GKE
- 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
-
Identify all container registries currently in use
- On any machine with access to the project:
- Compare the resulting list of registries (e.g.,
gcr.io,us-docker.pkg.dev,docker.io, others) to your organization’s approved registry list.
- On any machine with access to the project:
-
Determine clusters and projects where Binary Authorization should be enforced
- On any machine with
gcloudconfigured: - For each cluster in scope, decide whether all workloads must be restricted to approved registries or whether exceptions are required (e.g., third‑party images that cannot be mirrored).
- On any machine with
-
Review current Binary Authorization configuration and policy (if any)
- On any machine with
gcloudconfigured: - Inspect
current-binauthz-policy.yamlto see whether it exists and whether anyadmissionRuleordefaultAdmissionRulereferences constraints on image registries (e.g., via attestor requirements or image pattern constraints).
- On any machine with
-
Design or update the approved-registry policy
- Using the exported
current-binauthz-policy.yamlas a base (or the reference YAML in the Binary Authorization Policy Reference), decide:- Which registries (e.g.,
gcr.io/ORG/*,us-docker.pkg.dev/PROJECT/*) are allowed. - Whether images from unapproved registries should be blocked or only warned (for initial rollout).
- Which registries (e.g.,
- Edit a local policy file, for example:
- In that file, define or adjust admission rules to require that images match only the allowed registry patterns, and decide what to do with non-matching images (e.g.,
alwaysDenyfor strict enforcement, or attestation-based exceptions).
- Using the exported
-
Enable Binary Authorization on the cluster and apply the policy
- On any machine with
gcloudconfigured: - Be aware that tightening the policy can cause new pod creations or updates using disallowed registries to be rejected; plan for staged rollout and testing.
- On any machine with
-
Verify that only approved registries are allowed going forward
- On any machine with
gcloudandkubectlconfigured: - Confirm that the unapproved image is rejected by admission control and that the approved image runs successfully, then remove the test pods.
- On any machine with
Using kubectl
Using kubectl
kubectl cannot configure which container registries are allowed for image pulls or enable Binary Authorization; this control is managed at the GKE control‑plane / project level via gcloud, the GCP console, or IaC. Refer to the Manual Steps section for the exact
gcloud commands and policy configuration needed to restrict registries.Automation
Automation

