Reducing confusion and improving UX for the token join method / shared secret based joining

[strideynet]

It's been a long time since we first introduced the token join method, and since then, a plethora of join methods have been introduced that are much more secure.

There's a few interesting problems that have arisen now that we have more join methods:

• The token join method name is confusing given the resource itself is also generally called a "token".
• The name of a token join token is the secret value, this is unlike the other join methods:
  • We cannot securely reference a token join token in creation/join audit events. Currently, we redact most of the token name. This is a compromise in security for the improvement of user experience, but still doesn't really provide a much nicer UX.
  • It's a potential security foot-gun. It's far too easy to write code which handles resources of an unknown type, and as part of that, to include the name of the token within log messages or errors.
  • This creates confusion with users who then also assume that the name of a delegated join method token is a sensitive value.
• Misconfiguring a join token (e.g forgetting the join_method field) can fall back to creating a token join method - and one with a name that is likely predictable.

What I'd suggest is that we introduce a new shared-secret join method, and phase out usage of the token join method. Given the extent to which customers are likely dependent on existing join tokens working, it's unlikely that we'll be able to fully remove the token join method soon.

The name of a shared-secret join token would not be a secret value - this brings it in line with the other join method types.

Instead, a secret value would be included within the main spec of the resource. For example:

kind: token
version: v2
metadata:
  expires: "2024-11-24T21:45:40.104524Z"
  name: my-join-token
spec:
  join_method: shared-secret
  shared_secret: ONUGIZTVNJVXGZTVONXHK2TENZ2WUZDTNZTHGZDKMZXGI43KNZTGU43OMZVGI3TK

When configuring joining for Teleport or TBot, users would specify both values e.g

tbot start --join-method shared-secret --join-token my-join-token --join-shared-secret ONUGIZTVNJVXGZTVONXHK2TENZ2WUZDTNZTHGZDKMZXGI43KNZTGU43OMZVGI3TK

The secret value could also be read from the configuration file, from the environment or from a path specified in the config or environment.

This new join method could also be a good opportunity to introduce other mechanisms to improve security, e.g:

• Limiting the number of joins that a token can be used for - e.g self destruct. This mechanism is present in similar flows such as in AWS's SSM flow for installation on-prem. This can be more effective than a simple expiry time.

---

Whilst we're certainly on a mission to eliminate shared secrets, we cannot deny that in on-prem environments, without TPMs, there is no alternative.

[strideynet]

Could tie #43402 in this as well