content: Add attested build environments level requirements #1051
Conversation
✅ Deploy Preview for slsa ready!
To edit notification comments on pull requests, go to your Netlify site configuration. |
There was a problem hiding this comment.
The SLSA build track does not have a requirement for completeness of resolved dependencies as of today (L3). If feels like we should work to achieve that completeness before we further harden the build environment. It may be possible to add complete provenance alongside the other changes, but that feels like too much change from L3 to L4.
| Software releases needing assurances about the integrity of the environment | ||
| used to create the release (e.g., specific compute platform, pre-build | ||
| tamper detection). | ||
| Build L4 usually requires significant changes to existing build platforms. |
There was a problem hiding this comment.
There are no prior examples to be able to assess the truthfulness of this statement. Significant changes could be required for any increased level.
There was a problem hiding this comment.
Fair point. It's true that L3 already has a very similar statement, and we still wanted to be explicit about the fact that this L4 would require additional significant changes on top of L3. We can be more precise in what we mean here: for example, one of the significant requirements is hardware with very particular features (e.g., TPM or TEE support). Would that be more helpful here?
docs/spec/v1.1/levels.md
Outdated
| - SHOULD verify the build platform's attestations prior to a build and | ||
| produce a [verification summary] about the check. |
There was a problem hiding this comment.
What would this look like? I would expect that the build system would create a build environment attestation on the artifact. I feel like it is a lot to ask for a producer to verify it and publish the VSA. Or does this not have to be a human/manual process?
There was a problem hiding this comment.
The main goal of the proposed requirements is to make tampering prior to a build detectable. That is, at any point from when a build image is itself created/released to the point where a VM is deployed and waiting for a new build job to come in. This means the build platform will actually generate its attestations before and independently of the artifact. We have a figure showing this sequence which I think would be helpful in clarifying things.
I'll note that the point of using hardware-based integrity measurements and attestation for this is to reduce the amound of manual self-attestation and verification that needs to happen on the part of the build platform and producer. I'll also note that this requirement is a SHOULD, so producer's aren't strictly required to check these attestations.
docs/spec/v1.1/levels.md
Outdated
| produce a [verification summary] about the check. | ||
|
|
||
| - Build platform: | ||
| - Each build image (i.e., VM or container) made available to software |
There was a problem hiding this comment.
The VMs must be built on a SLSA Build L3+ platform as well? What does this mean in practice?
There was a problem hiding this comment.
Yes, we're using the creation process of the VM image to bootstrap a first degree of trust in the build environment. Today we're already placing trust in GHA to configure an L3 platform, so say GHA VM images were themselves built on GHA, this requirement would give us assurances that the VM images were built with the same L3 integrity. It's a bit recursive, much like building gcc with gcc is, but the guarantees provided by the rest of the requirements become significantly weakened if we didn't have integrity for the build environment's build process. This is because the Provenance of the VM image gives us the good known value that can be later check against when the VM is deployed.
There was a problem hiding this comment.
I should also add that the conditions for meeting requirement are meant to be binary. That is, L4 is achieved iff the VM image is built on a SLSA Build L3+ platform. We believe this is necessary to get around the issue of resolving what the transitive SLSA level would be.
docs/spec/v1.1/levels.md
Outdated
| producers MUST be built on a SLSA Build L3+ platform. The generated | ||
| SLSA Provenance MUST be distributed to allow for independent | ||
| verification. |
There was a problem hiding this comment.
The provenance for what must be distributed the build image? This is already a requirement for build L1-3: https://slsa.dev/spec/v1.0/requirements#distribute-provenance . Is the intention for this provenance to be verified somehow?
docs/spec/v1.1/levels.md
Outdated
| - Distribution of SLSA Provenance for pre-installed software within the | ||
| build image MAY be best-effort. |
There was a problem hiding this comment.
How would this distribution happen? Are we trying to add recursive SLSA into this requirement? Is that too much to do?
There was a problem hiding this comment.
We aren't trying to add recursive SLSA in this requirement. The intent here is to clarify that while SLSA Provenance is required for the build image creation, SLSA Provenance for pre-installed software (e.g., the Linux kernel, packages etc) is not expected of the build platform.
docs/spec/v1.1/levels.md
Outdated
| - The boot process of each build environment MUST be measured and | ||
| attested using a [TCG-compliant measured boot] mechanism. The | ||
| attestation MUST be authenticated and distributed for independent | ||
| verification. |
There was a problem hiding this comment.
These changes are proposed to be part of the build track but we are now adding additional required attestations into the mix (this attestation + the producer's VSA mentioned earlier). I know that we do not have a 1:1 relationship between attestations and tracks, but this seems to be muddling the simplicity of the build track. Would this proposal be better as its own track?
There was a problem hiding this comment.
You raise a valid point about preserving the simplicity build track, and the types of attestations being a part of that. The intent here is to actually encapsulate the hardware-based attestations inside an in-toto attestation, to at least ensure we remain within the SLSA attestation model. So at Build L4 there would be two types of in-toto attestations that would be generated: SLSA Provenance and SCAI encapsulating the hardware-based attestations. We think this approach helps us keep the attestation types limited to a select few. I'll add a TODO item to include examples of these attestations to illustrate what we would expect, and that'll hopefully clarify some of these questions.
On the question of converting this workstream into its own track, our original proposal went down that path. But we got some very convincing feedback from some in the community that that would actually introduce more complexity than is necessary in SLSA overall when the Build Track already pertains to properties of the build platform.
docs/spec/v1.1/levels.md
Outdated
| - Read-write block devices or file system paths MUST be encrypted | ||
| with a key that is only accessible within the build image. |
There was a problem hiding this comment.
Does this need to be included in the attestation?
Can you clarify the presence of the key? I assume that you are not trying to say that the encryption key should be present in the image used to run the VM/container as then it would be reused for multiple running instances of the build.
docs/spec/v1.1/levels.md
Outdated
| - Before launching a new environment based on a build image (i.e., VM | ||
| or container instance), its SLSA Provenance MUST be verified. |
There was a problem hiding this comment.
What are the criteria for verification here? Is it just the identity or is there more verification needed than that? Are we supposed to verify that it has met some SLSA level?
There was a problem hiding this comment.
The main aspect to verify here is the identity/hash of the build image against what's recorded in the Provenance. Checking the SLSA level of the Provenance here gives extra assurances about the trustworthiness of the hash. In practice, this check would follow the standard verification flow. I'll revise this requirement to make the intent clearer.
docs/spec/v1.1/levels.md
Outdated
| - Before launching a new environment based on a build image (i.e., VM | ||
| or container instance), its SLSA Provenance MUST be verified. | ||
| - Before making a build environment available for a build request: | ||
| - The boot process and state of disk image MUST be verified, and |
There was a problem hiding this comment.
This verification feels different than the previously mentioned one. Is it?
Signed-off-by: Marcela Melara <marcela.melara@intel.com>
Signed-off-by: Marcela Melara <marcela.melara@intel.com>
Signed-off-by: Marcela Melara <marcela.melara@intel.com>
Co-authored-by: Dionna Amalie Glaze <drdeeglaze@gmail.com> Signed-off-by: Marcela Melara <marcela.melara@intel.com>
marcelamelara
force-pushed
the
attested-build-env-level
branch
from
e23f591
to
7f55357
Compare
marcelamelara
changed the title
docs/spec/v1.1/levels.md
Outdated
| @@ -26,6 +26,7 @@ tracks without invalidating previous levels. | |||
| | [Build L1] | Provenance showing how the package was built | Mistakes, documentation | |||
| | [Build L2] | Signed provenance, generated by a hosted build platform | Tampering after the build | |||
| | [Build L3] | Hardened build platform | Tampering during the build | |||
| | [Build L4] | Attested build environment | Tampering before the build | |||
There was a problem hiding this comment.
nit: I don't think "Tampering before the build" is correct. That would be things like code review.
Rather, this is just even stronger protections against tampering during the build.
There was a problem hiding this comment.
Ah. I can see how this is ambiguous. While the main goal is to provide stronger protections during the build, what we really meant here is tampering before build execution, i.e., tampering with the build environment, specifically during the stages when the build environment is created and deployed, but before the tenant's build is actually executed. Perhaps something like "Tampering during build via build environment" would be clearer here?
docs/spec/v1.1/levels.md
Outdated
| produce a [verification summary] about the check. | ||
|
|
||
| - Build platform: | ||
| - Each build image (i.e., VM or container) made available to software |
There was a problem hiding this comment.
I recommend removing these requirements. In my mind, the requirement should be relatively simple: there is a hardware-backed attestation (SEV-SNP, TDX, or equivalent) attesting to:
- the entire initial state of the build environment (bootloader, kernel, filesystem, etc)
- all of the inputs to the build
The properties of those inputs, such as the VM, seem outside the scope. There are many inputs to the build, and I would assume that we should verify each of those separately as part of some "transitive SLSA" verification.
There was a problem hiding this comment.
Agreed, I realized looking at this again more recently that this list really enumerates low-level mechanisms for achieving the high-level properties, rather than stating those high-level properties. My thinking is that a lot of the content currently here would ultimately move to the requirements.md description.
The properties of those inputs, such as the VM, seem outside the scope. There are many inputs to the build, and I would assume that we should verify each of those separately as part of some "transitive SLSA" verification.
I generally agree with the notion that inputs/dependencies to the build should be verified separately. At the same time, the properties of the VM specifically are needed to check the initial state of the build environment. That is, in order for the platform or a strict producer to verify the initial state of the build environment it needs to have good known reference values to check against. The SLSA L3 Provenance for the build image's build provides this good known value, with strong integrity assurances, that can then be bootstrapped to gain trust in the integrity of the initial state of the build environment.
There was a problem hiding this comment.
there is a hardware-backed attestation (SEV-SNP, TDX, or equivalent) attesting to ... all of the inputs to the build
@MarkLodato Thinking about this some more as I reformulate the requirements. What do you mean by "inputs to the build"? Is this about the completeness of external parameters in the Provenance? If so, one way to accomplish this requirement is to sign the Provenance itself with the hardware root of trust. Is this what you have in mind?
| - Runtime changes to the build environment's disk image SHOULD be | ||
| observable at runtime by the executing build request. | ||
|
|
||
| <dt>Benefits<dd> |
There was a problem hiding this comment.
An alternate framing would be that it removes almost all of the build platform from the root of trust. All that's left is the hardware vendor and physical access.
There was a problem hiding this comment.
At a high level, this is true, and we should probably keep this section more concise than it currently is. We did want to capture some of the nuance of doing this practice, though. For example, you actually need to still place a fair amount of trust in the cloud provider that's hosting the VMs running the builds to not tamper with components like the host OS or the vTPM implementation being used to check the integrity of the build environment. The other part we wanted to emphasize is the machine-checkable aspect of relying on the attestable hardware, compared to the expectations for verification at L3. Maybe this nuance doesn't need to be covered in such detail here?
Signed-off-by: Marcela Melara <marcela.melara@intel.com>
Signed-off-by: Marcela Melara <marcela.melara@intel.com>
Signed-off-by: Marcela Melara <marcela.melara@intel.com>
Signed-off-by: Marcela Melara <marcela.melara@intel.com>
Signed-off-by: Marcela Melara <marcela.melara@intel.com>
| - MUST generate and distribute attestations to good known integrity | ||
| measurements of the entire initial state of the build environment | ||
| (i.e., VM/container image, boot process and filesystem). All | ||
| attestations MUST be authenticated by a hardware root of trust. |
There was a problem hiding this comment.
We may want to clarify "hardware" here. A vTPM is not "hardware" but is a software implementation of TPM that appears to the VM as if it were hardware.
There was a problem hiding this comment.
There's actually a note at the end of the requirements clarifying that virtual hardware also works. Do you think that's enough, or is it worth clarifying up front?
| <td> | ||
|
|
||
| The build platform generated an authenticated attestation to the integrity | ||
| of the entire initial state of the build environment (i.e., VM/container |
There was a problem hiding this comment.
I think I would separate VM and container images. VM image should always be attested while the container image should be attested if containers are being used. Something like:
(i.e., VM image, kernel, filesystem, and container image if containers are used)
There was a problem hiding this comment.
To clarify, you specifically mean the case where a container is used within a VM, right? My intent here was more to cover the scenario in which container-only build images are used. Whether or not containers are sufficient to achieve L3, I think is a related but separate question.
|
|
||
| The build platform MUST guarantee the following: | ||
|
|
||
| - When creating a new build environment: |
There was a problem hiding this comment.
This section might be more clear if we say "creating a new build environment image"? I think it's hard to tease apart the differences of "creating" a build environment vs. "deploying" if you're not already intimately familiar with the spec.
There was a problem hiding this comment.
"Image" might be a bit overloaded, considering we use it for "build image" and "disk image". Basically I'm looking for something to disambiguate a VM itself (build environment) from the VM template that was used to create it (build environment image? something different?).
There was a problem hiding this comment.
I just got to the terminology file, I think just "creating a new build image" would be appropriate given that terminology
There was a problem hiding this comment.
Good catch, this bullet point should say "build image". In terms of unloading the term "image" more, I'm thinking we could use the term "filesystem" whenever the text says "disk image". wdyt?
This (draft) PR introduces the following spec changes associated with #975. Per #975 (comment) and #975 (comment) the spec enhancements are being proposed as a new Build track level. The spec changes introduced in this PR are meant to be complementary to possible requirements being developed in parallel in #977 .
Spec changes:
Part 1 of #975 CC @chkimes