Hey all, looking for guidance on identity separation / least privilege with ESC and OIDC. Here's my setup. I have infrastructure as code (using the pulumiservice provider) that provisions a bunch of stuff into Pulumi Cloud: ESC environments, configuration, policies, and so on. Separately, my runtime workloads (AWS Lambda and some other services) authenticate to Pulumi using OIDC token exchange, so they assume an AWS role and exchange that for a Pulumi access token to open an ESC environment and pull the values they need. No long lived secrets, which is great. The problem I've run into is identity separation. The identity my Lambda ends up with through the OIDC exchange resolves to the same service account that I use to deploy and manage the infrastructure in the first place (

service-account:ysff347-xxx-xxxx-xxx

). So even when I request a

team

scoped token from inside the Lambda, that token's underlying identity can do a lot more than just read that one team's environment values. It effectively inherits the broader deploy and management privileges of the provisioning identity, which feels like privilege escalation. All I want the workload to be able to do at runtime is open and read one specific environment, nothing else. So my question is really about the right way to model this. How should I structure my IaC and my Pulumi Cloud permissions so that the runtime identity used by my workloads is strictly scoped to reading the environments it needs, and is fully separate from the identity that provisions and manages infrastructure? A few specific things I'm unsure about: How do people keep the provisioning identity and the runtime identity distinct when both end up flowing through OIDC? Is the right answer a dedicated, least privileged service account (or team) for runtime that only has read/open on specific environments, with the OIDC issuer trust mapped to that identity rather than the deploy one? And is there a recommended way to make the token the Lambda receives incapable of anything beyond opening the target environment, regardless of what the deploy identity can do? If anyone has a reference pattern or docs for this separation of duties between deploy time and run time with ESC, I'd really appreciate it. Thanks!

You could do the Pulumi Service Provider stuff with a regular old admin org token, since what you're doing there probably requires admin anyway.

Hey @stocky-restaurant-98004, thanks for the response. Let me paint the picture a bit better so you know what I'm trying to do. Right now I'm running the pulumiservice program from my laptop with an org level admin access token, and it deploys all the roles, teams, and permissions into Pulumi Cloud. Ideally this would be a CI/CD pipeline on GitHub Actions, but for now I'm just testing the flow from my machine. Here's where it gets tricky. When the pulumiservice program creates the teams and environments, all of those resources get an owner of

service-account:xxx-xxx-...

. Then when my workloads (like an AWS Lambda) authenticate to Pulumi via OIDC and request a team scoped token, they do get access to what that specific team is permitted to do, which is what I want. But the exchanged token also resolves to an identity, and that identity is the same

service-account:xxx-xxx-...

. Because of that shared identity, my Lambda, which should only have the team's permissions, effectively also inherits access to everything that service account owns, which is basically all of my infra. That is the escalation I'm worried about. As a test, I went into the Pulumi web UI and changed the owner of the environments from that service account over to my user, and the escalation went away. So that confirms the ownership of the deploying service account is what is leaking the extra access. So what I'm really trying to figure out through this forum is the best way to manage the IaC, specifically how to manage identities, so that we don't run into this kind of permission escalation when a workload is just trying to read secrets. I'm happy to provide more details if there's anything you want me to highlight more. Thanks in advance!

This isn't directly related to the problem (I don't think?), but you can just use your personal token if you're running on a laptop. Org and team tokens are for machines (so using a team token for your workload is definitely appropriate). I'll take your main question to engineering, because that does not sound like the appropriate behavior, and will come back with either a bug fix or additional debugging quesitons.

As I mentioned, my goal is to run it on CI/CD so that's why I'm using an org token locally just for testing purposes so I never would want to use my personal token to deploy the Pulumi resources through the pulumiservice program. I'd really appreciate you escalating this forward as I'm trying to working with the tool. I'm happy to even schedule a call with some key folks on the engineering side to discuss this problem further. Let me know what works best.

@fresh-mechanic-57821 working on this for you as well