Track flipping default securityPolicyFlavour from "insecure" once guest-components#1398 / image-rs#9 land

[butler54]

Summary

coco-pattern currently defaults securityPolicyFlavour: insecure (see .planning Phase 20b research / values-*.yaml), meaning container image signature verification (cosign/sigstore, Red Hat GPG) is not enforced by default. This is a deliberate, upstream-blocked decision — not an oversight — but there's currently no tracking mechanism inside coco-pattern to revisit it once the blocker clears.

Why insecure is the default today

Two upstream confidential-containers/guest-components (image-rs) gaps prevent enabling signature verification by default:

1. cosign/sigstore keyData is not base64-decoded by image-rs's policy engine, breaking Red Hat sigstore signature verification. Tracked upstream: confidential-containers/guest-components#1398.
2. No HTTP/HTTPS lookaside signature-store support in image-rs, which blocks GPG-based Red Hat signature verification. Tracked upstream: confidential-containers/image-rs#9.

Both are already filed and tracked upstream — this issue is not re-reporting either bug.

Ask

Add a lightweight tracking mechanism (this issue, plus ideally a code comment pointing to it in the values files / charts/all/coco-kyverno-policies) so that once guest-components#1398 and/or image-rs#9 land and are validated against coco-pattern, someone actually flips the default securityPolicyFlavour away from insecure for the relevant topologies. Today there is no reminder anywhere in the pattern itself that this is pending — it's easy for this to be forgotten once the upstream fix ships, since nothing in coco-pattern's CI/values would prompt a revisit.

References

• Upstream tracking: confidential-containers/guest-components#1398, confidential-containers/image-rs#9
• Blocker analysis in coco-gsd planning history: .planning/phases/06-container-signing-policy-enforcement/06-BLOCKER.md, 06-BLOCKER-ANALYSIS.md