GitHub app integration - Pulumi preview fails with permission errors for any stacks that use ESC environments

[tom-fletcher]

What happened?

When using Pulumi deployments with ESC, a Team account and the GitHub app integration configured for push/pull deployments, previews fail when running from GitHub with the following error:

error: getting stack configuration: opening environment: [0] 
Diags: You do not have permission to perform this operation.

Failures only occur from the GitHub app deployment when run on GitHub Pull Request or GitHub Push. Running a preview/update from the CLI, or merging the stack changes and then running a preview/update from the Pulumi Cloud console both work as expected without any permission errors.

Example

The stack config file looks similar to:

environment:
  - <name_of_service>

and the ESC environment looks like:

values:
  pulumiConfig:
    service:apiKey:
      fn::secret:
        ciphertext: ...

Output of pulumi about

CLI
Version 3.115.2 Go Version go1.22.2 Go Compiler gc

Plugins KIND NAME VERSION language nodejs unknown

Host
OS darwin Version 13.6.6 Arch x86_64

Additional context

This appears to be an extension of issue pulumi/pulumi#15484.

My guess is that the GitHub integration app is configured to run with it's own permissions, that do not include the open or write permission that are required to access environments?

Contributing

Vote on this issue by adding a 👍 reaction. To contribute a fix for this issue, leave a comment (and link to your pull request, if you've opened one already).

[komalali]

Hey! Looks like you're running into some issues around deployment permissions. You might find this doc helpful: https://www.pulumi.com/docs/pulumi-cloud/deployments/reference/#deployment-permissions

[tom-fletcher]

Thanks for the link - the root cause is definitely around those default deployment permissions!

Setting Deployment permissions

I am on a Team account, so I don't believe there is any access to modify default stack/organization permissions? This leaves only the second option, which is to set a PULUMI_ACCESS_TOKEN on the stack deployment settings.

I had initially avoided this as the the Deployment settings page actually tells you not to do this 🙂

Ignoring the warning though, I have just tested this, and setting the key does work and allows the GitHub action to perform the deploy without errors. So this gives a workaround. However...

Defaults

My understanding is that this means that to use Environments with the GitHub integration, every stack now has to have a PULUMI_ACCESS_TOKEN added to it. So we are back to a state where it is necessary to encrypt a common secret for every stack once again. Not having to do this was one of the attractive things about Environments (accepting that doing this with one token is slightly easier than many).

To me if feels like the ephemeral stack token should have OPEN access to the ESC environments listed in the stack's configuration file by default. I definitely expected this would be the case. This would make using Environments with GitHub far more seamless, and remove the need to add an access token to every stack.

[komalali]

the Deployment settings page actually tells you not to do this

Thanks for surfacing this, we need to fix that!

I am on a Team account, so I don't believe there is any access to modify default stack/organization permissions

Ah, sorry, I missed that you're on a Team account in your initial message. That's fair feedback, will start the conversation internally about how we can improve this for folks that may not have control over default permissions.

[tom-fletcher]

Ah, sorry, I missed that you're on a Team account in your initial message. That's fair feedback, will start the conversation internally about how we can improve this for folks that may not have control over default permissions.

I've had a bit more of a look at the Team account and permissions, so have some further feedback for the team, hopefully of some help!

GitHub access token

• Having permissions to access environments by default on the GitHub integration would be great, and probably the simplest option to implement
• Alternatively, if we could set a PERSONAL_ACCESS_TOKEN that applies to all Deployments on all stacks across the organization this would also solve the issue - but there isn't any provision for this at the moment and I imagine this is much a bigger piece of work

Member access

• A Team account can only have one admin, everyone else is a member
• It looks like currently only the admin on a Team account can create/view secrets in Environments, and a member does not have any access to these (they can see values)
• I understand that fine-grained RBAC is an Enterprise feature (and you need your differentiators!) however I think with a Team it would be useful to either:
  • Even with the principles of least privilege, Teams are limited to 10 people so the trust levels are different. It might be better user experience to allow all Team account members to access secrets - once an org gets to a size where that is an issue, they should be moving to Enterprise anyway. This again is probably the simpler solution. or
  • Have an additional member type that is member with environment secrets or similar

I see you have this under consideration at the moment, so I will finish with this feedback and just say that if you need any external testing then I am happy to help. 🙂