RFC for custom CA certs

[zmackie]

Viewable

[matthewmcnew]

I am not sure if it makes sense to add certs to the resulting run image especially as the default option.

The certs will obviously be needed at build time. However, it is a common practice for the platform that runs the resulting image to provide the necessary certs and rotating them when necessary.

[zmackie]

Thank makes sense, but it would be nice to have some mechanism for baking them in too.

[natalieparellano]

If we leave the run image out of scope for now, does that obviate the need to do rebase along with this piece of work?

[matthewmcnew]

Yes 🙂

[matthewmcnew]

This will be complicated for platforms that cannot easily create ephemeral images such as kubernetes based platforms like kpack. The platform will need to schedule a build for the image and write that image to a registry accessible by the kubernetes container runtime.

If /cnb/image/{build,run}/add-cert updated a single path specific to the stack such as /etc/ssl/certs. The platform would be able to mount that path in all the subsequent steps to avoid needing to create a new image. This would also generalize well for the run image as a platforms could use the same approach to add ca certs to built image at runtime.

[zmackie]

This will be complicated for platforms that cannot easily create ephemeral images such as kubernetes based platforms like kpack. The platform will need to schedule a build for the image and write that image to a registry accessible by the kubernetes container runtime.

If /cnb/image/{build,run}/add-cert updated a single path specific to the stack such as /etc/ssl/certs. The platform would be able to mount that path in all the subsequent steps to avoid needing to create a new image. This would also generalize well for the run image as a platforms could use the same approach to add ca certs to built image at runtime.

Interesting, but how do you handle ephemeral builders (my understanding was that there was a way to use arbitary buildpacks on a builder; how does it get constructed in that case?

That said, the idea of use a volume and sharing it is an interesting and good idea (probably better than using an image), and potentially more performant.

[frayer]

As a developer in an enterprise setting with custom CA certs, this is of interest. Custom CA's show up in our build and run phases.

Any thoughts on how the metadata of extended certificates could be visible to buildpacks that may perform extra actions with them? A JDK buildpack for example may wish to contribute [extend.(run|build)] certificates to the Java cacerts file for build activities (Maven talking to an internal Artifact repo) or run (consuming internal enterprise services behind custom CA's).

[zmackie]

@frayer I'm not too aware of how you'd normally add certs the the Java cacerts file, but I'm guessing that buildpacks should just assume that the system certs are available for use. @nebhale @jkutner know more about Java CNBs so can probably weigh in here..

[matthewmcnew]

Interesting, but how do you handle ephemeral builders (my understanding was that there was a way to use arbitary buildpacks on a builder; how does it get constructed in that case?

At this point in kpack, we don't support ephemeral builders and encourage users to create new builders in the kpack api. At some point we may allow builds to be scheduled with an order that contains a subset of the buildpacks in a builder by writing a custom order definition.

[sclevine]

Maybe: (pkg-cache-dir) -> (cache-dir)
Might be worth removing it though, or at least explaining why it's not used in this RFC.

[sclevine]

Need an explanation of how rebasing will work (and probably need to introduce pack upgrade from #23)

[nebhale]

@matthewmcnew @zmackie Ephemeral builders should be achievable simply by pushing a new manifest containing the appropriate layers to a registry, no build necessary. The same should be achievable here, right? Just synthesize a new manifest into a registry?

[matthewmcnew]

@nebhale Yes but, that is still complicated because we would still need to build the layers with some form of a "docker build" type mechanism.

Today we:
dynamically create a builder -> schedule build pod with init container that injects certs

Creating ephermal builders with ca certs in them would require us to:
schedule build pod to create ca cert layers -> upload to registry -> dynamically create builder -> schedule build pod without init containers.

[nebhale]

But that's only done once per stack+certs combo and effectively creates a new stack that is then used with manifest-based synthesis. So yes it does have to be scheduled once, but then can be re-used infinitely amortizing that time across an entire enterprise, no?

[matthewmcnew]

Yes, that's possible but, not without insignificant complexity.

I think it probably makes sense to do as part of the larger app extensions work.

However, it seems unfortunate that we need to execute some form of in cluster docker build with heightened privileges just to provide ca certs to builds.

[nebhale]

Ah the niceties of ca-certs being included in different flavors of linux, in different ways and places.

[hone]

I think it probably makes sense to do as part of the larger app extensions work.

Are we waiting on the app extensions RFC for this RFC to get in? These RFCs look super closely tied together. I agree with the motivations behind this RFC.

[jkutner]

Same as @hone, I agree with the motivations. However, I'd like to both this and #23 use buildpacks as an interface for providing the cacerts/extension. I'm working through that with Stephen, and we can probably upstream whatever we land on into this RFC.

[sclevine]

Converting to draft pending root buildpack RFC.

[sclevine]

Closing as abandoned and superseded by other RFCs.

[wilkinsona]

@sclevine Can you please link to the superseding RFCs?

[sclevine]

Stack buildpacks are intended as a robust solution to this problem: #111

However, an approach using regular buildpacks has removed some of the pressure to deliver #111 for this use case:
https://github.com/paketo-buildpacks/ca-certificates