Activate role on organizational level
Hi,
It would be great if it was possible to activate JIT controlled roles on the organization (and possibly folder) level too. The use case is the following: our organization uses JIT to control roles and provide just in time privileges to everyone in the company. That said there are "central" teams who have roles on the organizational or sometimes folder level - currently it's not possible for them to activate their role on anything else but a project.
A real life scenario is that if the role Security Admin was JIT controlled on the organizational level, there is no option to activate it so role owners could use their privileges on the org level instead of just a single project.
Hopefully this makes sense and it can be added as an enhancement.
Many thanks!
In general, I'd say that it's a good practice to activate a role for an individual project only, even if you've been granted elibible access to an entire folder or organization.
But your're right that there are some activities for which this project-based approach doesn't work -- such as for modifying org- or folder level IAM policies or organizational policies, or managing VPC-SC perimeters.
Technically, I think it would be possibe to extend the tool so that you can not only select projects (in the project dropdown), but also folders or the organization node. The only downside here is that it might steer users away from the good practice of activating roles for individual projects only.
Thanks for replying and considering for enhancement. I agree it's best practice and most secure to activate roles only where it's necessary (project level) but as you say there are quite a few things that need to be done on the org level. However, not having an option to activate roles on org level would only leave us to have "permanent" roles assigned on org level which is absolutely not ideal and secure.
In my view, having a JIT controlled and managed role(s) on org level is still much better than "permanently assigned" roles on the same level.
Many thanks again!
I wonder is it possible to configure an org level permission or role which can only add permissions to projects, but not have access to those projects themselves?
@rojomisin not sure if I understand your question... but are you thinking of something like delegated role granting to prevent users from granting themselves additional access?
Whilst I would like to be able to just activate the roles could we at least improve the error messaging on these guys.
Currently if you try to activate a permissions that can't be bound at a project level, but shows up because you have inherited it when you try to activate it you just get the mysterious 403 Forbidden Would be nice if we could pass through the error message Role (roles/orgpolicy.policyAdmin) does not exist in the resource's hierarchy. or something to let you know that whilst the role has the jit constraint you cant use it.
In my use case I have added a whole swathe of privileged roles to include the jit constraint. But most of these are actually admin esk roles that only exist on billing accounts or folder admins or org level. I would really love if i could activate my admin perms at a specific project and anything that cant be activated at a project level is activated at the lowest level it can support.
I agree that the error message is poor, and I'll fix that.
This activation at the organization level would be very useful, for a use case we currently have at our company:
- All the org-level groups should only have the high-level roles whenever required.
One particular example:
- We only want to provide the Billing Administrator role (at org level) for the billing group when we need to do something (example: approve a marketplace offer).
This would actually be very important for us to actually implement jit in our organization, because our main goal is to use it for org-level, not only project-level.
This feature is now available in JIT Groups 2.1.
In the privileges section of a group, you can now include role bindings for folders or organizations, and narrow them down using IAM conditions if necessary. For example:
privileges:
iam:
- resource: organizations/123
role: roles/resourcemanager.organizationViewer
description: "View basic details about the organization"
- resource: folders/12345
role: roles/compute.viewer
description: "View all Compute resources in folder 12345"
- resource: folders/12345
role: roles/compute.admin
condition: "resource.name.contains('/zones/asia-southeast1-a/')"
description: "Administrate Compute resources in folder 12345 for zone asia-southeast1-a"