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. |
marcelamelara
force-pushed
the
attested-build-env-track
branch
2 times, most recently
from
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. |
marcelamelara
changed the title
marcelamelara
force-pushed
the
attested-build-env-track
branch
from
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.
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.
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.
I'd made some changes to explicitly incorporate this scenario. PTAL!
marcelamelara
force-pushed
the
attested-build-env-track
branch
2 times, most recently
from
dbc5dd1
to
8846927
Compare
* Draft levels Environment L0-L2 * Add build environment model Signed-off-by: Marcela Melara <[email protected]>
Co-authored-by: Tom Hennen <[email protected]> Signed-off-by: Marcela Melara <[email protected]>
Signed-off-by: Marcela Melara <[email protected]>
Signed-off-by: Marcela Melara <[email protected]>
Signed-off-by: Marcela Melara <[email protected]>
Signed-off-by: Marcela Melara <[email protected]>
Signed-off-by: Marcela Melara <[email protected]>
Signed-off-by: Marcela Melara <[email protected]>
marcelamelara
force-pushed
the
attested-build-env-track
branch
from
048e718
to
0d99fc9
Compare
Signed-off-by: Marcela Melara <[email protected]>
marcelamelara
force-pushed
the
attested-build-env-track
branch
from
8df324b
to
08b92e8
Compare
| <dt>Requirements<dd> | ||
|
|
||
| - Build Image Producer: | ||
| - MUST automatially generate SLSA [Build L2] or higher |
Signed-off-by: Marcela Melara <[email protected]>
| 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.
| 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.
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.
| | 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.
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.
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.
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.
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