DataWarehouse Authorization and Permission
TL;DR
- There are 3 visibility (
Policy) levels: public, internal, retrigger; - Objects (
IssueandKCIDBCheckout+ children) visibility is defined by thePolicythey are created with; - Grant permissions to Users using DW Groups; preferably using [LDAP group links][admin-ldapgrouplink];
- DW Groups required to triage internal objects: “Triagers”, “policy_public_write”, “policy_internal_read”, “policy_internal_write”.
- CKI team members can be assigned to the DW Group “CKI Team”, or be enabled as a superuser.
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:
- public: Anyone can read these objects (
read_group=None). Users in thepolicy_public_writegroup can update objects with this policy. - internal: Users in the
policy_internal_readgroup can access objects with this policy. Users in thepolicy_internal_writegroup can update objects with this policy. - retrigger: Users in the
policy_retrigger_rwgroup 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.
Triagers: Grant permission to add and delete issue occurrences, among other things.policy_public_write: Grant permission to create, update and delete public data.policy_internal_read: Grant permission to list and read public data.policy_internal_write: Grant permission to create, update and delete internal data.
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:
- Desktop QE (desktop-qe)
- Kernel QE (kernel-qe)
- Kernel SE (rhel-sst-se-kernel)
- Linux QE (linux-qe)
- Network QE (network-qe)
Enabling triaging for a new QE Team
To grant permission to a new team:
- get the LDAP query from their Rover page
- [add a record of LDAP group link][add-ldap-link], pointing to the 4 DW Groups:
Triagers,public-write,internal-write,internal-write.
Service account can’t be managed through Rover, therefore their policies are granted setting them as “extra users” in a fitting LDAP group link.
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.