kubernetes
/
community
mirror of https://github.com/kubernetes/community.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

Locks down exact token format 

Signed-off-by: Joe Beda <joe.github@bedafamily.com>
This commit is contained in:
Joe Beda 2017-02-18 17:07:02 -08:00
parent 6a966407df
commit f1bf6c874e
No known key found for this signature in database
GPG Key ID: 4296898C63A3591D
1 changed files with 4 additions and 2 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

6
contributors/design-proposals/bootstrap-discovery.md
View File

@ -63,7 +63,7 @@ For the `kubeadm` flow, the command line might look like:
kubeadm join --discovery-file=my-cluster.yaml
```
After loading the ClusterInfo from a file, the client MAY look for updated information from the server by reading the `kube-public` `cluster-info` ConfigMap defined below. However, when retrieving this ConfigMap the client MUST validate the certificate when talking to the API server.
After loading the ClusterInfo from a file, the client MAY look for updated information from the server by reading the `kube-public` `cluster-info` ConfigMap defined below. However, when retrieving this ConfigMap the client MUST validate the certificate chain when talking to the API server.
**Note:** TLS bootstrap (which establishes a way for a client to authenticate itself to the server) is a separate issue and has its own set of methods. This command line may have a TLS bootstrap token (or config file) on the command line also. For this reason, even thought the `--discovery-file` argument is in the form of a `kubeconfig`, it MUST NOT contain client credentials as defined above.
@ -81,7 +81,7 @@ This is really a shorthand for someone doing something like (assuming we support
curl https://example.com/mycluster.json | kubeadm join --discovery-file=-
```
After loading the ClusterInfo from a URL, the client MAY look for updated information from the server by reading the `kube-public` `cluster-info` ConfigMap defined below. However, when retrieving this ConfigMap the client MUST validate the certificate when talking to the API server.
After loading the ClusterInfo from a URL, the client MAY look for updated information from the server by reading the `kube-public` `cluster-info` ConfigMap defined below. However, when retrieving this ConfigMap the client MUST validate the certificate chain when talking to the API server.
**Note:** support for loading from stdin for `--discovery-file` may not be implemented immediately.
@ -134,6 +134,8 @@ The first part of the token is the `token-id`. The second part is the `token-se
This new type of token is different from the current CSV token authenticator that is currently part of Kubernetes. The CSV token authenticator requires an update on disk and a restart of the API server to update/delete tokens. As we prove out this token mechanism we may wish to deprecate and eventually remove that mechanism.
The `token-id` must be 6 characters and the `token-secret` must be 16 characters. They must be lower case ASCII letters and numbers. Specifically it must match the regular expression: `[a-z0-9]{6}\.[a-z0-9]{16}`. There is no strong reasoning behind this beyond the history of how this has been implemented in alpha versions.
#### NEW: Bootstrap Token Secrets
Bootstrap tokens are stored and managed via Kubernetes secrets in the `kube-system` namespace. They have type `bootstrap.kubernetes.io/token`.