-
Notifications
You must be signed in to change notification settings - Fork 221
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 environment track #1115
base: main
Are you sure you want to change the base?
content: Add attested build environment track #1115
Conversation
✅ Deploy Preview for slsa ready!
To edit notification comments on pull requests, go to your Netlify site configuration. |
e505871
to
5a2a961
Compare
FYI if you want to make the linter happy easily this might help. The linter caused me a ton of trouble until I figured this out. |
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 like where this is heading :)
cbf816f
to
7a39858
Compare
- Build Image Producer: | ||
- MUST automatially generate SLSA [Build L1] or higher | ||
Provenance for created build images (i.e., VM or container images). | ||
- MUST allow independent automatic verification of a build image's SLSA |
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 could be requirements for "allow independent verification"? Does it imply having access to the image (i.e. being able to download it)? I am thinking about the scenario when Platform publishes scripts/templates to build the image but may decide to not publish the image artifact itself for some business reasons. Akin to OSS when one can publish source code but it does not necessarily mean that they also have to publish build artifacts. Is there a place for such an option?
I know that with VSA we provide a choice of artifacts without all the source code but here we have a reverse scenario (source code without artifacts). Perhaps my question is if distributing provenance is as sufficient or a necessary condition?
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.
Interesting, this is definitely a different scenario. I think the way to handle this is for the build image producer to separately put out an explicit attestation that hash X corresponds to a certain build image. We can then articulate this in the spec as an additional requirement like "The build image producer MUST distribute sufficient information about the build image artifact to allow for verification of its provenance, either in the form of the artifact itself or an immutable identifier (e.g., an attestation to its hash)." WDYT?
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'd made some changes to explicitly incorporate this scenario. PTAL!
dbc5dd1
to
8846927
Compare
* Draft levels Environment L0-L2 * Add build environment model 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>
Signed-off-by: Marcela Melara <marcela.melara@intel.com>
048e718
to
0d99fc9
Compare
Signed-off-by: Marcela Melara <marcela.melara@intel.com>
8df324b
to
08b92e8
Compare
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 these changes!
This generally LGTM, I would also like to see what @deeglaze thinks about it too.
<dt>Requirements<dd> | ||
|
||
- Build Image Producer: | ||
- MUST automatially generate SLSA [Build L2] or higher |
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.
nit: misspelled
A typical build environment will go through the following lifecycle: | ||
|
||
1. *Build image creation*: A build image producer creates different build | ||
images through dedicated build process. For the SLSA Environment 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.
images through dedicated build process. For the SLSA Environment track, | |
images through a dedicated build process. For the SLSA Environment track, |
| Primary Term | Description | ||
| --- | --- | ||
| Build ID | An immutable identifier assigned uniquely to a specific execution of a tenant's build. In practice, the build ID may be a cryptographic key or other unique and immutable identfier (e.g., a UUID) associated with the build execution. | ||
| Build image | The template for a build environment, such as a VM or container image. Individual components of a build image include the bootable storage volume containing the build executor, a dedicated build agent, and pre-installed guest OS and packages. |
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 disjunction "VM or container image" doesn't distribute over the components listed in the following sentence. A container doesn't need a bootable storage volume.
If you're running a build environment in a container, then the container runtime is included in the build environment. You can logically separate them for organizational purposes, but we have to draw the boundary at the unit of computation that is the virtual machine or bare-metal machine, no?
I also don't think that your bootable volume has to be the volume that contains your build executor etc. You can have multiple disk volumes, but the executable software, its configuration, and dependencies that orchestrate the build job should be embedded in the provenance-protected disk contents.
| --- | --- | ||
| Build ID | An immutable identifier assigned uniquely to a specific execution of a tenant's build. In practice, the build ID may be a cryptographic key or other unique and immutable identfier (e.g., a UUID) associated with the build execution. | ||
| Build image | The template for a build environment, such as a VM or container image. Individual components of a build image include the bootable storage volume containing the build executor, a dedicated build agent, and pre-installed guest OS and packages. | ||
| Build image producer | The party that creates and distributes build images. In practice, the build image producer may be the hosted build platform or a third party in a BYO build image setting. |
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.
| Build image producer | The party that creates and distributes build images. In practice, the build image producer may be the hosted build platform or a third party in a BYO build image setting. | |
| Build image producer | The party that creates and distributes build images. In practice, the build image producer may be the hosted build platform or a third party in a bring-your-own (BYO) build image setting. |
process. | ||
- MUST automatically generate and distribute signed reference values | ||
for the following build image components: bootloader or equivalent, | ||
guest kernel, build agent, build executor, and root filesystem (e.g., |
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 think above you say a bootable storage volume need to contain the guest kernel, build agent, and build executor. Now you're saying those separately from the root filesystem, which I'm unclear if that means all mount points (e.g., /boot, /usr/, etc) or just the / mount point. I don't know how this extends to a Windows-based environment either.
Do the "build agent" and "build executor" include their configuration and any subprocesses they execute, or just a single binary that is noted as an entrypoint?
|
||
- Build Platform Requirements: | ||
- MUST meet SLSA [Build L3] requirements. | ||
- Prior to dispatching a tenant's build to an instantiated 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.
You can verify a quote's signature without caring about the contents it measured. I think we need to say that the measurements in the quote are verified against the signed reference values provided by the build producer for the instantiated build image.
I'm interested in how you plan on identifying what a booted environment is as a whole to compare against its components. I don't think there is a commonly accepted mechanism for this.
with the host interface to obtain a signed quote for the | ||
environment's initial state. | ||
- Upon build dispatch: Automatically generating and distributing | ||
a signed attestation that binds its boot process quote to the |
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 binding should be to the boot, build job description and build job outputs, no?
If the build environment is meant to be from a clean slate every time, then the job description and outputs can be measured to integrity registers. I'm unclear about build ID. Is this not an in-toto signing key? If it is, I'd expect to see the key only released after the build is complete, following a quote binding to a challenge to get the key released to the build environment to sign the in-toto attestation.
| Primary Term | Description | ||
| --- | --- | ||
| Build ID | An immutable identifier assigned uniquely to a specific execution of a tenant's build. In practice, the build ID may be a cryptographic key or other unique and immutable identfier (e.g., a UUID) associated with the build execution. | ||
| Build image | The template for a build environment, such as a VM or container image. Individual components of a build image include the bootable storage volume containing the build executor, a dedicated build agent, and pre-installed guest OS and packages. |
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 a build being constructed using multiple container images?
ex: https://cloud.google.com/build/docs/build-config-file-schema#build_steps
| Primary Term | Description | ||
| --- | --- | ||
| Build ID | An immutable identifier assigned uniquely to a specific execution of a tenant's build. In practice, the build ID may be a cryptographic key or other unique and immutable identfier (e.g., a UUID) associated with the build execution. | ||
| Build image | The template for a build environment, such as a VM or container image. Individual components of a build image include the bootable storage volume containing the build executor, a dedicated build agent, and pre-installed guest OS and packages. |
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.
When a container image is used as build environment, in practice those container images are executed on a VM which gets created using a VM image. In that scenario, does the requirements documented here for build image would apply for both the host VM image and container image?
- Build Platform: | ||
- MUST meet SLSA [Build L2] requirements. | ||
- Prior to the instantiation of a new build environment, the SLSA Provenance | ||
for the selected build image MUST be automatically verified. |
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.
In general a provenance is verified against a policy. So, what policy would be used for verification here and who defines those policies?
Would it be simpler to treat the build image as an input to the build, and bundle the provenance of the build image along with the the provenance of the artifacts into the attestation bundle, so that all the provenances can be verified using a centralized policy at deployment time?
This PR introduces the following spec changes associated with #975. The spec enhancements are being proposed as the new "build Environment track".
Spec changes: Adds new high-level build environment terminology and levels.
Part 1 of #975 CC @paveliak