kubeadm init should default to a finite token TTL
#343
Assignees
Labels
area/security
priority/important-longterm
Important over the long term, but may not be staffed and/or may need multiple releases to complete.
Milestone
Comments
|
I think we should do this, set it to something reasonable (maybe 24 h), and cherrypick a warning into v1.7 kubeadm init that "Unlimited is the default token duration now, it will be xxx in v1.8" |
luxas
added
area/security
priority/important-longterm
hh
pushed a commit
to ii/kubernetes
that referenced
this issue
Jul 14, 2017
…t-token-ttl-warning Automatic merge from submit-queue (batch tested with PRs 48572, 48838, 48931, 48783, 47090) kubeadm: add a warning about the default token TTL changing in 1.8 **What this PR does / why we need it**: This adds a warning to `kubeadm init` and `kubeadm token create` if they are run without the `--token-ttl` / `--ttl` flags. In 1.7 and before, the tokens generated by these commands defaulted to an infinite TTL (no expiration) in 1.8, they will generate a token with a 24 hour TTL. The actual default change is in kubernetes#48783. This change is separate so we can cherry pick the warning into the `release-1.7` branch. **Which issue this PR fixes**: ref kubernetes/kubeadm#343 **Special notes for your reviewer**: This change is blocked on kubernetes/kubeadm#343. These warnings should probably be removed in the 1.9 cycle. **Release note**: ```release-note Add a runtime warning about the kubeadm default token TTL changes in 1.8. ``` /assign @luxas
hh
pushed a commit
to ii/kubernetes
that referenced
this issue
Jul 14, 2017
…ault-token-ttl Automatic merge from submit-queue (batch tested with PRs 48572, 48838, 48931, 48783, 47090) kubeadm: change the default bootstrap token TTL to 24 hours **What this PR does / why we need it**: This PR changes the TTL for the default bootstrap token generated by `kubeadm init` (without the `--token-ttl` parameter) and `kubeadm token create` (without the `--ttl` flag). Previously, the default TTL was infinite. After this change it is 24 hours. ~~The reasoning for 2 hours as a default is that it's 1) long enough that someone manually using kubeadm (copy-pasting) shouldn't have any issues and 2) short enough that if something is going to break, it should break while the user/admin is still paying attention to the cluster. I'm open to bikeshedding about the exact value, 2 hours is a bit of a strawman.~~ **Edit: updated this to 24 hours instead of 2 hours.** This is a breaking change if you rely on infinite TTL tokens (e.g., if you had an ASG group of worker nodes). The old behavior is easily restored by passing `--token-ttl 0` to `kubeadm init` or the `--ttl 0` flag to `kubeadm token create`. **Which issue this PR fixes**: fixes kubernetes/kubeadm#343 **Special notes for your reviewer**: This was discussed earlier today in SIG-cluster-lifecycle **Release note**: ```release-note Change the default kubeadm bootstrap token TTL from infinite to 24 hours. This is a breaking change. If you require the old behavior, use `kubeadm init --token-ttl 0` / `kubeadm token create --ttl 0`. ``` cc @jbeda
|
Fixed with kubernetes/kubernetes#48783 🎉 |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Versions
kubeadm version (use
kubeadm version): <= 1.7What happened?
kubeadm initcreated a default token with infinite TTL.What you expected to happen?
kubeadmcreates a token with limited (2 hour?) TTL by defaultHow to reproduce it (as minimally and precisely as possible)?
Run
kubeadm initwithout specifying the--token-ttlparameter.Anything else we need to know?
This was discussed in SIG-cluster-lifecycle earlier today. It should be a trivial fix if we agree on the new default.
cc @jbeda @luxas
The text was updated successfully, but these errors were encountered: