You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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:
As an argument on the command line
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
The text was updated successfully, but these errors were encountered:
Is your feature request related to a problem? Please describe.
There's currently two ways of passing the join token to
k0s controller
ork0s worker
:--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
The text was updated successfully, but these errors were encountered: