Authenticating with Bootstrap Tokens [page]deterministic
Bootstrap tokens are a simple bearer token that is meant to be used when creating new clusters or joining new nodes to an existing cluster. It was built to support [kubeadm](/docs/reference/setup-tools/kubeadm/), but can be used in other contexts for users that wish to start clusters without `kubeadm`. It is also built to work, via RBAC policy, with the [kubelet TLS Bootstrapping](/docs/reference/access-authn-authz/kubelet-tls-bootstrapping/) system.
## Bootstrap Tokens Overview
Bootstrap Tokens are defined with a specific type (`bootstrap.kubernetes.io/token`) of secrets that lives in the `kube-system` namespace. These Secrets are then read by the Bootstrap Authenticator in the API Server. Expired tokens are removed with the TokenCleaner controller in the Controller Manager. The tokens are also used to create a signature for a specific ConfigMap used in a "discovery" process through a BootstrapSigner controller.
## Token Format
Bootstrap Tokens take the form of `abcdef.0123456789abcdef`. More formally, they must match the regular expression `[a-z0-9]{6}\.[a-z0-9]{16}`.
The first part of the token is the "Token ID" and is considered public information. It is used when referring to a token without leaking the secret part used for authentication. The second part is the "Token Secret" and should only be shared with trusted parties.
## Enabling Bootstrap Token Authentication
The Bootstrap Token authenticator can be enabled using the following flag on the API server:
``` --enable-bootstrap-token-auth ```
When enabled, bootstrapping tokens can be used as bearer token credentials to authenticate requests against the API server.
```http Authorization: Bearer 07401b.f395accd246ae52d ```
Tokens authenticate as the username `system:bootstrap:<token id>` and are members of the group `system:bootstrappers`. Additional groups may be specified in the token's Secret.
Expired tokens can be deleted automatically by enabling the `tokencleaner` controller on the controller manager.
``` --controllers=*,tokencleaner ```
## Bootstrap Token Secret Format
Each valid token is backed by a secret in the `kube-system` namespace. You can find the full design doc [here](https://git.k8s.io/design-proposals-archive/cluster-lifecycle/bootstrap-discovery.md).
Here is what the secret looks like.
```yaml apiVersion: v1 kind: Secret metadata: # Name MUST be of form "bootstrap-token-<token id>" name: bootstrap-token-07401b namespace: kube-system
# Type MUST be 'bootstrap.kubernetes.io/token' type: bootstrap.kubernetes.io/token stringData: # Human readable description. Optional. description: "The default bootstrap token generated by 'kubeadm init'."
# Token ID and secret. Required. token-id: 07401b token-secret: f395accd246ae52d
# Expiration. Optional. expiration: 2017-03-10T03:22:11Z
# Allowed usages. usage-bootstrap-authentication: "true" usage-bootstrap-signing: "true"
# Extra groups to authenticate the token as. Must start with "system:bootstrappers:" auth-extra-groups: system:bootstrappers:worker,system:bootstrappers:ingress ```
The type of the secret must be `bootstrap.kubernetes.io/token` and the name must be `bootstrap-token-<token id>`. It must also exist in the `kube-system` namespace.
The `usage-bootstrap-*` members indicate what this secret is intended to be used for. A value must be set to `true` to be enabled.
* `usage-bootstrap-authentication` indicates that the token can be used to authenticate to the API server as a bearer token. * `usage-bootstrap-signing` indicates that the token may be used to sign the `cluster-info` ConfigMap as described below.
The `expiration` field controls the expiry of the token. Expired tokens are rejected when used for authentication and ignored during ConfigMap signing. The expiry value is encoded as an absolute UTC time using [RFC3339](https://datatracker.ietf.org/doc/html/rfc3339). Enable the `tokencleaner` controller to automatically delete expired tokens. …(trimmed)