Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
content: Add attested build environments level requirements #1051
content: Add attested build environments level requirements #1051
Changes from 4 commits
9d6feb142e44070db32447f55357f89d997d53f3d99515e7c98b6c43a531f50File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm sympathetic to view that we can just repeat the language from L3 (unless we also want to rewrite the L3 'intended for' section). Maybe with the caveat "significant changes to existing L3 builds platforms"?
I think the requirements below do a fine job of getting into the details.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
How about:
and then list some of the requirements?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This text also presupposes that all builders run in VMs. Are we categorically rejecting remote attestations from physical TPMs on non-virtual machines?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@deeglaze Can you please clarify, when you say non-VM, do you mean that a build could be running inside a container (backed by a physical TPM), or a bare metal environment, or either? There are a few reasons why we're preferring VM-based environments, but I'd like to track the discussion around other settings.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I mean a task that is launched by a trusted orchestration daemon that establishes some resource limitations and filesystem access restrictions as Linux allows, but not necessarily following an OCI container description. At Google we have build servers that only run builds but still run on Borg. All the node software is accounted for with Titan TPMs. There’s no strong reason for us to require builds to run in VMs since we have everything measured and can account for the machine access by the identity and access management system and (measured) software-enforced ACLs. The build environment is managed by this production identity system before getting to the build job that then measures the inputs for slsa L3 but without incorporating the measurement into pcrs.
The hardware attestation of prodID and software attestation by borg Id (BCID) protect our build environment integrity in an auditable manner, but without incorporating the entirety of our production ecosystem in the build attestation. The new slsa level should allow for ecosystem measurements to be held back if the operational security and physical security of the servers can ve attested to implicitly with the slsa signing key release mechanism.
Now if you’re saying that the build ecosystem integrity is only a means to an end of requiring the build to be run within confidential computing technologies, I’d say that is not the most important goal to reach. If you want the build ecosystem to satisfy holistic properties like “no humans may access the environment” then you have to talk about more security commitments of the software, not just its measurement.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for the detailed explanation!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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 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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@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?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This verification feels different than the previously mentioned one. Is it?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I see the importance of capturing the nuance. I think what Mark might be getting at is that the benefits as currently enumerated are a bit abstract.
E.g. "Greatly reduces trust in a hosted build platform by increasing observability into the level of integrity of the build environment."
Could this instead be something like "Greatly reduces the TCB of a hosted build platform by preventing tampering with the build execution environment, leaving only the OS and vTPM in scope" or something like that?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Clarify that the build executor must be a measured component of the build environment image.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Fair point. This isn't really about the exchanged messages, but about the action of assigning and dispatching a tenant's build process to a pre-deployed build environment. More recently, I've been using the term "build environment dispatch" for this step in the build environment's lifecycle, which is hopefully a little clearer.