[wip] Kubelet TLS bootstrapping #414
Conversation
Codecov Report
@@ Coverage Diff @@
## master #414 +/- ##
==========================================
+ Coverage 38.53% 38.71% +0.18%
==========================================
Files 30 30
Lines 2351 2358 +7
==========================================
+ Hits 906 913 +7
Misses 1324 1324
Partials 121 121
Continue to review full report at Codecov.
|
|
@danielfm Thanks for the great work! However, if a token file is subject to change by e.g. deletion of an user, how should we manage updates to a token file? AFAIK, we have to restart every apiserver to apply changes in a token file. |
k8s-ci-robot
added
the
cncf-cla: yes
|
Hey @mumoshu,
Yes, that's how I've been doing this so far. Although I'm sure there are better ways for granting and managing access to a Kubernetes cluster "at scale" (i.e. LDAP via dex), using a token file is simple enough for those with a more static set of tokens. Since this is not currently supported by kube-aws, what I've been doing so far in my setup is to manually embed the encrypted token file in |
|
Hi @danielfm, thanks for the info. I agree with you about token files.
Is this something you can introduce to kube-aws as the second option we've talked above? |
|
@mumoshu can I add the token file support as a non-experimental feature? Does this make sense to you? In order to make things easier for the reviewers, I think it's best I send another PR just for that, instead of doing everything in the same PR. Then, once kube-aws supports token files, I can go back to this PR and implement the TLS provisioning on top of that. |
|
Yes, and the another PR would be indeed preferable 👍
2017年3月16日(木) 23:06 Daniel Martins <notifications@github.com>:
… @mumoshu <https://github.com/mumoshu> can I add the token file support as
a non-experimental feature? In order to make things easy for the reviewers,
I think it's best I send another PR just for that, and resume this one once
kube-aws support token files.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#414 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AABV-f5rNAsYa7bRvuHRLzQ0GX33eGpvks5rmUHMgaJpZM4MdY_9>
.
|
Adds support for authentication via static token files, as documented [here](https://kubernetes.io/docs/admin/authentication/#static-token-file). The token file is a csv file with a minimum of 3 columns: token, user name, user uid, followed by optional group names. Note, if you have more than one group the column must be double quoted. Authentication via static token files, although not very flexible, is a pretty simple solution for users getting started with Kubernetes and/or want to have some mechanism to give access to different users, but do not want the complexity overhead of a more flexible solution, such as [dex](https://github.com/coreos/dex). This change will also be the foundation which #414 will be laid on. A more detailed change list follows: * Renamed function Since we'll be encrypting things that are not TLS certificates, it's time to rename the function in order to avoid any confusion. The function name suffix implied it created a file, which was not the case. * Updated test error message * Renamed systemd unit to match name changes * Defined a location in which to put the token auth file The decryption of the token file should also happen provided it is put at the correct location. * Should only attempt to decrypt tokens if the auth token file exists * Fixed typo * Added tests * Updated docs * Fixed script * Validate auth token file Before generating the encrypted version of the auth token file, parse it as a CSV and look for problems, such as comments and unmatching number of columns. If any problem is found, an error is raised, causing the cluster not to be created.
|
For some reason, my commits are not showing up here... maybe it has to do with the repository moving from the CoreOS org to the Kubernetes Incubator. 😅 |
|
Hey @danielfm, thanks for the PR added the token file support! |
|
Same problem for #394, rebase and force push does not seem to solve the problem. |
|
@c-knowles I sent a message to the GitHub staff and they said they'll try to find out what happened, but no ETA was given. 🤷♂️ |
|
I'll try moving to a new PR to see if it solves the problem. Moved to #449. |
Adds support for authentication via static token files, as documented [here](https://kubernetes.io/docs/admin/authentication/#static-token-file). The token file is a csv file with a minimum of 3 columns: token, user name, user uid, followed by optional group names. Note, if you have more than one group the column must be double quoted. Authentication via static token files, although not very flexible, is a pretty simple solution for users getting started with Kubernetes and/or want to have some mechanism to give access to different users, but do not want the complexity overhead of a more flexible solution, such as [dex](https://github.com/coreos/dex). This change will also be the foundation which kubernetes-retired#414 will be laid on. A more detailed change list follows: * Renamed function Since we'll be encrypting things that are not TLS certificates, it's time to rename the function in order to avoid any confusion. The function name suffix implied it created a file, which was not the case. * Updated test error message * Renamed systemd unit to match name changes * Defined a location in which to put the token auth file The decryption of the token file should also happen provided it is put at the correct location. * Should only attempt to decrypt tokens if the auth token file exists * Fixed typo * Added tests * Updated docs * Fixed script * Validate auth token file Before generating the encrypted version of the auth token file, parse it as a CSV and look for problems, such as comments and unmatching number of columns. If any problem is found, an error is raised, causing the cluster not to be created.
This PR introduces an experimental feature for provisioning TLS certificates for worker nodes via the also experimental certificate signing requests workflow. Since this workflow is used by kube-adm, I think we can rest assured it won't be dropped anytime soon.
If RBAC is enabled in
cluster.yaml, I also made sure to set up the appropriate cluster role bindings so that the token used for sending the certificate signing requests can only make requests related to certificate provisioning, as instructed by the official documentation.The work is not complete, though. For now, I hard-coded the access token used in the bootstrap process, so I need some pointers regarding how to implement this properly. I think we have two options here:
./credentials/csr-token, and handle it the same way we do with certificates, which is generating/encrypting when runningkube-aws render credentialsandkube-aws up, and handling the decryption in userdata templates./credentials/tokens.csv, (we can even generate a minimal one inkube-aws render credentials) in which he/she could add as many entries as needed alongside the one needed by the TLS bootstrap......and have it encrypted/decrypted the usual way.
The first option is more to-the-point, but IMO the second option has the nice advantage of allowing the cluster administrator to manage other tokens for other purposes, perhaps even as the main authentication strategy for the cluster (e.g. by issuing tokens for other users and controlling who does what via RBAC).
Could you guys share your opinions on this so I can proceed?
Closes #406.