How would the audience value be determined? Perhaps a new top-level spec element in the Workspace and/or Stack? Would it be the literal audience or would it be higher-level parameter(s) like organization (similar to pulumi/auth-actions)?
How is the token consumed by the CLI? Ideally an environment variable would be natively supported, similar to PULUMI_ACCESS_TOKEN. Otherwise one would need to exchange the token by hand on each RPC operation. Ideally we'd teach the CLI to exchange the token on-the-fly, to allow for long-running stacks (necessitating a mid-flight refresh).
As a user, I would like to perform updates against the Pulumi Cloud backend without needing to hard-code an access token.
A possible implementation would be to automatically mount an OIDC service account token using a projected volume, as provided by Kubernetes:
How would the audience value be determined? Perhaps a new top-level spec element in the
Workspace
and/orStack
? Would it be the literalaudience
or would it be higher-level parameter(s) likeorganization
(similar to pulumi/auth-actions)?How is the token consumed by the CLI? Ideally an environment variable would be natively supported, similar to
PULUMI_ACCESS_TOKEN
. Otherwise one would need to exchange the token by hand on each RPC operation. Ideally we'd teach the CLI to exchange the token on-the-fly, to allow for long-running stacks (necessitating a mid-flight refresh).