Unauthorised access tracking about guardian HOT 7 CLOSED

schema changes

- type Access struct {
+ type Grant struct {
	...
- 	Grant		string // policy | import
+ 	Source		string // appeal | import
  	Status		string // active | inactive
+ 	ProviderStatus	string // active | inactive
- 	CreatedBy	string // [email protected] 
+ 	Owner		*string // [email protected] | nil
  	...
  }

scenarios

1. will rename access entity to grant to avoid confusion since "access" is the main scope of guardian itself
2. rename grant to source with value appeal for grant that is created from appeal, and import for grant that is imported from provider
3. add ProviderStatus to track the status of the actual access in the provider
4. rename created_by to owner. For source=appeal Grants, the value of this field going to be the Appeal.created_by, and for source=import, initial value going to be nil until the Grant got assigned to someone

from guardian.

continuing the discussion for this.

assuming we have completed these issues:

1. #246
2. #206

there are two kind of cases that we want to collect the information of:

1. accesses that are created from guardian but don't exist in the provider
2. existing accesses in the provider that are not created through the guardian

Collecting information

The current decided approach in #206 is only for fetching accesses in provider and create the accesses for them. By that, apart from the access state/mapping itself, we only have the creation source information whether the access is created through guardian with approval flow or from outside of guardian (grant=import/policy). Additional information that needs to be added is the current activeness of each access in the provider itself.

We can add an active_in_provider: boolean flag in the access entity for tracking the access activeness. This is different with status="active where status is for the access status in guardian and active_in_provider is for the current status in the provider. We can use the "import existing access" function to update this information in accesses. And since in #206 it was decided that importing existing access going to be an api-based action, maybe we can consider it to run on a job as well so that the active_in_provider information is kept up to date.

Presenting information

Options:

1. add more query parameters in the list accesses API so that client can generate report and customize by passing params
   • pros: more flexible and let the client generate their own report based on their use case
2. create a new API that returns the summary of the track drift result. It can be at the provider level (GET /providers/report or GET /providers/:id/report) or resource level (GET /resources/report or GET /resources/:id/report)
   • pros: information is summarized, and also can show list of recommendations
   • cons: can't be customized, and the report might not suits what the user needs

from guardian.

@rahmatrhd will both of these statuses live in access objects? If yes, we will have three fields to be tracked?

grant: policy/import
active_in_provider/provider_status: true/false
active_in_policy/policy_status: true/false

from guardian.

for tracking access drift, essentially we only need to track two statuses which are active_in_provider: true/false and status: pending/active/inactive (active_in_policy/policy_status). While grant is only to track the creation of the access itself (whether created through guardian (with approval) or not)

from guardian.

And all these statuses are at access object or status is on appeal?

from guardian.

if we use active_in_provider: true/false, do we assume (only track) if provider only have two states of activeness active & inactive and ignore other possible statuses (if any)?

from guardian.

@ravisuhag grant, status, and active_in_provider are in access

@mabdh makes sense, I think we can make it equivalent to access.status: pending/canceled/active/inactive

from guardian.