Add Deployment Attestation

[laurentsimon]

This pull request proposes a Deployment Attestation, following the process outlined by ITE-9.

The purpose of this attestation is to authoritatively bind an artifact to a deployment environment. This allows consumers to protect resources and follow the least-privilege principle. In other words, this allows consumers to run only the intended containers / artifacts in the intended environment context.

This is a formalization of the attestation used by GCP Binary Authorization and part of the tooling used for the OSS@NA SLSA workshop.

Joint work with the team from GCP Binary Authorization.

Feedback welcome!

[laurentsimon]

Friendly ping for review. @SantiagoTorres @marcelamelara

[laurentsimon]

@adityasaky as well, thanks

[laurentsimon]

Marcela pointed me to @in-toto/attestation-maintainers. I would like a review, thanks

[laurentsimon]

Thanks for the response. See comments inline.

Thanks for this PR @laurentsimon ! I think it would be really helpful to more clearly describe the intent and focus of the predicate. In particular, the predicate as currently defined seems to aim at fulfilling 3 different related but independent purposes:

1) authorization policy declaration

I don't think we do, no. The only thing we explain is how to parse and verify the attestation. I'm probably mis-understanding what you mean. Can you point me to the text that led you to come to this conclusion? I suppose A deployment policy expresses which environment an artifact is allowed to be deployed to. :)

2) a record of an authorization policy computation that was made,

A policy is not requirement, but that's how most users will use it. I think I spent too much time motivating the DA via this example and it led to confusion. My bad.

and 3) a binding between an artifact and a deployment environment that has specific security properties,

This is what this PR is about.

Of these three, my intuition is that addressing (2) is really the main advantage of this predicate. I need to be convinced that

(1) can't be handled via ITE-10 in-toto layouts

Not sure which verification you're referring to. The verification of the DA attestation? Or the policy that someone may evaluate prior to generating the attestation? It's out of scope of this PR to define a policy language. Users can use intoto layouts or other means to verify the DA attestation. The policy that may be evaluated prior to generating the DA is also out of scope since it is not a requirement to use the DA.

and that (3) can't be handled by SCAI, one of its main intended use cases being to capture properties about compute environments and binding this information to artifacts and evidence.

SCAI states Consumers MUST ignore unrecognized fields. For DA verification Consumers MUST reject attestations with scope types they do not recognize. Take the example of a DA that contains fields "cluster_id = xxx" and "cluster_namespace = yyy". If the verifier does not recognize cluster_id, it should reject the DA because it would violate the intent of the DA (a container would be deployed where it's not intended to). In SCAI, as a consumer / verifier, you can cherry pick what values you care about. That's not the case for a DA.

[toddysm]

We have also been looking at deployment attestations, however in a step of the supply chain that is before the admission controller. We are mainly looking in the context of deploying containers (not only on K8s though). The goal is to create a claim in the CD to capture the details of what is deployed, what the target is as well as mapping the image tags to concrete digest at the time of deployment. The goal is to index this information in GUAC (the IsDeployed link that @pxp928 provided above) and be able to track back to the origins of the image and its dependencies.

One example is deploying on K8s via Helm. We would like to resolve all the image tags to digests before calling the K8s API and capture that event (i.e. an attempt to deploy X is made and here are the parameters). Of course, this attempt may fail if the admission controller prevents the deployment due to policy violation.

The question here would be whether this proposal can serve both needs or we need to look for other options to capture the claims.

[laurentsimon]

We have also been looking at deployment attestations, however in a step of the supply chain that is before the admission controller. We are mainly looking in the context of deploying containers (not only on K8s though). The goal is to create a claim in the CD to capture the details of what is deployed, what the target is as well as mapping the image tags to concrete digest at the time of deployment. The goal is to index this information in GUAC (the IsDeployed link that @pxp928 provided above) and be able to track back to the origins of the image and its dependencies.

The DA in this PR fits well in what you're describing: from the SLSA workshop: a deployment policy | attestation provides an inventory of all deployment environment used by an organization - See the end-to-end deployment from SLSA workshop we ran at the OSS@NA conference last week. The DA in this PR is not only about k8: may be for a VM image, cloud function, smartphone apps, etc.

One example is deploying on K8s via Helm. We would like to resolve all the image tags to digests before calling the K8s API and capture that event (i.e. an attempt to deploy X is made and here are the parameters). Of course, this attempt may fail if the admission controller prevents the deployment due to policy violation.

Yeah this is one thing I have had in mind to improve on the end-to-end demo above. The DA in this PR follows the same model, ie that it should be recorded after it's been resolved.

The question here would be whether this proposal can serve both needs or we need to look for other options to capture the claims.

I think it works well for this purpose. It seems beneficial to have a unique deployment-type attestation. Otherwise there is a risk an attacker could avoid the creation of the "record" attestation (ends up in GUAC) but somehow manages to get one attestation for the admission controller. (So they could be out-of-sync.). Depends on the implementation details, but worth avoiding this problem by having a single DA-type attestation.

[trishankatdatadog]

Interesting idea, but perhaps unnecessary if we simply allow deployment environments themselves to choose what artifacts they would run by filtering on policies. These policies may be specified in the VSA (v1.0 allows only one policy per VSA), or some other similar attestation that is the result of having evaluated a policy.

[trishankatdatadog]

One example is deploying on K8s via Helm. We would like to resolve all the image tags to digests before calling the K8s API and capture that event (i.e. an attempt to deploy X is made and here are the parameters). Of course, this attempt may fail if the admission controller prevents the deployment due to policy violation.

It sounds like you are not looking for Laurent's Deployment attestation so much as some Runtime attestation which I believe @marcelamelara thinks SCAI can fulfil.

[laurentsimon]

Interesting idea, but perhaps unnecessary if we simply allow deployment environments themselves to choose what artifacts they would run by filtering on policies. These policies may be specified in the VSA (v1.0 allows only one policy per VSA), or some other similar attestation that is the result of having evaluated a policy.

Fyi, a DA is the result of a policy evaluation. It comes after the VSA evaluation, as showcased in https://github.com/slsa-framework/oss-na24-slsa-workshop?tab=readme-ov-file#schedule. You can substitute VSA <-> publish attestation in the demo. Without DA, you need a query to an online policy evaluation service from the admission controller (but this comes with SLO / latency requirements which the DA solves).

[laurentsimon]

One example is deploying on K8s via Helm. We would like to resolve all the image tags to digests before calling the K8s API and capture that event (i.e. an attempt to deploy X is made and here are the parameters). Of course, this attempt may fail if the admission controller prevents the deployment due to policy violation.

It sounds like you are not looking for Laurent's Deployment attestation so much as some Runtime attestation which I believe @marcelamelara thinks SCAI can fulfil.

Do you have pointer to runtime attestation? Never heard of the term before. Thanks!

[trishankatdatadog]

Do you have pointer to runtime attestation? Never heard of the term before. Thanks!

Sorry, I should have clarified that I coined it on the spot 😅 But the idea is to instrument what deployments are actually running.

[trishankatdatadog]

You can substitute VSA <-> publish attestation in the demo.

Is the Publish attestation here what eventually became the Release attestation?

[laurentsimon]

You can substitute VSA <-> publish attestation in the demo.

Is the Publish attestation here what eventually became the Release attestation?

no. It's a simple VSA with the specific purpose of publication (and not tied to SLSA), created by an org (possibly a dev / team if they are not part of an org) to attest to its packages.

[laurentsimon]

Do you have pointer to runtime attestation? Never heard of the term before. Thanks!

Sorry, I should have clarified that I coined it on the spot 😅 But the idea is to instrument what deployments are actually running.

Thanks. What's running vs what is allowed to be run are 2 different things. Something that may not be running (but allowed to) may run in the future or might have run in the past. The DA serves the purpose of "what's allowed to be run and where". I don't know what @toddysm use case is: If the use case is "logging attempts to deploy", then the DA may not be what you need.

[trishankatdatadog]

no. It's a simple VSA with the specific purpose of publication (and not tied to SLSA), created by an org (possibly a dev / team if they are not part of an org) to attest to its packages.

Is there a definition I could look at somewhere?

[laurentsimon]

no. It's a simple VSA with the specific purpose of publication (and not tied to SLSA), created by an org (possibly a dev / team if they are not part of an org) to attest to its packages.

Is there a definition I could look at somewhere?

yep. It's all in the SLSA workshop. The publish attestation is explained in Activity 02.