Cosign/TUF integration
mnm678 opened this issue · comments
As mentioned in the README, cosign can be used to store TUF metadata on a registry. This TUF metadata can secure the tag to digest relationships on the registry, define trust delegations, and provide compromise resilience in the case of a registry or infrastructure compromise. It would be nice to get a working prototype of this integration, possibly leveraging existing TUF implementations such as go-tuf.
As I envision it, a TUF/cosign integration would involve:
[x] Storing TUF metadata on a registry using cosign
[] Ensuring easy querying of that TUF metadata by users, ideally using a human-readable name
In the future, this could lead to more sigstore integration, for example:
[] Allowing TUF targets metadata to delegate to a fulcio identity
[] Supporting TUF root key discovery through a threshold of fulcio servers
[] Publishing TUF metadata to rekor for an immutable history
This sounds awesome! How can we help?
I'll play more with storing TUF metadata using cosign this week, but I think the biggest issue there will be the discoverability of the metadata. So one place I could use some help is a mechanism to query cosign objects by some kind of deterministic name (ie 'root' for root metadata).
For the future steps, allowing storage of the TUF metadata in rekor would require support for either arbitrary data added to the TL or support specifically for TUF metadata (I imagine the former would be easier).
Could you outline a bit more @mnm678 what would constitute arbitrary data , we might be able to accommodate that with rekor types, but I guess it depends on how arbitrary we are talking?
Sorry! Missed this reply.
Depending on how much TUF metadata there is, we can store it as a custom object in cosign. Right now we hardcode the "cosign signature object" type in the redhat simple signing object, but don't really do much else to look at that field.
We could make that configurable and queryable pretty easily, if the TUF metadata can fit into the optional section.
The metadata should be able to fit into the optional section (I'm working on a PoC for that). It's just json with a specific set of fields (example from the TUF spec).
The only caveat is that not every piece of TUF metadata would be directly associated with an image, so the 'image' field in the simple signing object doesn't make as much sense.
Makes sense! I'm hoping to switch the simple signing field to something less Docker and image specific. Do you think the OCI Descriptor type would work?
@mnm678 and I sketched out a potential UX in a google doc earlier today. The idea is that someone would protect an entire "repository" with TUF, using cosign commands. The doc is here, shared with the sigstore-dev group.
Still undecided: it could be a subcommand under cosign (cosign tuf ...), or a separate top-level command that reuses the cosign components. I don't really have an opinion either way. I think if we can come up with a good pun for the name that would be enough to sway it either way :)
If we make this a sub-command of cosign, let's be sure to include tuf- in each command name and be consistent in the placement i.e tuf-initialize, tuf-sign, tuf-verify, etc. vs. initialize-tuf, tuf-sign, snapshot.
Given the thresholds/quorum of signatures in tuf, co-sign is actually a good name for a tuf signing tool. Pun name based on quorum; quorsign? (That bad suggestion may just sway it towards subcommands of cosign)
we should also keep in mind the other tools we have (albeit still a WIP):
- rubygems-sigtore
- bobs maven sigstore client
- sigstore/sigstore (general client that signs everything else).
@lukehinds I was thinking about the other formats and clients. I've convinced myself that I don't think TUF can be done generically, it's too coupled to the storage layer.
Even the formats like ruby and jars where we have a place to stick signatures won't really work because you need a place to store them across multiple artifacts.
This is probably the wrong place to track this discussion, but I had an interesting idea I want to document somewhere about merging the TUF delegation with Fulcio as a root of trust. Some of the complexity involved in setting up a TUF repo is managing the root keys, rotation and delegation. Fulcio doesn't directly solve those problems, but could provide an alternative model that is simpler (albeit with some security tradeoffs).
I'm imagining something like this:
A "hybrid TUF" flow, where we'd have:
- No root keys for a repo, instead we would trust the Fulcio root of trust. Fulcio's root certs would handle rotation for users. The root metadata would instead include a list of OIDC ids, rather than raw keys.
- Further delegations could then be based off of OIDC ids, rather than raw public keys as well.
Basically, everywhere we talk about keys and chains of keys in the TUF design above, we could drop that and write policy in terms of raw OIDC ids. Fulcio would handle rotating credentials for those OIDC users through it's root cert.
At a super high level, you could create a repo with roles like this:
Repo: gcr.io/hybrid-tuf
Root users: dlorenc@google.com, mnm678@gmail.com, lhinds@redhat.com..., with a policy requiring 2 out of 3 for delegations and new roots.
Snapshot users: jonjohnson@google.com, ahmetb@google.com, jasonhall@redhat.com, where any of these individuals can sign a snapshot
Timestamp users: somesystemaccount.sigstore.dev, where we'd have an automated system identity perform timestamps
Target users: ...
Does that make sense at all? I think the big tradeoff here is that you would be outsourcing the Root of Trust to Fulcio (which would be using TUF itself to protect that root). But, the threat model for the entire fulcio system is trusted-but-verifiable, so this may be a reasonable tradeoff for many organizations.
This is an interesting idea! One place it may make sense to capture this is in a TAP (and I would willing to collaborate on one) documenting Fulcio/sigstore/TUF interactions – an initial idea for that TAP could be captured in the issue tracker.
I've been thinking of a less complete version of this for PEP 480 whereby individual developer signing delegations could be to an OIDC and their signing certificates generated through Fulcio with a simple signing tool. This would enable us to mitigate the concerns we heard from Python packagers about managing a signing key.
Does that make sense at all? I think the big tradeoff here is that you would be outsourcing the Root of Trust to Fulcio (which would be using TUF itself to protect that root). But, the threat model for the entire fulcio system is
trusted-but-verifiable, so this may be a reasonable tradeoff for many organizations.
Agreed. Particularly where organisations are volunteer run open source projects (or open source projects with small numbers of staff who are not security expects).
Are TUF signatures fully supported now? This blog post makes it seem like they are but this issue is still marked as open. Also, once TUF signatures are supported, does that mean that cosign can be used as a complete replacement to Notary to sign Docker images?
Are TUF signatures fully supported now? This blog post makes it seem like they are but this issue is still marked as open. Also, once TUF signatures are supported, does that mean that cosign can be used as a complete replacement to Notary to sign Docker images?
Some of these tasks have been completed. I updated the pr to turn the different pieces into check boxes. @asraa might know of some related issues that I missed (or of some items I should add here). I'm also open to closing this here and moving to a longer-term discussion/planning forum for these ideas/issues if the maintainers would prefer that.
@mnm678 Thank you for the quick response. I have some questions about what you said.
Some of these tasks have been completed.
Which tasks are you referring to? Cosign being a complete replacement for Notary or for items listed in the linked blog post? We are very interested to know if cosign can currently be used to sign Docker images in a manner that Docker Content Trust can natively verify.
We are very interested to know if cosign can currently be used to sign Docker images in a manner that Docker Content Trust can natively verify.
I don't think cosign will ever be a "drop in" replacement for DCT. The location signatures are stored is too different and I doubt docker will make changes that large at this point.
I think we're aiming for is a conceptual replacement where it supports the same feeatures, use cases, and key management strategies as DCT so it can be used instead if people want.
Which tasks are you referring to? Cosign being a complete replacement for Notary or for items listed in the linked blog post? We are very interested to know if cosign can currently be used to sign Docker images in a manner that Docker Content Trust can natively verify.
I was referring to the subtasks listed in the original issue. Some pieces of the TUF integration have been finished, like the TUF root of trust in sigstore, and the cosign+TUF approach in the blog post you mention. However, I think there's still room here for other integrations, like the ongoing Fulcio+TUF work that is being proposed for PyPI and others.
As @dlorenc said, making a direct replacement for Docker Content Trust is probably out of scope here, but I could envision a verification plugin of some sort for Docker. That would allow for something like native verification.
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.
This issue was closed because it has been stalled for 5 days with no activity.