Requirements

• Guardian to collect all pre-existing access from each resource in the provider
• User (admin) to be able to revoke that imported access if needed

Approach:

1. Fetching access

• Option 1: add a flag in the provider config to import access
  Pros : Under the assumption that after the provider is onboarded to guardian there will be no access created outside guardian, this approach would be just sufficient (simpler process)
  Cons : Will only run once when the provider is just created
• Option 2: provide an API endpoint to trigger import access
  Pros : Can be triggered at any time
  Cons : Need to be triggered manually
• Option 3: regularly collect existing access with jobs
  Pros : Continuously control those access created outside guardian
  Cons : Might increase the scope to the Track access drift feature

2. Creating the appeals

The appeal going to be like this:

{
  "id": "", // auto-generated
  "resource_id": "", // added by guardian
  "policy_id": null,
  "policy_version": 0,
  "status": "active",
  "account_type": "", // imported from provider
  "account_id": "", // imported from provider
  "role": "custom", // TODO: need to find a way to map the existing/imported permissions with the roles user defined in the provider
  "options": {},
  "resource": {}, // added by guardian,
  "approvals": [], // depends on the policy
  "details": {},
  "created_by": "", // TODO: for "user" account type, we can use that as the value here, but can't for serviceAccount or other account types
  "creator": null, // depends on the policy. Might be empty because iam config defined in the policy

  // new field(s):
  "imported": true, // imported flag to differentiate with normal (user-created) appeal
  "permissions": [] // https://github.com/odpf/guardian/issues/205 
}

Things to note

Policy

Policy is going to be null since there's no approval flow for the imported access

Account Types

We are going to import pre-existing access for account types that are defined in the allowed_account_types field in the provider config only.

Role

Assuming this bug has been resolved,

• Case 1: the imported access are predefined roles in the Provider Config
  1. Suppose in the provider config we have defined a role named bq-admin which has two permissions: roles/bigquery.dataViewer and roles/bigquery.dataEditor.
  2. In case a user has following access granted outside Guardian: roles/bigquery.dataViewer and roles/bigquery.dataEditor
  3. Those access will be imported and mapped as an appeal with role:bq-admin only. Note that it will also have "permissions": ["roles/bigquery.dataViewer", "roles/bigquery.dataEditor"] in the appeal object
• Case 2: the imported access don't have permissions defined in the provider config
  1. A user has roles/bigquery.metadataViewer access in the bigquery, but that permission was not defined in the provider config.
  2. In that case, each access will be mapped into a single appeal with "role" = "roles/bigquery.metadataViewer" and "permissions" = ["roles/bigquery.metadataViewer"]