From f1bf6c874ec2a131fb552c20ca42ec9ff836338a Mon Sep 17 00:00:00 2001 From: Joe Beda Date: Sat, 18 Feb 2017 17:07:02 -0800 Subject: [PATCH] Locks down exact token format Signed-off-by: Joe Beda --- contributors/design-proposals/bootstrap-discovery.md | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/contributors/design-proposals/bootstrap-discovery.md b/contributors/design-proposals/bootstrap-discovery.md index 0cc719a4e04..26912caad67 100644 --- a/contributors/design-proposals/bootstrap-discovery.md +++ b/contributors/design-proposals/bootstrap-discovery.md @@ -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`.