kubeadm init --token-ttl 0 (flag) and tokenTTL: "0" (config) are broken since 1.8.0

[mattmoyer]

Is this a BUG REPORT or FEATURE REQUEST?

BUG REPORT (copied from @rhuss's issue filed here kubernetes/kubernetes#5363)

Versions

1.8.0 - up to current master (2017-10-26)

What happened?

When using kubeadm with a token generated by kubeadm token generate in advance, but also when letting kubeadm create the token, a tokenTTL configuration is ignored. The same is true when not using a config file but using kubeadm init --token-ttl 0

What you expected to happen?

I would expect when providing a tokenTTL of 0s that the token does not expire.

How to reproduce it (as minimally and precisely as possible)?

See kubernetes/kubernetes#53637 where @rhuss described this nicely.

Anything else we need to know?

This bug was introduced in kubernetes/kubernetes#48783 when default token TTL was changed.

The API machinery defaulting mechanism doesn't have a way to differentiate between an unset value and a value that's explicitly set to zero.

I did some manual testing on that change, but apparently only for kubeadm token create --ttl 0, which works fine because it doesn't use the MasterConfiguration defaulting mechanism.

[mattmoyer]

cc @kubernetes/sig-cluster-lifecycle-bugs
/type bug

[rhuss]

My current workaround is to create an extra token on my own after kubeadm init:

kubeadm init --config /etc/kubernetes/kubeadm.yml
kubeadm token create --ttl 0 --groups system:bootstrappers:kubeadm:default-node-token --description "Bootstrap token which does not expire"

The later token is then used for kubeadm join on the nodes.

[luxas]

Thanks @mattmoyer for the bug fix 👏! Approved

[mattmoyer]

This is fixed in master and should be in v1.8.3.