Prototype Validation with Notary v2

[SteveLasker]

Describe the feature As we make progress on Notary v2, customers have asked about integration with several projects like Connaisseur. As we're not experts with Connaisseur, and we'd like to make sure we've collected the right feedback, we'd invite the maintainers, or anyone active with the project to view the latest prototypes, captured in the above status reports and let us know if we've captured the needs to integrate Connaisseur with full Notary v2 support, including content promotion within and across registries.

Optional: Implementation ideas Use Notary v2 signatures for validation of content before deployment. The e2e scenarios are captured here: Notary v2 Scenarios

Optional: Additional context Feel free to reach out to any of the Notary v2 folks, myself, or possibly participate in the Notary v2 weekly call: https://hackmd.io/_vrqBGAOSUC_VWvFzWruZw

[xopham]

Thank you @SteveLasker for letting us know! We are excited to see that Notary v2 is making progress. We are actually in the process of integrating support for images accross multiple registries (and thus notaries, #90 ) for v1 and hope this becomes easier with v2. We plan to take a look at Notary v2 soon and would gladly provide feedback. In particular, we're planning to evaluate whether (and how) Connaisseur features can be transferred into the Nv2 world.

[Starkteetje]

Hi @SteveLasker

thank you for the question and including folks into the nv2 discussions. I've looked into the Notary v2 project a bit and can give you some thoughts in general and a few more regarding what Connaisseur needs.

First of all, I would say the integration of an at least TUF-like feature that guarantees freshness and that allows a trusted mapping of tags to digests is necessary. I have seen the TUF integration proposal and the discussion on issue 43 but wanted to reiterate this as I believe it to be a central aspect of container security.

Other than that, I really like the move of signatures to get closer to the image, i.e. basically integrating all notary functions into the registry. It feels a lot less like the security is just randomly attached to an otherwise independent eco-system (although it obviously still is).

One question I had was regarding TAP 16, who would the auditors be? Given that they are introduced as a third-party one would assume them to be somewhat independent of registry operators, but given that the task of verifying a huge Merkle tree regularly, maintaining uptime (otherwise clients can't verify, so uptime of registry without uptime of auditor doesn't mean that much and if you use caching by some other third-party you have yet another dependency...) and being a trust anchor for clients sounds somewhat expensive, it does not sound like a task someone would just do without compensation.

As for Connaisseur, it's main task is to validate a provided signature (chain) against a pinned root key, and in case of successful validation translate a potential tag into a trusted digest enabling the underlying container engine to pull a trusted image. Basically, Connaisseur does what is mentioned in your TUF prototype documentation.

Connaisseur needs some things to fulfill its job as a Kubernetes AdmissionController:

• Pinned root of trust (currently DCT root pub key, would become x509 cert)
• Access to trust data

The root of trust change on a technical level does not really change the behaviour of Connaisseur. We'd have to implement verification for x509 (there's already an unrelated issue for that), but that shouldn't be a big deal. However, it sounds like what also changes (or what registry operators' intentions are) is that the TUF data is somewhat more global in that there's a global root for a registry with a key not controlled by the "owner" of a repository. From the perspective of an organization that doesn't (want to) trust its image registry vendor (i.e. ACR), I would need to be able to pin root trust to an intermediate key under my control instead of relying on a (global) root provided by the vendor. This might not necessarily be covered by the nv2 spec, but it should be a possible use-case to allow to delegate their own trust network "independent" of the registry and if I do understand TAP-13 correctly, this is in the works or (outside TUF-spec) already possible via regular TUF delegations if the repository owner controls a delegated-to key.

With regards to the trust data acquisition, currently Connaisseur can get it via a simple (potentially authenticated) call to the notary web server. In particular, Connaisseur does not need to pull the actual image as it can derive a trusted digest from the trust data without ever looking at content (as a mutating admission controller Connaisseur changes the deployment files from image:tag to image@sha256:digest). With notary v2, trust data becomes a JWT stored as a application/vnd.cncf.notary.config.v2+jwt within the registry, which needs to be discovered and pulled. Regarding discoverability, it seems you are already looking at reverse lookups. We don't have any stakes in how this gets implemented though. Pulling the OCI Manifest linking to the OCI Artifact being the signature and pulling the signature itself should be doable via the registry API, so from that perspective Connaisseur should, given a few adjustments on our part, work with a notary v2.

Questions that would arise specifically for the use-case of Connaisseur are:

• How would Connaisseur handle timestamp key rotation? TAP-16 seems to suggest it gets more or less ignored by auditor and in turn client, but it is a trust boundary. We might want to implement both a strict blocking and a relaxed mode which just logs warnings.
• If TAP-13 is not implemented or doesn't quite work the way I understood it and we resort to pinning a "lower" node's key as "root", then differing from TUF the timestamp key is not signed by "root". In that case, would we have to pin the timestamp key (or registry root key) separately or do we TOFU that for usability?

Long story short, I think nv2 in general looks good, would work with Connaisseur given a few adaptations on our part, but a) auditors look a bit underspecified and b) auditors and hence clients ignoring timestamp key rotation as a non-event invalidates some of the security guarantees that auditors are supposed to establish. If you want to go into detail on some of the above, feel free to comment again.

Best, Teetje