Support getting join token from environment variable

[twz123]

Is your feature request related to a problem? Please describe.

There's currently two ways of passing the join token to k0s controller or k0s worker:

1. As an argument on the command line
2. As a file, by passing the --token-file /path/to/tokenfile flag on the command line.

The first approach is only feasible for development and testing purposes, since the command line is not confidential except on particularly hardened machines. The second approach doesn't suffer from this, as it relies on the token file's permissions and is therefore used by automation tools (e.g. k0sctl). However, this means that the token must be written to a place where it is potentially persistent and, if the permissions are inappropriate, can be leaked. While persistence may or may not be a desired property, it still means that the lifecycle of the token file must be managed.

Describe the solution you would like

In addition to the above ways of passing the join token, have both subcommands accept it via an environment variable, say K0S_JOIN_TOKEN. This would be a fairly standard way of passing credentials. It doesn't require the file system or the command line, and is a good middle ground for tools.

In fact, I'm about to ask for a deprecation of support for join tokens as CLI arguments, since managing this via environment variables is potentially even more friendly to manual plumbing.

Describe alternatives you've considered

No response

Additional context

No response

[adlion]

Just to add about security.

When creating a join token there is an argument where you can define time expiration of the token. Currently I am setting it in about 1 hour on my cluster. This might help regarding security.

[psaradhi]

@twz123 - please assign this to me.

@adlion @twz123 - couple of questions reg implementation --

1. If command line arg & token file path needs to be deprecated a. print a warning to users that these features are deprecated and removed from next major version ?

2. if all 3 are specified does the following order of priority sound reasonable? a. argument b. token file c. env variable

   for eg: if json token is specified as an argument (even though it's insecure), it will take the highest priority , followed by token file and then env variable

[twz123]

@twz123 - please assign this to me.

There you go 🚀

1. If command line arg & token file path needs to be deprecated a. print a warning to users that these features are deprecated and removed from next major version ?

That's not decided yet. I've asked for the deprecation of the support for join tokens as CLI arguments only. I think the token file argument is legit and here to stay. If we do this, we also need to update some examples in the docs with the new preferred way of passing around join tokens.

2. if all 3 are specified does the following order of priority sound reasonable? a. argument b. token file c. env variable

   for eg: if json token is specified as an argument (even though it's insecure), it will take the highest priority , followed by token file and then env variable

k0s will already ensure that there's either the token file arg or the token argument, not both, so I think that's fine. I'd say we can just add the fallback to the environment variable of none of the above is given.

[psaradhi]

@twz123 -

Reg implementation -- Which option is preferable ?

Option a: Remove accept json token as cli argument update examples add fall back to env variable

Option b: Print deprecation warning if cli argument is used for passing json token update examples to remove cli argument add fall back to env variable

[twz123]

Definitely option b including the deprecation process to give folks time to adapt.

[twz123]

@psaradhi Are you still planning to work on this?