-
Notifications
You must be signed in to change notification settings - Fork 712
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
RFE: Optionally Encrypt Certs as Secrets on init
use token on join
#1200
Comments
/assign @fabriziopandini @timothysc |
@timothysc When you say "Output a token/key (file or command line)" you mean another token? couldn't we use the same token used for joining the cluster? otherwise we would be moving from a "how to distribute certs in the cluster" problem to a "how to distribute a token" problem... :-/ |
@timothysc what if kubeadm join
Pros: We are duplicating certs only for a short time during the join workflow and the encryption key will be managed by kubeadm edited 22/12 - this cannot be implemented to a RBAC problem. see gdoc |
That's a lot of extra jiggery, but it would work too. |
/assign |
my proposal here:
pros:
cons:
working POC project - try it: i can explain how the security implementation and protocol works. |
In my view, the idea of serving files for a limited period of time would mean that new masters could not be added later on, and that would import important restrictions in the topoloogy in the cluster. I guess that the solution in this case would be that users would have to restart the Besides this, I think that the whole idea of having a fileserver embeded in the seeder is not the best approach. Not only because of the MitM problems you mentioned (that would require the distribution of certifciates to the nodes I think it would be better to distribute these files as part of the bootstrapping process, in the response from the seeder, I don't know the internals of the bootstrapping process, but maybe when the client gets the reposnse to the CSR... So the client could ask "I want to join, but as a new master" and the seeder could perform a regular bootstrap but attaching in some way the new master certificates. Maybe clients should provide some additional token (so not every node could join as a new master), but the whole certificates distribution would be part of the protocol. What do you guys think? |
that's a limitation yes.
MITM problems are removed by the encryption of the file transfer. there is no need to distribute public/private keys because the bootstrap token itself is the secret key.
@fabriziopandini proposed something similar. having the certs as part of the bootstrap token. |
after the discussion of 28.11 office hours, we decided that we should collect proposals in a gdoc for this and eventually do a KEP. |
@timothysc @fabriziopandini @luxas proposals added in a gdoc here: |
drafts of the KEP for this feature https://docs.google.com/document/d/1hSghREAoM8f_usJjGuQS1bWEtCC2wBYFNoBC7FyISwA/edit?usp=sharing |
will we allow the user to create a cluster without create the |
we should, as it is now, and this will allow the user to copy certs manually if they want HA. |
closing in favor of #1373 |
edit(neolit123): google doc link for the proposals:
https://docs.google.com/document/d/1XkByzeehah20CgNY47NUMr2VAz-D_ok-GqRX5YRQH0o/edit?usp=sharing
The general UX for standing up an HA control plane is a bit manual for most consumers. There has been a desire for folks to be able to store control plane certs as secrets but there is a broader security concern that these secrets are not encrypted, or any token could be obtained through the cluster itself.
token/key
(file or command line)key
Certs are stored as secrets but the key is only created on init and used on join. The key is never to be stored on cluster.
/cc @kubernetes/sig-cluster-lifecycle
The text was updated successfully, but these errors were encountered: