kubernetes
Creating separate CAs for client and server certificates
edit: neolit123
This is a Feature Request
A suggestion was made by @deads2k in PR26837 to update kubeadm docs to suggest separating client and server CAs:
If I were choosing one thing to tweak about kubeadm's certificate generation overall, I would suggest splitting the CA that signs serving certificates from the CA that signs client certificates. Since we lack individual certificate revocation and the few servers are less likely to expose their cert/key pairs than the many clients, separating the two allows for less disruption if a CA needs to stop being trusted.
What would you like to be added
Add two separate CAs for signing server and client certificates in kubeadm deployments.
Update documentation describing suggesting that separate CAs be used. The information could go on the PKI certificates and requirements page), but it could also go on other kubeadm initialization docs.
Why is this needed This practice could result in less disruption of only one of the two CAs needs to stop being trusted.
@chrisnegus: This issue is currently awaiting triage.
SIG Docs takes a lead on issue triage for this website, but any Kubernetes member can accept issues by applying the triage/accepted label.
The triage/accepted label can be added by org members by writing /triage accepted in a comment.
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.
hi, you can close this issue and log the same issue in kubernetes/kubeadm for tracking. it's not something that is easy to implement, is a breaking change and would require a KEP https://github.com/kubernetes/enhancements/tree/master/keps
/retitle Creating separate CAs for client and server certificates
@chrisnegus would you be willing to tweak this issue now it's logged against kubeadm? The description is now slightly out (through no fault of your own).
thanks for transferring the issue @sftim i can tweak the description.
we can keep this tracked here, but i also wanted to note that i have hopes that certificate revocation will be supported one day, which is a much desired feature in general.
@neolit123 @sftim Thanks for following up with this. I would be happy to help if some writing assistance is needed with this.
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:
- After 90d of inactivity,
lifecycle/staleis applied - After 30d of inactivity since
lifecycle/stalewas applied,lifecycle/rottenis applied - After 30d of inactivity since
lifecycle/rottenwas applied, the issue is closed
You can:
- Mark this issue or PR as fresh with
/remove-lifecycle stale - Mark this issue or PR as rotten with
/lifecycle rotten - Close this issue or PR with
/close - Offer to help out with Issue Triage
Please send feedback to sig-contributor-experience at kubernetes/community.
/lifecycle stale
