because I’m an Admin in the slack org is it inferr...
# general
o
because I’m an Admin in the slack org is it inferring/granting me something I can’t see?
w
I expect you are an
Admin
in the organization, which gives you
ADMIN
permission for all stacks in the organization. See https://pulumi.io/reference/service/roles-and-access-controls.html#default-stack-permission for more details. Definitively interested in any feedback on the set of options you'd like for configuring these roles to fit your organization better. cc @colossal-beach-47527 and @clever-sunset-76585.
c
(subscribe)
c
Yeah, +1 to what Luke was saying. Would love your feedback here, especially were things are surprising. Members with the
ADMIN
role have full access to all stacks. But one thing that we don’t show in the UI (and will fix that soon), is that the person who created the stack may have permissions to modify it, even if the organization’s default stack settings don’t allow for it. i.e. if the organization allows members to create new stacks, but the default stack permission is
READ
, we still grant the person who created the stack read/write access. Otherwise being able to create a stack but not use it would be kind of lame. Like I said, that’s one of the finer details of our RBAC settings that we don’t show in the UI. But it will be fixed in the next week or so.
o
ok cool - thanks for the feedback. I have some thoughts and will write up a brief Google doc
kind of experience plus wishlist
I mentioned this in a conversation with Cameron the other day and it dovetails a little bit with this. Naming of things
Or I should say visualizing the naming of things. The stacks have absolute names but in the UI they can show up 3 different ways.
Also, it would be nice to ensure nobody but Admin and/or the defined group would have access to any stack created for x, y or z environments
if any stack gets stood up in alpha, prod or staging - I want this set of permissions to apply
as far as I can tell there is no dynamic permissioning - you have to explicitly add them
c
The stacks have absolute names but in the UI they can show up 3 different ways.
Yeah, that’s a bug. It will be fixed sometime in the next few weeks. (Sorry about that :P)
it would be nice to ensure nobody but Admin and/or the defined group would have access to any stack created for x, y or z environments
Yeah. We’ll add a feature where you can (1) drill into an organization member and see what stack(s) they have access to, and how they were granted that access. And (2) from a stack, go backwards and see which teams and users have access to it. That should help determining that. (Again, should be fixed in a few weeks. Sorry we don’t have that right now.)
as far as I can tell there is no dynamic permissioning - you have to explicitly add them
That is generally correct. To get access to a stack, you need to be explicitly added. e.g. that stack added to an existing Team, or you get added to a Team.