@@ -24,8 +24,7 @@ Controller Manager. The tokens are also used to create a signature for a
24
24
specific ConfigMap used in a "discovery" process through a BootstrapSigner
25
25
controller.
26
26
27
- Currently, Bootstrap Tokens are ** alpha** but there are no large breaking
28
- changes expected.
27
+ {% include feature-state-beta.md %}
29
28
30
29
## Token Format
31
30
@@ -39,10 +38,10 @@ only be shared with trusted parties.
39
38
40
39
## Enabling Bootstrap Tokens
41
40
42
- All features for Bootstrap Tokens are disabled by default in Kubernetes v1.6 .
41
+ All features for Bootstrap Tokens are disabled by default in Kubernetes v1.8 .
43
42
44
43
You can enable the Bootstrap Token authenticator with the
45
- ` --experimental -bootstrap-token-auth ` flag on the API server. You can enable
44
+ ` --enable -bootstrap-token-auth ` flag on the API server. You can enable
46
45
the Bootstrap controllers by specifying them with the ` --controllers ` flag on the
47
46
controller manager with something like
48
47
` --controllers=*,tokencleaner,bootstrapsigner ` . This is done automatically when
78
77
expiration : base64(2017-03-10T03:22:11Z)
79
78
usage-bootstrap-authentication : base64(true)
80
79
usage-bootstrap-signing : base64(true)
80
+ auth-extra-groups : base64(system:bootstrappers:group1,system:bootstrappers:group2)
81
81
` ` `
82
82
83
83
The type of the secret must be ` bootstrap.kubernetes.io/token` and the name must
@@ -92,8 +92,11 @@ for. A value must be set to `true` to be enabled.
92
92
` usage-bootstrap-authentication` indicates that the token can be used to
93
93
authenticate to the API server. The authenticator authenticates as
94
94
` system:bootstrap:<Token ID>` . It is included in the `system:bootstrappers`
95
- group. The naming and groups are intentionally limited to discourage users from
96
- using these tokens past bootstrapping.
95
+ group. `auth-extra-groups` indicates that it will also be included in the
96
+ ` system:bootstrappers:group1` , and `system:bootstrappers:group2` groups. The
97
+ naming and groups are intentionally limited to discourage users from using these
98
+ tokens past bootstrapping. Extra bootstrap token groups must start with
99
+ ` system:bootstrappers:` .
97
100
98
101
` usage-bootstrap-signing` indicates that the token should be used to sign the
99
102
` cluster-info` ConfigMap as described below.
@@ -104,24 +107,8 @@ controller will delete expired tokens.
104
107
105
108
# # Token Management with `kubeadm`
106
109
107
- You can use the `kubeadm` tool to manage tokens on a running cluster. It will
108
- automatically grab the default admin credentials on a master from a `kubeadm`
109
- created cluster (`/etc/kubernetes/admin.conf`). You can specify an alternate
110
- kubeconfig file for credentials with the `--kubeconfig` to the following
111
- commands.
112
-
113
- * `kubeadm token list` Lists the tokens along with when they expire and what the
114
- approved usages are.
115
- * `kubeadm token create` Creates a new token.
116
- * `--description` Set the description on the new token.
117
- * `--ttl duration` Set expiration time of the token as a delta from "now".
118
- Default is 0 for no expiration.
119
- * `--usages` Set the ways that the token can be used. The default is
120
- ` signing,authentication` . These are the usages as described above.
121
- * `kubeadm token delete <token id>|<token id>.<token secret>` Delete a token.
122
- The token can either be identified with just an ID or with the entire token
123
- value. Only the ID is used; the token is still deleted if the secret does not
124
- match.
110
+ You can use the `kubeadm` tool to manage tokens on a running cluster. See the
111
+ [`kubeadm token` docs](/docs/admin/kubeadm/#manage-tokens) for details.
125
112
126
113
# # ConfigMap Signing
127
114
0 commit comments