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.
There was a problem hiding this comment.
This text also presupposes that all builders run in VMs. Are we categorically rejecting remote attestations from physical TPMs on non-virtual machines?
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?
| @@ -32,35 +32,38 @@ build level, implementing any controls as specified by the chosen platform. | |||
| <th>Implementer | |||
| <th>Requirement | |||
| <th>Degree | |||
| <th>L1<th>L2<th>L3 | |||
| <th>L1<th>L2<th>L3<th>L4 | |||
There was a problem hiding this comment.
Where are all the close tags for these?
|
|
||
| - Greatly reduces trust in a hosted build platform by increasing | ||
| observability into the level of integrity of the build environment. | ||
| - Provides machine-checkable, cryptographic, hardware-rooted evidence |
There was a problem hiding this comment.
I know that "hardware-rooted" has been used a fair bit when describing confidential computing environments, but it is misleading and not representative of the desired property.
| - Provides machine-checkable, cryptographic, hardware-rooted evidence | |
| The dynamic root of trust for measurement (DRTM) provides machine-checkable and integrity-protected evidence of build environment as authenticated by the DRTM's root of trust. | |
| The DRTM should follow industry standards for isolation to be protected from workload- and host-based tampering. |
I'm not sure binding the specification to TCG as the only trustworthy industry standard body is required.
| MUST be integrity measured and attested. The boot and disk | ||
| attestations MUST be distributed to allow for independent | ||
| verification. | ||
| - When deploying a new build environment: |
There was a problem hiding this comment.
Are these deployment assertions meant to be checkable from each of the build environment's output build attestations, or are these operational attestations for claiming SLSA L4? I can't really prove to folks that I did a check before starting the builder VM unless I'm already in a builder VM, which doesn't seem like the right scope.
OR is this saying that the build image's SLSA provenance MUST be verified as a component of the DRTM's remote attestation for the built artifacts? Is delegating that verification to a VSA already understood as an acceptable verification?
| tampered with. | ||
| - A unique immutable build environment identifier (e.g., | ||
| cryptographic keypair) MUST be generated and cryptographically bound | ||
| to the build environment via attestation. This *deploy-time |
There was a problem hiding this comment.
Is this item meant to address the Google doc comment of attestation verification policy-based key provisioning for SLSA L4 build attestation signing keys? If so, I think this could be clearer. I'm not familiar enough with SLSA mechanics to know whether SLSA level is expected to be assigned by a specific cryptographic key usage.
| and disk image integrity have been verified, and distributed to | ||
| allow for independent verification. | ||
| - When accepting a new build request (e.g., GHA build job): | ||
| - The build environment's deploy-time attestation and uniqueness of its |
There was a problem hiding this comment.
What does this mean? I imagine that the SLSA L4 attestation signing key would be deleted from memory after use from a previous build job, so yes you'd need to re-establish the attestation with the key management service, but only AFTER the build request has completed. You don't want the key material in memory while an untrusted build process is taking place, even if it is isolated.
Who does the build environment attestation verification? It seems like the build job is accepting itself from this wording. The build requester would not necessarily be the one with an appropriate attestation verification policy to apply before even initiating a build request, but maybe that's what you meant? Is a build request supposed to happen over an attested channel?
| - Run-time changes to the build environment's disk image SHOULD be | ||
| observable at run-time by the executing build. These changes NEED NOT | ||
| be attested. | ||
| - Boot, disk, deploy- and request-time attestations MUST be authenticated |
There was a problem hiding this comment.
I don't think request-time attestation is what's desirable. Although it could be an enhancement for tenant confidentiality, i.e., "I don't want to release my code to a builder I haven't vetted."
For build integrity, we want response-time attestation in order for both input and output resource descriptors to be cryptographically bound to the attestation. This prevents replay attacks given that the attestations are meant to be verified offline (i.e., not during the build process where the environment could respond to a cryptographic challenge for freshness).
| attestations MUST be authenticated by a hardware root of trust. | ||
| - MUST capture all of the inputs to the build in the Provenance. | ||
| - MUST verify the build environment integrity against the build | ||
| environment attestations prior to passing control of the build to |
There was a problem hiding this comment.
When you say "prior to", do you mean that there is a separator event between boot to the build executor and the executor running any build request? That's my expectation, but this also seems like there could be a temporal prior, where an attestation verification service must do this verification before providing a ticket (for example) to permit the build request to proceed. I don't think the latter is desirable. See my later comment about response-time attestations.
|
|
||
| | Primary Term | Description | ||
| | --- | --- | ||
| | Build image | The run-time context within a build environment, such as the VM or container image. Individual components of a build image are provided by both the hosted build platform and tenant, and include the build executor, platform-provided pre-installed guest OS and packages, and the tenant’s build steps and external parameters. |
There was a problem hiding this comment.
This definition of build image as including parts from a tenant seems contrary to prior uses of the term to mean specifically the image of the build environment.
I would advise checking prior instances of "build image" and disambiguate them with "build environment image" and "tenant build image". A build platform will attest to itself, but it may also mount a container including a tenant's build toolchain for executing a build request, so that's an important distinction to make.
| | Primary Term | Description | ||
| | --- | --- | ||
| | Build image | The run-time context within a build environment, such as the VM or container image. Individual components of a build image are provided by both the hosted build platform and tenant, and include the build executor, platform-provided pre-installed guest OS and packages, and the tenant’s build steps and external parameters. | ||
| | Build executor | The platform-provided program dedicated to executing the tenant’s build definition, i.e., running the build, within the build image. |
There was a problem hiding this comment.
Clarify that the build executor must be a measured component of the build environment image.
| | --- | --- | ||
| | Build image | The run-time context within a build environment, such as the VM or container image. Individual components of a build image are provided by both the hosted build platform and tenant, and include the build executor, platform-provided pre-installed guest OS and packages, and the tenant’s build steps and external parameters. | ||
| | Build executor | The platform-provided program dedicated to executing the tenant’s build definition, i.e., running the build, within the build image. | ||
| | Build request | The process of assigning a build to a pre-provisioned build environment on a hosted build process. |
There was a problem hiding this comment.
I always think of requests as messages. Perhaps,
"A user-provided message to the build platform that is used to assign a build to a pre-provisioned build environment on a hosted build process."
But this could be splitting hairs.
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