More Info:
Configure Image Provenance for your deployment.Risk Level
LowAddress
SecurityCompliance Standards
- CIS GKE
Triage and Remediation
- Remediation
Remediation
Manual Steps
Manual Steps
-
Review current admission configuration for ImagePolicyWebhook
- On any machine with
kubectlaccess, check whether anImagePolicyWebhookadmission 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).
- On any machine with
-
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
CREATEand preferablyUPDATEoperations onpods(and optionallydeployments,daemonsets, etc.) and that it is reachable (no failing webhook calls reported inEventssections).
- For each candidate webhook from step 1, describe it to confirm its purpose and scope:
-
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.
-
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(andMutatingWebhookConfigurationif required) that targetsCREATE(andUPDATE) ofpodsand relevant workload resources in all namespaces where enforcement is desired.
- 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:
-
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.
- Attempt to create a pod using an image that should fail provenance checks (for example, an unsigned image or one from a disallowed registry):
-
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.
- Re-list webhook configurations to ensure your image provenance webhook is present and cluster-wide:
Using kubectl
Using kubectl
- 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
ImagePolicyWebhookmeans it is not in use.
- 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).
- 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
podsinrules.resourcesandcreate/updateinrules.operations. failurePolicy: Ignorefor a critical image provenance webhook (allows unverified images if the webhook is down, which may violate your policy).namespaceSelectororobjectSelectorexcludes namespaces where you expect image provenance to be enforced (e.g.default,prod-*).
- Images from untrusted/unapproved registries based on your organization’s policy.
- Images without digests (e.g.
:latesttags 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.
- 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.
Automation
Automation

