By default, the sigstore policy-controller rejects any image that does not match a policy when no-match-policy is not configured. Namespaces must also opt in with a label. You can set no-match-policy to warn, allow or deny, so decide it deliberately before enabling enforcement.
How the pieces fit
A ClusterImagePolicy applies to images whose digests match glob patterns in its spec. When several policies match one image, all must pass. Within a policy, authorities are OR'd, so one passing authority is enough. The controller checks signatures and attestations.
Enforcement is opt in per namespace. The docs say to add the label policy.sigstore.dev/include with the value true to the namespaces you want checked. Opt out is possible by changing the webhook configuration, and the docs warn that this can affect system namespaces.
The no-match setting
| Setting | Effect for an image no policy matches |
|---|---|
| deny | Rejected |
| warn | Allowed with a warning |
| allow | Allowed |
| not configured | The docs say it is rejected |
Why this catches teams out
A team labels a namespace, creates one policy for their own registry, and then a third party image or a sidecar injected by another tool is blocked because no policy covers it. The cluster outage is a policy gap, not a bug.
A safe rollout
- Inventory the images running in the target namespace, including sidecars and init containers.
- Write policies for each registry you trust, with the identity you expect.
- Set no-match-policy to warn first and read the warnings.
- Move to deny once the warnings are gone.
- Label namespaces one at a time, starting with a low risk one.
See also roll out admission policy with warn and audit first.
What to put in the first policy
Start with the registry paths your team already pulls from. Use glob patterns that match the repository and not just a single tag, because the controller matches image names in the policy and then checks the signature on the digest. Add an authority that names the identity you expect to see on the signature. Keep one policy per trust relationship, such as one for your own build pipeline and one for each upstream publisher, so a failure message points to a single cause.
Remember the rule for combined policies: if two policies match the same image, both must pass. A broad policy with a strict authority and a narrow policy with a different authority can make an image impossible to admit. Test combinations in a scratch namespace.
Warn mode on a single policy
Each ClusterImagePolicy also has a mode. The docs say that setting the mode to warn lets non compliant images through and emits a warning instead of blocking. That is useful for a new policy, and it is separate from the no-match setting, so check both.
Try it yourself
Try it yourself
Click through it at your own pace, or open it full screen. Watch how a gate decides pass or block, and compare that with an admission decision at deploy time.
Quick check
Does the controller check running pods or new ones?
It acts at admission, so it evaluates workloads when they are created or updated.
Can a tag be swapped after admission?
The docs say the controller resolves tags so the image that runs matches what was admitted.
Safeguard policies, gates and guardrails apply rules earlier, in the pull request and pipeline, and a free scan is at https://gold.safeguard.sh/scan.
Sources
Last reviewed: 19 October 2026.
