Hey folks 👋 trying to wrap my head around service accounts (ref) on Pulumi and could use a sanity check on the intended workflow. My mental model: I create a service account (did this via the web UI), and then I'd associate it with one or more teams so it inherits those teams' permissions, which becomes its scope. I'd then generate an access token for it and hand that token to my CI/CD so the pipeline acts as this service account (and only this service account). Where I'm stuck: 1. UI: After creating the service account, I don't see any way to (a) attach it to a team, or (b) generate an access token for it. So I can't actually use it anywhere yet. 2. Docs/REST API: The v2 "add service account items" endpoint looks like it supports adding items like access tokens and team memberships to an existing service account. But I can't tell from the request body how I'd actually generate the token / assign a team, or how I'd get the resulting token value back (it doesn't seem to be returned in the response). What I'm ultimately trying to do: have a dedicated service account that's used only by my CI/CD, scoped to specific teams, authenticating via its own token. So my questions: • How do I generate an access token and assign a team to a service account via the REST API, and what does the request body actually look like for each? • When I add an access-token item that way, how/where do I retrieve the resulting token value so I can plug it into CI/CD? • Is there a way to assume the identity of this service account when making a request to Pulumi via OIDC (rather than a long-lived token)? • Is any of this also doable in the UI, or is the REST API the intended path for now? Looking forward to hearing from the community!

Hey Vasu! Hm yeah the services REST API endpoint there is for Services inside Pulumi Cloud: a logical grouping of stacks + ESC environments to compose a "Service". It's not related to accounts or permissions. I'll work on getting the docs corrected here. Team token (Pro/Enterprise): go to Settings > Access Management > Teams > (your team) > Access Tokens > Create Token. A team admin or org admin can do it. The token gets whatever roles the team has, plus your org's default member permissions. E.g. If default stack access is Read, it can read every stack. You might want to tighten that if you need strict scoping. Org token: Settings > Access Management > Access Tokens. Assign a custom role so it only gets the scopes the pipeline needs. If you want to script it: Create Team Token (

POST /api/orgs/{org}/teams/{team}/tokens

) and Create Org Token (

POST /api/orgs/{org}/tokens

). The token value comes back in the response and isn't available after. Using either one: store it as a secret in your CI and expose it as

PULUMI_ACCESS_TOKEN

.

pulumi login

and

pulumi up

pick it up. OIDC: you can skip the long-lived token. Register your CI provider under OIDC Issuers in Pulumi Cloud, then have the job exchange its OIDC token for a short-lived Pulumi access token through the token exchange API. For GitHub Actions,

pulumi/auth-actions

wraps that. By default the exchanged token isn't admin; request that scope if you need it.

@future-hairdresser-70637 Thanks for the clarification, that's really helpful. Good to know the Services REST API is about grouping stacks + ESC environments and isn't related to accounts or permissions. That definitely cleared up some of my confusion (and appreciate you getting the docs corrected). To give a bit more context on why I went down the service account path: I already know how team tokens, org tokens, and OIDC work and how to wire them into CI. What I'm actually after is the concept of a service account as a distinct identity in Pulumi. I want two different access patterns to be backed by two separate identities, and I'm not sure how (or whether) I can create distinct service accounts for that. I'm running into this in a related thread where I dig into where I keep seeing references to `service-account`: https://pulumi-community.slack.com/archives/C0602S4P4T1/p1790950353682849?thread_ts=1790889958.895209&cid=C0602S4P4T1. In this thread I'm mentioning that my two different access patterns are resolving to the same identity of the same exact service account, and that is leading to privilege escalation. I go into more detail on that in the thread. If you have any thoughts there, I'd love to hear them, since I'm actively trying to work through it and hitting some walls. Thanks again!