Can't see the option to add approvers list in the solution: need help to add approvers list

[dagwarv]

We have done the complete deployment of the application on app engine with required permissions by following below articles.

https://cloud.google.com/architecture/manage-just-in-time-privileged-access-to-project
https://github.com/GoogleCloudPlatform/jit-access/wiki/Configure-Multi-Party-Approval

After completing the configuring multi party Approval can't see any option or a place to add approver list.

Any help appreciates.

[jpassing]

JIT Access doesn't let you specify a list of approvers. Instead, approval works on a peer-to-peer basis: If you grant two (or more) users the same role, and add the IAM condition has({}.multiPartyApprovalConstraint) to both role bindings, then the 2 users can approve each other's requests.

[dimisjim]

Is it possible to add the ability to create an exclusive list of approvers, so that they only can approve privilege escalations? So essentially to have a third option in https://github.com/GoogleCloudPlatform/jit-access/wiki/Multi-Party-Approval where a requester is just a requester, and doesn't get enrolled into a peer list that allows him/her in the future to approve other peers' requests, thus essentially making the request / approve logic hierarchical rather than peer-based.

[jadsonww]

Privilege escalations by appovers other than reqester is quite useful and enterprise customer may compare it to Azure PIM.
Hope this can be added into JIT.

[jpassing]

I agree that peer-approval (as implemented currently) isn't suitable for all scenarios.

One option would be to introduce a configuration option for a list of approvers, and to apply that list to all MPA roles. However, that also wouldn't be very scalable as the list of approvers might differ by environment or project.

Another option (discussed in #48) would be allow users with Project IAM Admin access approve any MPA request. But there are also some downsides with that approach.

What I'm currently exploring is a mix between the two where...

• you grant eligible access by using roles with a has({}.multiPartyApprovalConstraint) condition just like today, but
• there is a central config file that lets you configure additional rules like "For role X in project Y, only Alice and Bob can approve"

[jadsonww]

Some thoughts and appology first that I don't know the function behind.
Is it possible to add an admin-page ? If we can manage approvers at that page then we don't need to set in configuration options.

As for the scalability, we can use tags on Org/folder level that match the approvers list set on admin-page or even set the key-value pairs to "approver":"jadson@domain" or "role_key1":"jack@domain".

This way we can manage approvers at a high level and only roles in Organizations with tag permission can control access.

[rwblokzijl]

I agree that peer-approval (as implemented currently) isn't suitable for all scenarios.

One option would be to introduce a configuration option for a list of approvers, and to apply that list to all MPA roles. However, that also wouldn't be very scalable as the list of approvers might differ by environment or project.

Another option (discussed in #48) would be allow users with Project IAM Admin access approve any MPA request. But there are also some downsides with that approach.

What I'm currently exploring is a mix between the two where...

• you grant eligible access by using roles with a has({}.multiPartyApprovalConstraint) condition just like today, but
• there is a central config file that lets you configure additional rules like "For role X in project Y, only Alice and Bob can approve"

I agree that IAM Admin is far too extensive a role to grant an approving user.

But perhaps it would be possible to create a second custom role binding that the the JIT app could get approvers from.

Eg.

resource: resource_to_grant_access_to
role: role_to_grant (or empty/dummy, or iam.admin)
members: [approvers]
condition: has({}.jit_approvers) AND has({}.jit_NAME_FOR_CORRELATION) //always evaluates to false

resource: resource_to_grant_access_to
role: role_to_grant
members: [eligible members]
condition: has({}.multiPartyApprovalConstraint) AND has({}.jit_NAME_FOR_CORRELATION)

Correlation between the roles could be done on the basis of jit_NAME_FOR_CORRELATION, or the combination of role and resource.

I don't know how easy it would be to get a list of users from the approvers role, especially within groups and such.