Skip to content
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.

Sign up for GitHub

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

Jump to bottom

Creating separate CAs for client and server certificates #2586

Open
chrisnegus opened this issue Oct 7, 2021 · 8 comments
Open

Creating separate CAs for client and server certificates #2586

chrisnegus opened this issue Oct 7, 2021 · 8 comments
Labels
area/pki PKI and certificate related issues area/security kind/design Categorizes issue or PR as related to design. kind/feature Categorizes issue or PR as related to a new feature. lifecycle/frozen Indicates that an issue or PR should not be auto-closed due to staleness. priority/backlog Higher priority than priority/awaiting-more-evidence.
Milestone
Next

Comments

@chrisnegus
Copy link

chrisnegus commented Oct 7, 2021 •
edited by neolit123
Loading

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.
@k8s-ci-robot
Copy link
Contributor

@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.

@neolit123
Copy link
Member

neolit123 commented Oct 7, 2021 •
edited
Loading

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

@sftim
Copy link

sftim commented Oct 7, 2021

/transfer kubeadm

Is that OK?

@k8s-ci-robot k8s-ci-robot transferred this issue from kubernetes/website Oct 7, 2021
@sftim
Copy link

sftim commented Oct 7, 2021 •
edited
Loading

/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).

@k8s-ci-robot k8s-ci-robot changed the title Suggest creating separate CAs for client and server certificates used with kubeadm Creating separate CAs for client and server certificates Oct 7, 2021
@sftim
Copy link

sftim commented Oct 7, 2021

/kind feature

@k8s-ci-robot k8s-ci-robot added the kind/feature Categorizes issue or PR as related to a new feature. label Oct 7, 2021
@neolit123 neolit123 added the priority/backlog Higher priority than priority/awaiting-more-evidence. label Oct 7, 2021
@neolit123 neolit123 added this to the Next milestone Oct 7, 2021
@neolit123
Copy link
Member

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 neolit123 added area/security kind/design Categorizes issue or PR as related to design. labels Oct 7, 2021
@chrisnegus
Copy link
Author

@neolit123 @sftim Thanks for following up with this. I would be happy to help if some writing assistance is needed with this.

@k8s-triage-robot
Copy link

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/stale is applied
  • After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
  • After 30d of inactivity since lifecycle/rotten was 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

@k8s-ci-robot k8s-ci-robot added the lifecycle/stale Denotes an issue or PR has remained open with no activity and has become stale. label Jan 9, 2022
@neolit123 neolit123 added lifecycle/frozen Indicates that an issue or PR should not be auto-closed due to staleness. area/pki PKI and certificate related issues and removed lifecycle/stale Denotes an issue or PR has remained open with no activity and has become stale. labels Jan 10, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
area/pki PKI and certificate related issues area/security kind/design Categorizes issue or PR as related to design. kind/feature Categorizes issue or PR as related to a new feature. lifecycle/frozen Indicates that an issue or PR should not be auto-closed due to staleness. priority/backlog Higher priority than priority/awaiting-more-evidence.
Projects
None yet
Milestone
Next
Development

No branches or pull requests
5 participants
@neolit123 @chrisnegus @k8s-ci-robot @sftim @k8s-triage-robot