DataWarehouse Authorization and Permission

DataWarehouse uses Django Auth Module with Users, Groups and Permissions that limit operations. On top of that, we have object-level permission, combining Groups with our custom PolicyAuthorizationBackend to distinguish between Public and Internal (Red Hat) data, and also data from retriggered pipelines.

Creating an Account

If you are a Red Hat associate, your account will be created once you have logged in successfully via OIDC for the first time. Otherwise, accounts are currently managed by the CKI team, reachable through cki-project@redhat.com, Red Hat associates can also ping us in the internal Slack channel: #team-kernel-cki.

Consuming the API

The API follows the same permission policies from standard website usage, which will be explained below, other than that, see API auth documentation for information regarding out-of-browser authentication.

Permission Groups

Policies

There are 3 levels of visibility, in DataWarehouse: public, internal and retrigger, each with a DW group associated with read and write permissions. The policies apply to KCIDBCheckouts and Issues, and are propagated to their children, i.e. KCIDBBuild, KCIDBTest, KCIDBTestResults, Artifacts, IssueOccurrences, and IssueRegexes:

1. public: (read=None,write="policy_public_write")

   Public data allows read operations (GET requests) without authentication, while write operations (POST, PUT, DELETE requests), e.g. who can submit results, require basic permissions, which are granted to members of the policy_public_write DW group.

2. internal:(read="policy_internal_read",write="policy_internal_write")

   Certain records pertaining to Red Hat data are restricted to internal users with appropriate read and write permissions, which are granted to members of policy_internal_read and policy_internal_write, respectively.

3. retrigger:(read="policy_retrigger_rw",write="policy_retrigger_rw")

   Users in the policy_retrigger_rw DW 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.

If you are a DataWarehouse contributor, you might want to know that the implementation is based on Django Rest Framework framework of custom permissions, which we’ve used to define our PolicyAuthorizationPermission and PolicyAuthorizationBackend, then applied it to most models’ default queryset subclassing AuthorizedQuerySet.

Triaging permissions for QE Teams

To enable an user to manipulate issues, their occurrences and regexes, in addition to the relevant object-level read/write policy groups, they need to be part of the Triagers DW group, which will grant them permission to read/write operations on those objects.

How to be a member of a DW group?

DataWarehouse admins don’t manage DW groups directly, instead they manage admin/LDAP-group-link, where they assign DW groups:

• to service-accounts and external users listed as “extra users” in the LDAP-group-link.
• to users who match an LDAP/Rover query (for Red Hat associates). The LDAP sync happens when the query is created or updated, but also in an hourly cronjob (UpdateLdapGroupMembers).

LDAP/Rover Group Sync

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, these teams are 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)

But there are still some users managed manually in these Rover groups: