content: Add figure for the build environment model

[marcelamelara]

This PR adds figures depicting the system model for the BuildEnv track.

Fixes #1165

CC @paveliak

[netlify]

✅ Deploy Preview for slsa ready!

Name	Link
🔨 Latest commit	d1dbe11
🔍 Latest deploy log	https://app.netlify.com/sites/slsa/deploys/6758c8b2bc14d20008e12fa9
😎 Deploy Preview	https://deploy-preview-1244--slsa.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

---

To edit notification comments on pull requests, go to your Netlify site configuration.

[paveliak]

Re: Tenant Build Definition

Is it a yaml defining build steps? If so, then it is part of the image. Instead it comes in the payload of a job request message.

Re: Build Executor and Build Agent

I wonder if we would be better with merging them into a single Build Agent box, just for simplicity. In practice they most likely exist as two different processes. The mental model I have in mind is - suppose we have MyAwesomeCiProvider that can integrate with different CI systems (GitHub, GitLab, AzureDevOps, etc). Then "Build Agent" on this picture would be a "CI Provider agent" (more of a compute agent) while each of the different CI systems would have its own build executor that knows how to deal with specific build definition format. OnPrem build platforms may not need this level of customization and have them as a single component.

Another thing that comes into my mind is that existing docs define build executor as The build executor is the independent execution environment where the build takes place. And then IMO it gets confusing to see build executor on this diagram defined as a sub-component of a build image.

What do you think?

[marcelamelara]

Is it a yaml defining build steps? If so, then it is part of the image. Instead it comes in the payload of a job request message.

Good point. The tenant build definition is supposed to be the file defining the build steps, so it's not loaded until the build has been dispatched. I'll remove it to simplify the figure.

In practice [build executor and build agent] most likely exist as two different processes.

IMO, this is actually an argument in favor of keeping the build executor and build/compute agent separate. My reasoning is if they are provided by different parties (compute provider vs CI provider), then we will have different integrity expectations for each of those components at different levels of the build environment track.

Another thing that comes into my mind is that existing docs define build executor as The build executor is the independent execution environment where the build takes place.

While I think this definition didn't make it into the final v1.0 spec, I do see your general point. We also have an open TODO for ambiguous terms where I think we can include "build executor".

So, I'm fine with renaming the build executor to something like "build runner" because this term runner may be more familiar to CI users. What do you think? But I do still think it's worth keeping it separate from the build/compute agent.

[marcelamelara]

@paveliak I made several changes, PTAL!

[marcelamelara]

I had some more time to think about your comments, and I have come around. I further simplified the build environment model and merged the build executor and agent into a single "build agent". I've also updated the definition to add some more details.

[paveliak]

@marcelamelara Thanks! that looks very nice. Curious about the dedicated link that connects Control Plane and Host Interface (in addition to the links that connect Control Plane with the Build Environment). Does it signify the interaction needed to attest the environment (e.g. via the remote attestation?) or there is something more/different to it?

[marcelamelara]

I perhaps should label those arrows. The arrows between the control plane and build environment are supposed to represent the various data flows between them, including the mutual attestation between the two, sending the tenant's build steps. The arrow between the control plane and host interface signifies the request to create a new VM or container.

[arewm]

Does this also resolve #1245?

[arewm]

Does this mean that there is no provenance for the control plane? Should there be (except for the bootstrapping problem)?

[marcelamelara]

for now, we aren't explicitly requiring provenance for the control plane because it's not considered part of the Build Environment per se, and it's trusted at least in certain levels of the BuildEnv track. It's an interesting question, though, so I'll open up an issue to discuss.

[marcelamelara]

I opened issue #1253 to track this.

[marcelamelara]

Does this also resolve #1245?

It doesn't, at least not how I've imagined it. What I have imagined for #1245 is a flow diagram showing the data flows to/from the build environment at various points in its lifecycle, pre-build and during the build. These data flows would show the points at which SLSA or other provenance formats would be generated and/or verified during the build env lifecycle. I'll add some more context to that issue to clarify.

[TomHennen]

FWIW I support adding a diagram, but I don't think I'm expert enough to review it from a technical perspective. Happy to approve once the experts (@paveliak ?) are happy. :)

[paveliak]

@marcelamelara That looks very nice! 🚀

[mlieberman85]

LGTM