Skip to content

added impersonation flow for get groups

Rustam Lotsmanenko (EPAM) requested to merge impersonation-api into master

Description:

Implementation for osdu/platform/data-flow/ingestion/home#54. Was moved from GC module to core module.

Endpoint /groups was updated, if the request contains header on-behalf-of request will be passed to new method and authorization filters that evaluate if impersonation is allowed:

curl --location 'https://community.gcp.gnrg-osdu.projects.epam.com/api/entitlements/v2/groups' \
--header 'Data-Partition-Id: osdu' \
--header 'on-behalf-of: user-to-impersonate@test.com' \
--header 'Authorization: Bearer <IMPERSONATOR_TOKEN>

If the requester doesn't have a group users.datalake.delegation, the request will be forbidden:

{
    "code": 403,
    "reason": "Forbidden",
    "message": "Impersonation not allowed for rustam_lotsmanenko@osdu-gcp.go3-nrg.projects.epam.com"
}

If the target user to be impersonated doesn't have a group users.datalake.impersonation the request will be forbidden:

{
    "code": 403,
    "reason": "Forbidden",
    "message": "Impersonation not allowed for user-to-impersonate@test.com"
}

Thus least privilege principle is respected, bootstrapping was not updated and by default, none of the users have any of those groups.
An exception is a tenant service account, which by default is owner of all groups. For that was added validation that prevent the impersonation of a tenant service account.

Few points to mention:

  • Solution respects the least privilege principle
  • Impact on the platform is minimal as the same endpoint /groups is used, no changes are required in services except DAGs that should impersonate the user.

How to test:

via integration tests.

Changes include:

  • Refactor (a non-breaking change that improves code maintainability).
  • Bugfix (a non-breaking change that solves an issue).
  • New feature (a non-breaking change that adds functionality).
  • Breaking change (a change that is not backward-compatible and/or changes current functionality).

Changes in:

  • Common code

Dev Checklist:

  • Added Unit Tests, wherever applicable.
  • Updated the Readme, if applicable.
  • Existing Tests pass
  • Verified functionality locally
  • Self Reviewed my code for formatting and complex business logic.
Edited by Rustam Lotsmanenko (EPAM)

Merge request reports