If we supported API token scopes, would you be open to us supporting both, or are there other reasons for deprecating user token auth?

Something I like about relying on user authentication is that this token could be rotated without restarting the Coder server and#7992 could be used down the road to limit specific user tokens to specific provisioners versus full API access.

It does feel a little odd passingCODER_SESSION_TOKEN to the provisioner, especially if it is a long-lived token, but that could be said about any automation somebody is trying to do with Coder.

I know it also requires that youcreate a token prior to starting a provisioner and you can only create a token on behalf of another user (machine account) via the REST API which is clunky.

Perhaps, for now, we mention the drawbacks of the token admin auth and avoid "deprecation" language and then we can support it again as a first-class citizen when we add scopes to API tokens.

I think we need to keep supporting user token auth anyway because of local provisioners.

I agree that we'll want to add support for tightly-scoped credentials that can be rotated without restarting Coderd in the future. At present I'm agnostic about whether they are API tokens or some other kind of credential (as a specific example: a JWT signed by an external authority). We should speak with our large customers to get their take on how they'd like to do this auth.

We should speak with our large customers to get their take on how they'd like to do this auth.

Bet you a 🌮 someone is going to ask for Azure Workload Identity

It's a bit confusing to me how the provisioner chart and the Coder chart seemingly accept the same Helm values format despite being different charts. If I am understanding correctly, when:

provisionerDaemon:pskSecretName:"coder-provisioner-psk"

is set for the server values, it will setCODER_PROVISIONER_DAEMON_PSK for the coder server. I see that codehere.

However, when the same values file is used set for the provisioner server, it passes the PSK to the provisioner.

Is this a normal practice for Helm charts? If so, I'm on board. I also wonder, in a follow-up PR, if we should rewrite our workspace proxies Helm to do something similar.

Our workspace proxies Helm is currently on the Coder chart andwhen enabled, Helm changes the entrypoint/command to start a wsproxy server instead of a full server. Our current wsproxy approach is easier for me to wrap my head around, but I can see how it may not be a best practice.

Thevalues.yaml between the charts is very similar, but there are a number of differences. For example, the provisioner chart doesn't accept TLS certificates (because it doesn't serve traffic), doesn't include theservice block, etc.

I kept thepskSecretName value the same, since from a user's perspective, it's the same thing: the name of the K8s secret with the PSK. It's true that the two charts are doing slightly different things with the same piece of information.

I think having different charts for coderd and provisionerd is conceptually easier to understand, rather than a single massive chart with lots of values that don't make sense when running provisioners. Workspace proxies are conceptually much more similar to Coderd in that they serve traffic, so maybe it's ok to keep those two use cases in a single chart. We should keep an eye on how much they diverge and split it into two charts if we're finding there is a lot of either-or config knobs.