-
Notifications
You must be signed in to change notification settings - Fork 71
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
RFC for custom CA certs #69
Conversation
Signed-off-by: Zander Mackie <zmackie@gmail.com>
text/0000-custom-ca-certs.md
Outdated
|
||
##### pack | ||
Given the following command: | ||
`pack build --cert /cert1.pem --cert:build /cert2.pem --cert:run /cert3.pem` |
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 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.
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.
Thank makes sense, but it would be nice to have some mechanism for baking them in too.
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.
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?
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 🙂
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 |
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. |
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 |
Signed-off-by: Zander Mackie <zmackie@gmail.com>
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. |
text/0000-custom-ca-certs.md
Outdated
### Specification | ||
Stack authors may include an `extend` executable to the build and/or run images of their stack: | ||
``` | ||
/cnb/image/{build,run}/extend ({build,run}-extend-toml-file) (pkg-cache-dir) | cwd: / |
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.
Maybe: (pkg-cache-dir)
-> (cache-dir)
Might be worth removing it though, or at least explaining why it's not used in this RFC.
# What it is | ||
[what-it-is]: #what-it-is | ||
|
||
### Specification |
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.
Need an explanation of how rebasing will work (and probably need to introduce pack upgrade
from #23)
@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? |
@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: Creating ephermal builders with ca certs in them would require us to: |
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? |
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. |
Ah the niceties of ca-certs being included in different flavors of linux, in different ways and places. |
Signed-off-by: Zander Mackie <zmackie@gmail.com>
Signed-off-by: Zander Mackie <zmackie@gmail.com>
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. |
Converting to draft pending root buildpack RFC. |
Closing as abandoned and superseded by other RFCs. |
@sclevine Can you please link to the superseding RFCs? |
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: |
Viewable