Bulk access approvals

[Chief-Rishab]

Summary
Guardian supports only a single user appeal to be granted/revoked currently . In case we want to grant access to n users to a particular resource with the same permissions, then according to the current flow n appeals have to be made and approved by all the approvers for the same resource.

Some providers like GCS/BQ have a group entity, using which the access can be granted to the entire group at once when the appeal is approved on Guardian but for other providers we don't have this feasibility.

Proposed solution
Similar to the group userType in Google Cloud Storage, a team/group in Guardian will consist of multiple user emails/serviceAccounts which have been added to this group by the Group Owner. The group owner will create a single Appeal to get the access for the entire set of users from the Approvers.

For example: If we have a group name DE Interns and say 5 users need access to a Github Organization ODPF to be added as a collaborator. The Approvers will not have to separately give access to all of them, and only a single approval would do.

@rahmatrhd @ravisuhag @AkarshSatija @mabdh @bsushmith @singhvikash11

[bsushmith]

@Chief-Rishab This is an interesting feature. 👍

Assuming that the new type - team/group will be created in guardian in addition to user & serviceAccount.
I have a couple of questions -

1. Would this team/group be comprising of only user's or a combination of users & serviceAccounts or even non-human bot accounts?

If Shield is the source for group information,

2. Do we want only the team admins to be able to raise the appeal? why not open it for the team members?
   Example: As a user of DE users - I should be able to raise an appeal for the entire team that I am part of.
   A) if not, when would the team admin check take place - when the API call is made or when the appeal is processed/validated inside guardian?

3. Let's say - we have an approval step in our existing policy where the appeals raised by an individual are vetted by their individual's manager before it goes to the other various manual approval steps. How would it work in this case?

4. What would happen in case a team member already has an appeal approved for it and access granted for 180 days, and also through group access for 90 days? After 90 days, will that member lose access along with others?

5. Since we are planning to onboard and support invitation-based providers like github & gitlab - how would this work in those cases?

[Chief-Rishab]

1. I don't think having different type of accounts would make any difference, initially I wanted to keep both user and serviceAccounts (as you mentioned bot accounts may also be included)@rahmatrhd what do you think on this?

2. In analogy to this issue(Appeal request on behalf of other user #212). I think any user from the team can be this Group Owner and create the appeal on group's behalf.

3. @Rahmat mentioned it in this issue(Appeal request on behalf of other user #212) that the user details in creator field right now is based on the created_by field.
   
   Similarly in this case the Group Owner will be the appeal creator and for manager's approval the Group Owner's manager will be considered for approval.
   
   In the concluding comment of the same issue, @ravisuhag said that the creator will own the entire appeal lifecycle and appeal will not show in account_id's appeals. Can we follow the same constraints in here?

[rahmatrhd]

@bsushmith @Chief-Rishab

1. having different account types within a group could cause difficulty when creating an appeal, like for example if the group consists of user and serviceAccount but the appeal created to a metabase resource that doesn't support serviceAccount. Only limiting a group to have one account type would be easier to handle. But that can be controlled only if the group is managed in guardian.

2. even I'm thinking anyone can create an appeal for any group as they can create an appeal for a group account type in bigquery/gcs

3. agreen with @Chief-Rishab

4. this just reminded me that this case is also happening for the additional appeals. Need to discuss this separately

5. this should only affect the process of appeal creation until it is approved and creates accesses for the members of the group (one appeal has many accesses). The lifecycle of the access itself will go independently as it is

[Chief-Rishab]

For the 4th point mentioned by @bsushmith and @rahmatrhd , I was thinking instead of creating multiple appeals for the same user, can we instead update the duration of the previous one with the new deadline?

Or whenever the user creates an additional appeal for the same resource, we first revoke the previous one and create the new one altogether? There can be other approaches for this with their own pros and cons. I will create another Github issue to discuss this existing problem to handle the additional appeals conflict.

[bsushmith]

I'm with the second approach.
Using the first approach, it's difficult to track the appeal lifecycle or status as the duration gets updated modifying the appeal.

[bsushmith]

@rahmatrhd @Chief-Rishab @singhvikash11
On Point 1 - Why not restrict this to only the user type for simplicity? Bringing serviceAccounts brings a whole lot of complexity for very little return.

serviceAccounts are generally used whenever there is a use case to represent a non-human account to do things automated way - which in general has its own set of guidelines and approval flows. This issue specifically deals with access to a group of users or all members of a team - which are similar for all user type accounts.

Whenever guardian acts on a group - we can do operations only on user type accounts in the group, and ignore serviceAccounts. With this, we don't need to manage team/group definitions at guardian itself.

WDYT ?

[ravisuhag]

I think we should keep team/group out of Guardian. We should think of this as a case of bulk appeals. I think this information can be provided to Guardian in two ways.

1. In appeal user can take the name of the team and fetch the list of details from the identity provider. Each identity provider can start providing group details.
2. List of users can be passed in the appeal itself.

[Chief-Rishab]

During our initial discussion, on the same lines as point 1 which @ravisuhag mentioned, @rahmatrhd suggested adding this
team/group entity in Shield instead of Guardian, if we are to proceed with this approach. This will ensure that the group identity/membership is out of Guardian's scope.

Instead, we can also take the same approach as the Bulk Revoke Appeals issue, we can pass the list of users and grant access to all in a single appeal.

Which one should we proceed with further? @bsushmith @singhvikash11

[singhvikash11]

@Chief-Rishab I liked the above idea of bulk appeal approval for a group from outside of the guardian.

Even the lifecycle of members(member add to a group, member remove to a group) belonging to a group will be managed outside of the guardian.