Disable static tokens by default as of Kubernetes 1.18

[johngmyers]

Disables by default in k8s 1.18, can be re-enabled by enabling basic auth. Removed in k8s 1.19 using instructions in security.md.

[johngmyers]

Okay, so have to remove basic auth first.

[hakman]

@johngmyers @rifelpet This looks more like complete removal of static tokens for 1.18+.
According to kubernetes/kubernetes#89069 that remove basic auth, "Similar functionality is available via the --token-auth-file flag for development purposes".

I guess that means it's not something that should be used by people other than devs, but I am curious about the reason to remove it from Kops starting 1.18+.

[johngmyers]

The removal would be for security hardening.

kops/pkg/tokens/wellknown.go

Line 20 in bf24a64

// Use of these tokens is deprecated for > 1.6 and should be dropped at the appropriate time

states they've been deprecated since 1.7, yet they're still provisioned always. Also

kops/pkg/apis/kops/componentconfig.go

Line 308 in 64ffe00

// TODO: Remove unused TokenAuthFile

incorrectly states the field is unused.

[hakman]

Seems a good idea to me. My suggestion would be to disable by default in 1.18 and remove completely in 1.19, same as with basic auth.

[johngmyers]

The question would be whether it is worth adding a field to the API for re-enabling this in 1.18.

Other possibilities would be to reuse DisableBasicAuth in 1.18 or to go from enabled in 1.18 to removed in 1.19.

[hakman]

Continuing the discussion in office hours, my vote is for adding a new flag, instead of reusing the DisableBasicAuth one. Best to have a name that matches the action, even if it's another flag.
Also I am all for disabling the Token Auth by default and adding this to release notes.

[johngmyers]

These autogenerated static tokens have been deprecated since kops 1.8. The only thing using any of them was the basic auth support, which is controlled by the field in question.

Basic auth will not work without also enabling static tokens. Basic auth and static tokens have equivalent security properties—it is just a difference of protocol encoding. There is little to no benefit of disabling basic auth without also disabling the autogenerated static tokens.

[justinsb]

I'm sort of confused about kubernetes/kubernetes#89069 - it removes basic auth but not the seemingly equivalent token auth.

This makes it hard to find a reasonable answer, I feel. AFAICT k8s isn't removing or deprecating token-auth, at least not in #89069.

kops can be proactive here and lock this down ahead of removal from k8s upstream - that does seem like a good idea. One thing we could do fairly easily is to not generate auth tokens we don't ourselves use, i.e. I don't think we should still be auto-generating the tokens in GetKubernetesAuthTokens_Deprecated - with the possible exception of "kube" or "admin" which should probably be tied to basic-auth (and thus also go away in 1.19).

If anyone was relying on these tokens, we should be able to figure that out in 1.18 beta. It's also not too hard to generate your own tokens (it looks like we don't have kubectl create secret token, which does suggest nobody is using them). However, this wouldn't help people that have existing clusters, that would have these secrets. If someone was using this, I would imagine they would be creating their own tokens. However, we don't write any additional tokens anyway. Because of this, I'd say it is OK simply to stop writing this file and stop passing the TokenAuthFile flag.

The fallback I imagine is that users could still directly set TokenAuthFile on the apiserver in their cluster config; so we would stop defaulting it, but if users set it we would honor it. To introduce this gradually, we could continue to write known_tokens.csv but not wire it in automatically. That gives an easy way to get back the existing behaviour (in the release note, we should also request that users open an issue to let us know, to stop us further deprecating the behaviour).

To summarize:

• I propose we stop setting token-auth-file on kube-apiserver automatically in kops 1.18.0-beta.1, for k8s >= 1.18.
• We add a release note explaining, and giving a workaround - set token-auth-file, open an issue to let us know the use-case
• I propose we continue to write token-auth-file for a release or two, in case of a use-case, and to provide that fallback.
• Once we're happy, we can stop generating the unused tokens / stop writing the file entirely.

I think this meets the need - we do generate and write these tokens to disk, but I think they are harmless unless we pass the flag to kube-apiserver.

[johngmyers]

I'll work tonight on changing the PR to create known_tokens.csv but not enable them by default.

[johngmyers]

/retest

[hakman]

/lgtm

[justinsb]

Thanks @johngmyers (and @hakman for the discussion!)

/approve
/lgtm

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: johngmyers, justinsb

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

• OWNERS [justinsb]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment