Proposal to migrate kube-webhook-certgen to kubernetes-sigs repo

1,213 views
Skip to first unread message

Ricardo Katz

unread,
Sep 9, 2021, 8:49:48 AM9/9/21
to kubernetes-sig-network
Hi folks,

Recently, during the migration of ingress-nginx to ingress v1 we've faced the need to evolve a project that we used, which was https://github.com/jet/kube-webhook-certgen/

Long story short, I've opened a PR (https://github.com/jet/kube-webhook-certgen/pull/32) to this project, which got stuck. Reached the original author, who left the company and told me that it seems the company don't want to maintain anymore, then reached sig-contribex and Chris from CNCF asking if we should and could migrate this to ingress-nginx repo and the answer was that as soon as we kept original credits, this is doable so we did (keeping the original credits)

While discussing this in Slack, it came to my attention that not only ingress-nginx but also gateway-api (and other projects) use this, so if the original company really don't want to maintain this, I'm wondering if we should migrate this to kubernetes-sigs under sig-network (I propose me, Rob, James Peach to maintain this). Then I've raised an issue for this: https://github.com/kubernetes/org/issues/2960. This email is also part of the justification for the new repo.

I've anyway reached the company via email (cc'ed Rob and James Strong on that) asking if they want to donate or deprecate this code, we should probably have a lazy consensus on that, right? (the license allows us to do that as soon as we keep the credits)

Thanks

tho...@google.com

unread,
Sep 16, 2021, 6:05:03 PM9/16/21
to kubernetes-sig-network
I don't quite understand what it is for?

Ricardo Katz

unread,
Sep 17, 2021, 11:02:59 AM9/17/21
to tho...@google.com, kubernetes-sig-network
Tim,

kube-webhook-certgen is a project to generate self signed certs with a long expiration date to be used by projects webhooks. The idea is instead of relying on the whole cert-manager stack, for simple cases just use this one to generate all you need. Also it patches Admission Webhook objects, etc (so it's sort of a Webhook automation tool).

We were using that in ingress-nginx and discovered that other projects like Prometheus-operator were using it as well. We have migrated the project (forked) to ingress-nginx because it doesn't seem to be maintained by the original company, but still it's a really useful tool (and it was using deprecated API versions).

I'm ok with keeping this inside ingress-nginx, although I've discovered that even GatewayAPI uses this, so it would be good and beneficial to us maybe to turn this project into a kubernetes-sigs project with more OWNERS.

This is only the point :) otherwise I can keep this internally in ingress-nginx.

Thanks

--
You received this message because you are subscribed to the Google Groups "kubernetes-sig-network" group.
To unsubscribe from this group and stop receiving emails from it, send an email to kubernetes-sig-ne...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/kubernetes-sig-network/2fe64356-4393-4320-99d0-335fd09a6412n%40googlegroups.com.

Tim Hockin

unread,
Sep 17, 2021, 5:42:47 PM9/17/21
to Ricardo Katz, kubernetes-sig-network
It is a CLI that does a one-time generation?  Or it actively does ... something?   

I feel dense...

Ricardo Katz

unread,
Sep 17, 2021, 6:19:50 PM9/17/21
to Tim Hockin, kubernetes-sig-network
It's a one time run Pod (a Job, actually), that runs as part of the deployment of the controller:



Again, no pressure or rush on that, more like "should we own this as a Kubernetes SIG project?"


Bowei Du

unread,
Sep 17, 2021, 6:43:30 PM9/17/21
to Ricardo Katz, Tim Hockin, kubernetes-sig-network
One question -- dare I say -- could this just be a bash script...

Bowei

Ricardo Katz

unread,
Sep 18, 2021, 7:42:08 AM9/18/21
to Bowei Du, Tim Hockin, kubernetes-sig-network
How dare you?? Kidding

Well, it can (like some openssl + curl patching the admission and validation webhook config) but honestly I’m not sure I wanna spend time refactoring a working code in Go to some shell script. 

I think we can close this subject as the effort is not worth to, and keep this internally in ingress repo. 

Thanks folks
Reply all
Reply to author
Forward
0 new messages