You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Jun 26, 2023. It is now read-only.
We've had some discussions at Google about HNC, and some of us were concerned by the runtime dependency on cert-manager. For example, we've already seen cases where different versions of cert-manager can break us - what happens if someone has the wrong version installed on their cluster?
By contrast, Gatekeeper is a similar project to HNC, but has the optional ability to generate its own self-signed certs for its webhooks. We thought it would be nice to include this capability in HNC as well.
We had a chat with the controller-runtime folks about moving Gatekeeper's cert management there, but they're not really interested in maintaining it. For now, the best solution we can think of is simply to copy Gatekeeper's manager (which is a single code file, plus a test file) into HNC, and update it periodically with fixes. @yiqigao217 has already been working with Gatekeeper to get some (unrelated) fixes into their cert manager so she has a good understanding of how that code works.
Hopefully this is an interim solution until we move that file to a proper library location, but in the meantime, we think this will make HNC easier to use in more environments.
The text was updated successfully, but these errors were encountered:
I think as a default its fine. I'd prefer/hope we maintain the option to configure HNC with a secret name where to find the cert to use (and therefore skip the self signed route). Leaving the use of cert manager open.
Personally we (as in Cray) wouldn't allow the self signed option in our clusters, but for development/getting started I think it's generally ok.
I've done quite a bit around certs within k8s so feel free to reach out @yiqigao217 if you need some help with this.
On Fri, Apr 17, 2020 at 6:49 PM Ryan Bezdicek ***@***.***> wrote:
I think as a default its fine. I'd prefer/hope we maintain the option to
configure HNC with a secret name where to find the cert to use (and
therefore skip the self signed route). Leaving the use of cert manager open.
Personally we (as in Cray) wouldn't allow the self signed option in our
clusters, but for development/getting started I think it's generally ok.
I've done quite a bit around certs within k8s so feel free to reach out
@yiqigao217 <https://github.com/yiqigao217> if you need some help with
this.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<#653 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AE43PZFF6SV5327P2K4N3BTRNDMHHANCNFSM4MLCUNSQ>
.
We've had some discussions at Google about HNC, and some of us were concerned by the runtime dependency on
cert-manager
. For example, we've already seen cases where different versions ofcert-manager
can break us - what happens if someone has the wrong version installed on their cluster?By contrast, Gatekeeper is a similar project to HNC, but has the optional ability to generate its own self-signed certs for its webhooks. We thought it would be nice to include this capability in HNC as well.
We had a chat with the
controller-runtime
folks about moving Gatekeeper's cert management there, but they're not really interested in maintaining it. For now, the best solution we can think of is simply to copy Gatekeeper's manager (which is a single code file, plus a test file) into HNC, and update it periodically with fixes. @yiqigao217 has already been working with Gatekeeper to get some (unrelated) fixes into their cert manager so she has a good understanding of how that code works.Hopefully this is an interim solution until we move that file to a proper library location, but in the meantime, we think this will make HNC easier to use in more environments.
The text was updated successfully, but these errors were encountered: