DataWarehouse Authorization and Permission

How DataWarehouse hides internal data and handles user access

DataWarehouse is powered by Django, which comes with a built-in permissions system to manage users and group access to read and write operations per table, e.g. who can submit results, create issues and remove occurrences. However, it doesn’t provide a way to handle object-level permissions, what in our case means basically which users should be able to interact with internal objects.

Django Rest Framework offers a framework to design custom permissions, which we’ve used to define 3 levels of visibility in our “PolicyAuthorizationPermission”: public, internal and retrigger. In summary, we’ve created the Policy table to connect database objects to user groups, i.e objects (Issue and KCIDBCheckout) point to one of 3 policies, each with a read_group and write_group:

  1. public: Anyone can read these objects (read_group=None). Users in the policy_public_write group can update objects with this policy.
  2. internal: Users in the policy_internal_read group can access objects with this policy. Users in the policy_internal_write group can update objects with this policy.
  3. retrigger: Users in the policy_retrigger_rw group can access and update objects with this policy. This data has a debug nature, and is submitted by the cki-ci-bot’s pipelines, triggered when testing merge requests. This policy is used only by service-accounts, however superusers have the same privileges.

LDAP/Rover Group Sync

We have an hourly cronjob (UpdateLdapGroupMembers) to keep DW groups synchronized to LDAP/Rover groups, which is the preferable way to handle permissions. It works as a simple 1:1 relationship between a DW Group and a LDAP query, managed by admin/LDAP-group-link.

Triaging permissions for QE Teams

To enable an user to triage issues, you need to assign them to the Triagers and public-write groups. To triage internal data, they would also need internal-read and internal-write.

In the past, that meant adding them to the following Rover groups, which might still be the case for some users:

Rover Group DW Groups
cki-datawarehouse-public-write public-write
cki-datawarehouse-internal-write internal-write
linux-eng-pe internal-read
bugzilla-redhat internal-read
cki-kernel-tests-reviewers public-write, internal-write, Triagers

Nowadays, we have been using a team-based permission management, granting triaging permissions to all members of interested QE teams, creating LDAP group link for the four groups mentioned above. Currently, there are 4 teams enabled for this:

API authentication and permission

In short, we are using DRF token authentication, which should provide users with the same permissions they have when accessing the website in the browser. There’s a little bit of additional information about it in DataWarehouse API permissions documentation, but we are planning to move to OIDC authentication.