Skip to main content

More Info:

Configure Image Provenance for your deployment.

Risk Level

Low

Address

Security

Compliance Standards

  • CIS GKE

Triage and Remediation

Remediation

Manual Steps

  1. Review current admission configuration for ImagePolicyWebhook
    • On any machine with kubectl access, check whether an ImagePolicyWebhook admission configuration file is referenced in the API server flags (GKE Autopilot/managed control planes generally hide this, so this may not be visible):
    • Capture the output and look for any webhook explicitly dedicated to image provenance (for example, a name containing image-policy, imageprovenance, or your chosen image security tool).
  2. Identify and inspect any image-policy–related webhook
    • For each candidate webhook from step 1, describe it to confirm its purpose and scope:
    • Verify it is configured to intercept CREATE and preferably UPDATE operations on pods (and optionally deployments, daemonsets, etc.) and that it is reachable (no failing webhook calls reported in Events sections).
  3. Verify that image provenance checks are actually enforced
    • From the webhook descriptions in step 2, confirm that the webhook’s rules or configuration refer to image provenance or an external policy engine that validates image signatures, attestations, or trusted registries (for example, using cosign, Binary Authorization, or another signing/verification system).
    • If the webhook is only logging/monitoring and not rejecting non-compliant images, update its policy configuration (per your chosen image provenance solution’s documentation) so that it denies pod creation when images are not verified or are from untrusted sources.
  4. Deploy or integrate an ImagePolicyWebhook solution if none exists
    • If step 1 finds no suitable webhook, choose and deploy an image provenance solution that integrates via ImagePolicyWebhook or an equivalent admission webhook (for example, a tool that verifies image signatures/attestations). Follow that solution’s installation guide to:
      • Deploy the controller components (usually a Deployment/Service in a dedicated namespace).
      • Create a ValidatingWebhookConfiguration (and MutatingWebhookConfiguration if required) that targets CREATE (and UPDATE) of pods and relevant workload resources in all namespaces where enforcement is desired.
  5. Test enforcement using a non-compliant image
    • Attempt to create a pod using an image that should fail provenance checks (for example, an unsigned image or one from a disallowed registry):
    • Confirm that the pod creation is rejected with an admission error message from your image policy webhook indicating failed provenance/signature/attestation checks.
  6. Re-verify cluster-wide coverage and document the policy
    • Re-list webhook configurations to ensure your image provenance webhook is present and cluster-wide:
    • Confirm that:
      • All target namespaces and resource types are covered by the webhook’s rules.
      • The webhook’s failure policy and timeouts are set per your risk appetite (typically fail-closed for production).
    • Document the configured image provenance policy (what is required for images to be admitted, which registries/signers are trusted, and any exemptions) for future audits and change control.
What to look for (problem indicators)
  • On self-managed control planes, ImagePolicyWebhook is missing from the enabled admission plugins.
  • On fully managed GKE control planes you typically won’t see or be able to modify these flags; absence of ImagePolicyWebhook means it is not in use.

Problem indicators
  • No ConfigMap/Secret exists that appears to configure an image policy webhook, while your security policy requires image provenance enforcement.
  • Stale/unused webhook configs (e.g. legacy ConfigMap present but no corresponding admission plugin/webhook enabled).

Problem indicators
  • No webhook configuration with a purpose related to image validation/provenance (no mention of “image”, “cosign”, “notary”, “policy”, etc. in names/annotations).
  • Existing image-related webhook does not include pods in rules.resources and create/update in rules.operations.
  • failurePolicy: Ignore for a critical image provenance webhook (allows unverified images if the webhook is down, which may violate your policy).
  • namespaceSelector or objectSelector excludes namespaces where you expect image provenance to be enforced (e.g. default, prod-*).

Problem indicators
  • Images from untrusted/unapproved registries based on your organization’s policy.
  • Images without digests (e.g. :latest tags only), when your policy requires digests or signed images.
  • Wide variety of arbitrary public images, suggesting there is no enforcement on allowed sources or signatures.

Then check the result:
Problem indicators
  • Pod is admitted and runs successfully even though it clearly violates your defined image provenance policy (for example, untrusted public registry, unsigned image, tag-only).
  • No admission webhook-related events or error messages appear in kubectl describe pod, indicating no policy check occurred.

These commands surface:
  • Whether any admission mechanism that can enforce image provenance (ImagePolicyWebhook or equivalent webhook) appears to be configured.
  • Whether existing webhooks actually cover pod creations/updates.
  • How images are currently used, so a human can compare observed practice with the organization’s required image provenance policy.
Deciding whether the current configuration is acceptable, and what changes to make, requires human review against your organization’s security policy and the Kubernetes image provenance guidance.

Additional Reading: