How do you verify images from one vendor signing with its own x.509 CA and another signing keylessly?
answer
- Two roots of trust, not one
- Installed CA versus identity provider
- Scope each vendor to its own repositories
- Referrers versus a derived signature tag
- Revocation lists versus short-lived certificates
basics
~10 sTwo trust models means two policy entries, scoped per repository. Notation matches an x.509 trust store and permitted certificate subjects; Sigstore-style verification matches an OIDC issuer and identity. Kyverno's verifyImages can express both styles.
solid answer
~50 sThese are different signature formats and different trust roots, so you need a verifier that can hold both and, crucially, scope each to its own repositories. For the CA-based vendor, Notation's trust policy is the natural fit: install the vendor's CA into a trust store, restrict acceptance to the certificate identities that vendor actually signs with, and scope the rule to that vendor's registry paths. For the keyless vendor, Sigstore-style verification matches an OIDC issuer plus an expected identity from the signing certificate. Kyverno's `verifyImages` can select either verification style per rule, so both can live in one policy set; Sigstore's policy-controller covers the keyless side natively. Two things bite in practice: the signature formats are discovered differently in the registry, so mirrors that drop referrers break one vendor and not the other, and revocation works differently — CRL or OCSP against a long-lived chain versus short-lived certificates plus a transparency-log record of when signing occurred.
go deeper
Know that there is more than one signing model: certificates chaining to a CA someone installed, and keyless signatures tied to an identity from an identity provider. They are not interchangeable.
Explain what trust material each model needs and where a verifier finds the signature — referrers attached to the manifest versus a separate artifact under a derived tag — and why a mirror can break one and not the other.
Show you scope each vendor's trust anchor to that vendor's repositories, test the re-hosting copy path for both formats, and have a stated position on revocation reachability failing open or closed.
Own the supplier conversation: which signing model you require of new vendors, what you accept from incumbents, and how long an unsigned-vendor exception is allowed to live before it becomes a contractual issue rather than a policy one.
## Two suppliers, two trust models, one cluster A cluster that runs third-party images almost never gets one signing model. One vendor operates a PKI and signs with certificates chaining to its own CA. Another builds in public CI and signs keylessly against a public identity provider. Both are legitimate; they are not interchangeable, and the verifier you pick has to hold both without letting either vouch for the other's images. ## What each model gives the verifier **CA-chained x.509.** Trust flows from a root you installed. The verifier checks the certificate chains to that root, is within validity, is not revoked, and that the certificate subject is one you permit. Notation expresses this directly: a trust store holding the CA material, `trustedIdentities` narrowing to particular certificate subjects under it, registry scopes limiting where the rule applies, and a verification level controlling how strictly the individual validations are enforced. Operationally this is classic PKI: you must receive the vendor's roots through a channel you trust, and you must handle their rotation. **Keyless.** Trust flows from an identity provider rather than a vendor-run CA. The verifier matches the OIDC issuer and the identity in the signing certificate against what you accept, and consults the transparency log to establish that the signature was made at a point consistent with that certificate. There is no per-vendor root to distribute — a real operational saving — but the acceptance decision is now a string identity, and getting that string subtly wrong (a wildcard too broad, an issuer unpinned) accepts far more than intended. ## Holding both **Kyverno.** A `verifyImages` rule selects the verification style, Sigstore-style or Notary-style, with attestor material matching that style. Two rules, two `imageReferences` scopes, one policy engine. **Sigstore policy-controller.** A `ClusterImagePolicy` matches images by glob and lists authorities as keys or keyless identities. It is the natural home for the keyless vendor. A separate CA-chained signature format is outside what it was built to verify. **Notation.** Trust policies scoped by registry, chaining to CAs you install. The natural home for the PKI vendor, and no help at all with a keyless identity. The common mistake is not picking wrong; it is writing one broad rule and letting both trust models apply to every image. Then vendor A's CA can vouch for images in vendor B's repositories. Scoping by registry or repository path is not tidiness here, it is the containment boundary: each supplier's trust material should be able to speak only for that supplier's namespace. ## Where the signatures live The formats also differ in *discovery*. Notation attaches signatures as OCI referrers of the subject manifest; cosign has historically published a signature as a separate artifact under a tag derived from the subject digest. Consequences you will actually hit: a registry or mirror that does not implement the referrers API makes correctly signed artifacts appear unsigned, and a copy operation that moves manifests without their referrers silently strips signatures on the way into your internal registry. If you re-host vendor images — most regulated estates do — the copy step is where signatures go missing, and the symptom looks exactly like a vendor that failed to sign. ## Revocation and rotation With long-lived certificates you inherit revocation infrastructure: CRL or OCSP reachable from wherever verification runs, and a decision about what happens when it is not reachable. Fail open and revocation is decorative; fail closed and a network problem stops deployments. With short-lived certificates, the freshness question is handled differently — the transparency log record is what establishes signing time — but you now depend on a public log being reachable and on the trust root material for that ecosystem being current. ## The answer worth giving Name the four axes and the interviewer knows you have done this: **trust material** (installed CA versus identity provider), **format and discovery** (referrers versus derived tag), **scope** (each vendor's trust bound to their repositories only), and **freshness** (revocation checks versus short-lived certificates plus a log). Then say what you cannot fix: the vendor who signs nothing at all. That is not a verifier capability question, it is a procurement one, and pretending a policy will solve it is how permanent exceptions get created.
- You re-host both vendors' images in an internal registry. What breaks?Signatures, quietly. A copy that moves the manifest without its referrers strips referrer-attached signatures, and a target registry that does not implement the referrers API cannot hold them at all. Verification then fails as if the vendor never signed. Test the copy path for both formats before enforcement, and treat signature-preserving copy as a requirement on the internal registry.
- Why is one broad rule covering both vendors dangerous even if both trust anchors are legitimate?Because trust becomes transitive across suppliers: vendor A's CA can vouch for images in vendor B's repositories, so compromising the weaker vendor's signing path lets it sign artifacts in the stronger one's namespace. Scoping each trust anchor to its own registry paths keeps a supplier compromise inside that supplier's blast radius.
- What do you do about revocation reachability for the CA-based vendor?Decide explicitly and write it down. If revocation checks fail open, a revoked certificate still verifies and the check is decorative; if they fail closed, an outage at the vendor's revocation endpoint halts your deployments. Most estates fail closed in production with a documented break-glass path, and monitor reachability so the failure is diagnosed as network rather than attack.
saying these in an interview costs you the question
- Assumes one verifier covers every signature format
- Applies both trust anchors globally instead of per repository
- Thinks a keyless identity can be added to a CA trust store
- Ignores that copying images can strip attached signatures
- Treats revocation as solved without saying fail open or closed