[proposal] Add generic Bootstrap Token constants and helpers to client-go

[luxas]

Features issue: kubernetes/enhancements#130
Proposal: kubernetes/community#189
Initial implementation PR: kubernetes/kubernetes#36101

Why should this be in client-go?
Well, I and @sttts had a discussion about this in #kubernetes-dev on Slack:

Slack thread:

luxas [14:25] 
What do you think about the bootstrap api and the util functions it needs?
@sttts Can it be in client-go?
I think that would make a lot of sense, because this is code people are gonna build on top of

sttts [14:26] 
@luxas we don't have many alternatives I fear

luxas [14:26] 
and the fear is?
just that there are no other alternatives or something else?

sttts [14:26] 
client-go is a bit (too much) our catch-all for packages where we don't know where to put them (edited)

luxas [14:27] 
yeah, I see

sttts [14:28] 
which kind of util funcs?

luxas [14:28] 
validation mostly
regexes for valid tokens
maybe generation of a random one
and for example, a function that builds a full token from an id and a secret, that's just `fmt.Sprintf("%s:%s", id, secret)`
but that way it's clear that the char in the middle isn't `.` or `-` or whatever
a function that checks whether the token has expired
and so on
but all these would in that case be super-generic
only the essentials

sttts [14:33] 
sounds like something for tools/bootstrap

luxas [14:34] 
might be
right now the constants live in `pkg/bootstrap/api`

sttts [14:35] 
which doesn't make sense if it cannot be shared

luxas [14:35] 
and since this isn't a "real" api, it shouldn't be in `client-go/pkg/api{,s}`

sttts [14:35] 
I think client-go/tools/bootstrap is good

luxas [14:35] 
but `client-go/tools/bootstrap` sgtm

sttts [14:36] 
what is left in pkg/bootstrap?
after moving that

luxas [14:36] 
nothing

sttts [14:36] 
+1

luxas [14:36] 
now only the constants are there
most of the logic is "hardcoded" in `pkg/controller/bootstrap`, but the most generic utils would in this case be moved out
and only the controller logic would be left in `pkg/controller/bootstrap`

sttts [14:38] 
makes sense

luxas [14:38] 
then the main and first consumers of `client-go/tools/bootstrap` will be `cmd/kubeadm/app`, `pkg/controller/bootstrap` and `apiserver/plugin/pkg/authenticator/token/bootstrap`
but I expect kops to use this in some way or another in the future as well

The proposal is to:

• move the constants from k8s.io/kubernetes/pkg/bootstrap/api to k8s.io/client-go/tools/bootstrap/(token/)api
• factor out the most essential validation, generation and information getters about the token to k8s.io/client-go/tools/bootstrap/(token/)utils or similar

Then

• k8s.io/kubernetes/cmd/kubeadm/app
• k8s.io/kubernetes/pkg/controller/bootstrap
• k8s.io/kubernetes/apiserver/plugin/pkg/authenticator/token/bootstrap (see: kube-apiserver: add a bootstrap token authenticator for TLS bootstrapping kubernetes#41281)

can use those common util funcs and it's generally easier to build upon the bootstrap token functionality.

This should preferably make v1.6, since we're aiming for beta for this functionality

cc @jbeda @mikedanese @roberthbailey @pires @dmmcquay @errordeveloper @deads2k @smarterclayton @liggitt @sttts @justinsb @ericchiang

[ericchiang]

sttts [14:26]
client-go is a bit (too much) our catch-all for packages where we don't know where to put them (edited)

This kinda sucks. I really hate that client-go becomes the catch all for util packages. That seems like the opposite of what client-go needs in the long term.

Why not k8s.io/apiserver? If it's "generic" functionality, shouldn't it be there?

[luxas]

@mattmoyer could you please take this on for v1.8 as part of getting this to beta?

[mattmoyer]

@luxas sure, I may reach out for guidance. I should be able to do this by early next week.

[luxas]

@mattmoyer Thanks! Let's sync up on Slack or something before you start implementing this so we can make sure we're on the same page 👍

[fejta-bot]

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.

Prevent issues from auto-closing with an /lifecycle frozen comment.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or @fejta.
/lifecycle stale

[errordeveloper]

/remove-lifecycle stale

As shown above, there are in-flight PRs that reference this issues.