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
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).
The text was updated successfully, but these errors were encountered:
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).The text was updated successfully, but these errors were encountered: