How can we restrict a Pulumi access-token to stacks of one Git repository? We’re going to use Pulumi in CI for our microservices. Each microservice’s deployment config is in its own Git repository. In the CI, we would like to use one service-account, here worked around with restricted access-tokens, for each microservice.

Hey @stocky-island-3676, currently that is not possible. But the good news is that we are literally designing some features to address this scenario right now. I cannot commit on when exactly we’ll ship it though. In the mean time, you would just need to resort to using different Pulumi accounts and then controlling access to certain stacks using Pulumi’s support for Teams. (Note however that this role-based access control is only available at the Team Pro tier and higher.)

@colossal-beach-47527 Just stumbled upon it once again. Your workaround would mean that we have one account per microservice??? I.e. we should pay one “user”-account for each of them? Or did I misunderstand sth.?

If you wanted a Pulumi account that only had access to one specific stack, then yes, you would need to create a separate Pulumi account and then use our role-based access control features to only grant that one user to that one stack. Obviously not ideal, but like I said, we’ll make this easier in the future. But if your concern is about the security implications if, for example, your CI/CD system were compromised, it’s worth noting that the Pulumi credentials aren’t nearly as important as the cloud provider credentials used to actually make resource changes. In other words, having a different Pulumi service account for each microservice is less important than having a separate AWS/GCP/Azure credential used for the CI jobs that updates your stacks. (Since those cloud resource provider credentials provide access to your resources, while the Pulumi credentials only provide access to the topology of those resources.)

CI-compromise is not my concern, actually. Problems with current situation: 1. The token is bound to an employee. If he/she leaves the company or department, all CI jobs using that token will fail immediately. Sure, constantly changing credentials would be secure, but it’s inconvenient. 2. Accidential wrong setting in the CI config will overwrite stack of another project. Whereas project is a Github repo in our case. We’ll see if our developers would use the preview at all which may prevent this.

having a different Pulumi service account for each microservice is less important than having a separate AWS/GCP/Azure credential used for the CI jobs that updates your stacks.

That’s right and we try to achieve this for that reason.