Key Management for Trust Pinning

[xopham]

Hi,
thanks for the great tool 🥳 It provides great usability for one of the major weak spots of container images 👍

I was wondering how to implement simple key management (though mentioned as out-of-scope in the docs 😜 ), specifically key hierarchy to facilitate trust pinning with delegation and key rotation. In case of TLS, there is infrastructure (PKI) parallel to transparency logs (t-logs) to achieve this...though it's brittle. Notary v1, provides a root key and one can pin to the associated public key. The root key may be used to create and manage the lifecycle of delegations which are then used to sign the actual targets that are in turn validated against the root pubkey. This facilitates collaboration and key rotation without service interruption or manual effort for clients.

Cosign does currently not seem to implement such key management (KMS). Without going into too much detail, I would see 3 options to achieve it:

• Trust the t-logs: Grab the current valid pubkey for images from the t-log. However if I understand correctly, the t-log does not check the validity of a key, just makes it transparent which allows for audit and identification of unauthorized keys. That would require maintainers to check the log and is by definition always after the fact.
• Implement KMS in t-logs: Have a root key to sign delegations, push that to t-log and grab valid public keys for cosign just before verification. This appears a bit unnatural and hacked.
• Use cosign annotations: A signature of the delegation by a root key for the used key and image could be added as an optional parameter (using the -a flag) to the image signature, freshness could probably be guaranteed via t-logs.

Is there a more natural solution how to achieve this in cosign or is it permanently considered out of scope? I think KMS would be a major step to making signatures even more seamless and useful...
Thanks again for the awesome tool 💪

[dlorenc]

Hey! Thanks for asking! This is probably too tough of a topic to completely handle via a github issue, but I'll point you at a few of the options. We're not going to prescribe a single one in cosign, but we'll have a few supported flows and let you build your own.

Here's what we're working towards:

• No key management at all! Generate a key with cosign, sign with it, distribute it however you want. You can use this to build other workflows if you want.
• Bring your own certificate/root certs. See here for the tracking issue Managing/configuring root certs for fulcio #87. You could keys and certs from whatever CA you want, and then configure cosign to trust that root.
• Automatic certs! Cosign will have the ability to trust our transparency logs and root certificate!

Then for a final option with delegations, we're planning to make it possible to use cosign to manage TUF metadata and delegations. See here: #86

[dlorenc]

I think this is fixed now! Are we missing anything still @xopham ?

[xopham]

I am not entirely certain. I think the issue comes from a different time 😅
Is there a way to have actual delegation w/o OIDC?

[github-actions]

This issue is stale because it has been open 60 days with no activity. Remove stale label or comment or this will be closed in 5 days.

[github-actions]

This issue was closed because it has been stalled for 5 days with no activity.