-
Notifications
You must be signed in to change notification settings - Fork 177
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
certificatesigningrequests/v1beta1 to v1 #115
base: master
Are you sure you want to change the base?
Conversation
needed for certificatesv1 performed by: go get -u k8s.io/client-go go mod vendor go mod tidy
v1beta1 will be dropped in kube 1.22
@jqmichael would you be able to (find someone to) review this? Thanks! |
is there any updates on this? |
I tried this in a new 1.22.2 Kubernetes cluster and it wasn't quite enough.
When you view the
This page: https://kubernetes.io/docs/reference/access-authn-authz/certificate-signing-requests/#kubernetes-signers
Feel free to add the fix to this PR (and adjust if necessary, I'm only a beginner at golang). |
Kubernetes v1.23 is out now, so this project is now 2 minors behind the latest Kubernetes release. The fact that the |
I agree. I think it's good to support cert-manager based deployments in the future. Refs: #94 |
I have the same issue, and it is solved by that change. The |
Yes it seems like requesting kubelet-serving with system:node prefix is the path of least resistance for maintaining roughly the same functionality/behavior in 1.22 as if It might be "wrong" for the webhook to be getting its own serving cert in the first place...it is mimicking what kubelet does. From what I have seen, it is more common a pattern to have the cert generation be the responsibility of the deployer as a prerequisite to webhook deployment. So for example, another aws maintained webhook https://github.com/kubernetes-sigs/aws-iam-authenticator has an optional step where certs are generated before deployment. As mentioned in #94 if the webhook could just read the cert from file and reload then it could be ignorant of how certs are generated, by cert-manager, manually or whatever. Another complication is that AWS EKS does NOT run the kubernetes default signer. So having the webhook create a kublet-serving cert might not work on EKS. But EKS 1.22 is not released yet so that's not really a problem yet |
Oh, sure... |
😂 don't worry, it's on AWS's radar to fix the problem before release. If you have time to submit a PR with the change if @joelddiaz is not available (to be fair, we took very long to review this PR!) I can approve it. Thanks |
Actually I have time to submit a PR now, will link to it in a minute and appreciate reviews. thx. |
#133 is up for review , (sorry for noise, I sent previous comment with just hte link ) and btw when I said 'not a problem' yet I meant for EKS users specifically. Obviously this repository has a wider audience and I'll try to prioritize the cert-manager fix even if EKS doesn't necessarily officially support that as an add-on or whatever. |
Solution I'm thinking of is (cross-posting from #133 (comment) for awareness, apologies again for all the noise):
|
Looks like AWS released EKS 1.22 3 days ago, but noticed this did not make it. Is a different work around for getting this deployed with 1.22? Not sure if you would know @wongma7 |
Hi, is there an update or any workaround for this? Looking to update my cluster to 1.22. |
It looks like the certificates API was switched to v1 in #134 which also updated client-go to 0.23 (huge diff though, so hard to see all that changed) I believe cert-manager is the recommended way forward now, mentioned in README:
And associated PR #139 adds the YAML for this deployment style. |
I clearly don't know how this got added to my cluster infact, I do have cert-manager, but this specific thing got installed in my cluster. Any idea what might bring this up? |
Any update on this? The solution below seems pretty reasonable to me
|
I understand that everything's in place for |
Issue #, if available:
Description of changes:
Kube 1.22 drops support for certificatesigningrequests/v1beta1. Update vendor/k8s.io/client-go and migrate to certificatesigningrequests/v1.
By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.