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
There is currently no way to add stacks to group permissions as they are created (so far as I can tell) and the grant stack access does not allow wildcards:
Right now we have something like 80 stacks across dozens of projects. Manually adding these to permission sets is not great.
Ideally, you could do something like grant a group permission to */dev to grant access to "all projects with stacks named dev" or foobar/* to grant access to "all stacks in the foobar project". At the very least I think the */dev form should be added.
This would be a very nice improvement as it is kind of a pain for onboarding larger engineering organizations (eg you start with a POC and want to expand it globally).
The text was updated successfully, but these errors were encountered:
Thank you for this feedback! We are currently kicking off a project to handle assignment of stacks to Teams so I would love to get your thoughts once we have some options designed.
In terms of workarounds today there are 3:
You can add a team flag on stack init to auto add it to a team or multiple teams blog here
You can use the Pulumi Service Provider to add stacks into Teams and manage permissions in a pulumi project. You can implement custom logic as well.
You can use the REST API directly and write a script to move stacks to teams based on your requirements.
There is currently no way to add stacks to group permissions as they are created (so far as I can tell) and the grant stack access does not allow wildcards:
Right now we have something like 80 stacks across dozens of projects. Manually adding these to permission sets is not great.
Ideally, you could do something like grant a group permission to
*/dev
to grant access to "all projects with stacks nameddev
" orfoobar/*
to grant access to "all stacks in thefoobar
project". At the very least I think the*/dev
form should be added.This would be a very nice improvement as it is kind of a pain for onboarding larger engineering organizations (eg you start with a POC and want to expand it globally).
The text was updated successfully, but these errors were encountered: