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 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

Manual Steps

  1. 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.
  2. Determine clusters and projects where Binary Authorization should be enforced
    • On any machine with gcloud configured:
    • 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).
  3. Review current Binary Authorization configuration and policy (if any)
    • On any machine with gcloud configured:
    • Inspect current-binauthz-policy.yaml to see whether it exists and whether any admissionRule or defaultAdmissionRule references constraints on image registries (e.g., via attestor requirements or image pattern constraints).
  4. Design or update the approved-registry policy
    • Using the exported current-binauthz-policy.yaml as 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).
    • 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., alwaysDeny for strict enforcement, or attestation-based exceptions).
  5. Enable Binary Authorization on the cluster and apply the policy
    • On any machine with gcloud configured:
    • 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.
  6. Verify that only approved registries are allowed going forward
    • On any machine with gcloud and kubectl configured:
    • Confirm that the unapproved image is rejected by admission control and that the approved image runs successfully, then remove the test pods.
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.

Additional Reading: