-
Notifications
You must be signed in to change notification settings - Fork 715
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
CA rotation: controller-manager needs a separate ca.crt file #1350
Comments
@anguslees thanks for this issue and for the detailed explanation!
What discussed in this issue is clearly part of 1; I personally prefer the idea to change the kube-controller-manager, because this will ease the pain on users, but I'm open to reconsider this in the context of the discussion above... |
This is a broader topic and we should loop in @kubernetes/sig-auth-misc on approach + fixes. |
For the immediate question, the signing cert/key given to the controller manager should be distinct from the trust bundle. Coupling the two and having kube-controller-manager treat the first cert in the bundle specially seems ill-advised, since order in trust bundles is not typically significant. |
Signing certs and trust bundles are clearly different things indeed. So, I tried to separate one from the other in rojkov/kubernetes@afed24f. Cluster creation (and node join) seems to work. |
Agreed. To be clear though, the signing happens with a private key, already called out separately ( (I think we should just use a separate file, as @liggitt suggests and @rojkov's change implements. Just pointing out that we could modify controller-manager to try to find the matching public key in the trust bundle if we really wanted to avoid a separate file) |
@rojkov it looks like you have already made some good changes for this issue. Are you planning to submit a PR, or interested in help testing your change? We're interested in this feature as well and would consider working on a similar implementation and PR otherwise. Sounds like the current recommendation is to have a separate trust bundle file and keep the |
@astrieanna I'm consumed by another project ATM, but I'll try to submit a PR by the end of this week. |
@astrieanna it seems a simple rebase is not enough now after @fabriziopandini refactored the cert renewal code. If you need to fix this issue urgently please consider submitting your own PR. I'll get back to k8s in 2 weeks hopefully. |
hi, this topic needs a design proposal. |
As per kubeadm office hours discussion, we are considering certificate rotation in scope of the kubeadm operator #1698 |
this is too late for 1.17. |
/remove-lifecycle stale |
Issues go stale after 90d of inactivity. If this issue is safe to close now please do so with Send feedback to sig-contributor-experience at kubernetes/community. |
/remove-lifecycle stale |
Issues go stale after 90d of inactivity. If this issue is safe to close now please do so with Send feedback to sig-contributor-experience at kubernetes/community. |
/remove-lifecycle stale |
For this particular reason (ie change the pointing of the client-ca and cluster-signing-cert to different CA), I'm not able to automate the CA rotation. I thought, I can use a config file that can change the arguments kube-controller-manager accepts, but per the official doc https://kubernetes.io/docs/reference/command-line-tools-reference/kube-controller-manager/ doesn't show if KCM can accept config files. I use command line arguments to start a KCM docker container, so changing arguments to point to different certs is not possible while rotating the CA. |
this is the officially approved guide for rotating CA: it includes notes about client-ca-file and cluster-signing-cert-file. |
The Kubernetes project currently lacks enough contributors to adequately respond to all issues and PRs. This bot triages issues and PRs according to the following rules:
You can:
Please send feedback to sig-contributor-experience at kubernetes/community. /lifecycle stale |
The Kubernetes project currently lacks enough contributors to adequately respond to all issues and PRs. This bot triages issues and PRs according to the following rules:
You can:
Please send feedback to sig-contributor-experience at kubernetes/community. /lifecycle stale |
/unassign |
May I ask why |
if you have tested it and it works with bundles, you can PR the same page with a fix. similar Q asked here: |
Oh, I see the doc text points back to this issue as justification for the kube-controller-manager exception ("Issue 1350 for kubeadm tracks an bug with the kube-controller-manager being unable to accept a CA bundle.") To be clear: This (#1350) is a bug report against kubeadm, not kube-controller-manager. kube-controller-manager always accepted CA bundles in all the right places just fine, but the way kubeadm configured kube-controller-manager was incorrect and conflated CA bundle and CA signing cert. If you don't use kubeadm, or are willing to deviate from the kubeadm-generated config files, then there was never an issue here. |
Can you please elaborate? If one used kubeadm previously, how does one move away from a kubeadm generated config file? IE - how would you propose updating in place using a CA bundle? |
What happened?
I tried to (manually) rotate my cluster's CA key over the weekend. I discovered that
/etc/kubernetes/pki/ca.crt
can actually include multiple CA keys, and this is key (hah!) to rotating the CA key.kube-controller-manager
however, can only accept a single key in the file pointed to by--cluster-signing-cert-file
, since this is the key used to sign things, and not to verify things (so having multiple keys doesn't make sense).kube-controller-manager
exits immediately (with a helpful error) if--cluster-signing-cert-file
includes multiple keys.I think pointing
kube-controller-manager --cluster-signing-cert-file
toca.crt
works for the simple (single key) case, but is incorrect in general, since it preventsca.crt
file from being used to rotate keys. I think the correct path is to either:--cluster-signing-cert-file
that only contains the single "primary" CA cert.or
ca.crt
or some other logic to ignore additional certs.What you expected to happen?
Able to append a new CA cert to
/e/k/pki/ca.crt
and have both CA certs accepted by controller jobs without other impact.How to reproduce it (as minimally and precisely as possible)?
Append an additional cert to /e/k/pki/ca.crt and restart kube-controller-manager pod
The text was updated successfully, but these errors were encountered: