teleport-kube-agent pitfall: `tokenName` vs `token_name`

[programmerq]

Current Behavior

When setting joinParams in the values.yaml file for teleport-kube-agent, it is easy to write token_name instead of tokenName.

In teleport.yaml, snake_case is used:

join_params:
  token_name: foo
  method: token

but in the helm values, camelCase is used:

joinParams:
  tokenName: foo
  method: token

It is very easy to grab token_name from a teleport.yaml example, and end up with a silent failure. The tokenName field is empty, so an empty token name is tried, and that can cause a warning and then error: WARN Empty config value file: /etc/teleport-secrets/auth-token utils/config.go:45 ... ERRO [PROC:1] Kube failed to establish connection to cluster: rpc error: code = InvalidArgument desc = missing parameter Token. pid:7.1 service/connect.go:123

Expected Behavior

The helm chart should be more helpful here. Here are some possible things that would make the experience better:

• It could fail fast when tokenName is unpopulated and joinTokenSecret.create is true. The error could explain that helm prefers camelCase.
• It could fail if token_name is used.
• It could just use the snake case token_name as-is if it is set.

Bug details:

• Teleport version - Teleport Enterprise v14.1.0 git:api/v14.1.0-0-g508ccc5 go1.21.3
• Recreation steps
• Debug logs

[taraspos]

I just faced the same pitfall with teleport-cluster/.

I added configuration like:

    authentication:
      local_auth: false

but it had to be camel case:

    authentication:
      localAuth: false

https://goteleport.com/docs/reference/helm-reference/teleport-cluster/#authenticationlocalauth