Platform Authentication & Authorization

[soenkeliebau]

This is an initiative to track the work needed until we have an integrated authentication & authorization story for our platform.

This will be split into sub-epics to generate units of work that can be pulled onto the board and finished in a reasonable amount of time.

Authentication

Tasks

Beta Give feedback

1. Tracking: OIDC support #462
   9 of 18
   epic size/M +2
2. Initial Kerberos support #352
   5 of 5
   epic release/2024-03 +2
   

Authorization

The following diagram shows a high level view of the entire process, which should be helpful for dividing the work into separate projects that have value on their own.

• Decision Layer: This refers to the collection of RegoRules that we supply that handle the actual policy decision making in OPA.
• Abstraction Layer: This is built on top of the decision layer and should be an opinionated, simplified authorization model that should allow 90% of users to specify their authorization policies in a way that doesn't involve writing RegoRules. This might be implemented with CRDs like KafkaAcl, TrinoAcl, etc.. It should be based on a model like ReBAC, ABAC or RBAC.

Decision Layer

Tasks

Beta Give feedback

1. Policy decision layer: production-ready Rego policy definitions v1 #499
   18 of 23
   epic +1
   

The decision layer does the actual policy decisions. This still needs to be developed and is product specific.

Most of the work in the decision layer will happen in the operator repositories, as writing the generic RegoRules per product is part of the product specific implementation tickets (e.g. #500).

The groundwork for moving the data and rules into place should already be present in the OPA operator and the bundle builder.

Having these RegoRules in place is necessary for the abstraction layer (next step).

Abstraction Layer

Tasks

Beta Give feedback

1. Authorization abstraction layer #439
   0 of 2
   epic +1
   

Rego is not something that is really suitable to be exposed to the average user, so Stackable will define a suitable abstraction layer, probably per product that is the exposed to the users.
This abstraction will be implemented via CRDs, read by the product operators and converted into an internal format (configmaps, secrets, crds, tbd during refinement/implementation).
The initial step here will be to decide on some guiding principles and the overarching design in the form of an ADR (#439).
The actual design and implementation of the decisions from the ADR will then happen in the operator issues (e.g. stackabletech/trino-operator#479).

UserInfoFetcher

The current idea for the UserInfoFetcher is to develop it as part of the OPA Operator. The following diagram shows the current idea of how it could be deployed and interact with the rest of the system.

One thing currently missing, but shown as part of the decision layer is the UserInfoFetcher, which will need to be implemented.
This component is not named "UserGroupFetcher" or similar on purpose, as users may want to enrich user objects with arbitrary data, not just groups.
An example for such a use case would be this message from the Trino slack:

However I wanted to post a user story/use case we have. Need others opinions.

1. User is a US citizens and employee of a French company
2. User runs a query against a table that has (hypothetical) mix of US, Canada, Mexico, Korean, and various European customers
3. Since the user is a US citizen, if the customers is Korean there is a restriction on even accessing said information.
   4a) If the customers is European and said user is currently geographically inside the US, rows returned should NOT include the European user.
   4a) If the customers is European and said user is currently at the French office, then rows returned can include the European customers.
4. If the customers is Canadian, the data may be viewed but there is a reporting requirement for said data (reporting handled via Telemetry not OPA)
5. If the customer is from Mexico or US, said User is entitled to see all rows
6. The row filters (and/or masking) applied should be based on said geopolitical rules

So the general idea is to allow defining arbitrary properties that user principals should be enriched with, if they are available in the backend. This will have to be backend specific, as for example Keycloak and AD have different concepts around group membership, usernames and custom properties.

Group based authorization

Beta Give feedback

1. First release of userinfo fecher tool (with Keycloak backend) opa-operator#477
   12 of 23
   customer-request epic release/2024-03 +3
   
2. Implement user group mapper for LDAP
3. Other mappers according to ADR

Products

In the products themselves authorizer implementations that use OPA as backend will need to be provided.
This will need to be investigated per product, with a few already being taken care of:

• In Trino this is currently being contributed upstream: Add support for Open Policy Agent trinodb/trino#17940
• For Druid we have an authorizer
• For Kafka we have an authorizer

For the rest of the tools we'll need individual tickets in the operators (e.g. stackabletech/hdfs-operator#400).
In some cases it might not make sense, we'll need to determine this per product (e.g. #120 (comment)).

In some cases, on top of the authorizer a group mapper might be needed, as some products actually have a concept of user groups and use these internally (HDFS being a prominent example).
The idea here is to implement a simple group mapper for the product in question that calls out to OPA to retrieve the groups for that user via a rest call, so that the actual functionality remains in the UserInfoFetcher and is not spread throughout the entire plattform (stackabletech/hdfs-operator#401).

HDFS

Beta Give feedback

1. Implement Authorizer hdfs-operator#400
   5 of 5
   changelog/crd-change changelog/highlight release/2024-03 +3
   
2. Implement Group Mapper hdfs-operator#401
   5 of 5
   release/2024-03 +1
   
3. Define and implement abstraction layer according to guidelines set out in ADR

HBase

Beta Give feedback

1. Implement OPA compatible authorizer hbase-operator#488
   refinement-needed +1
   
2. Define rego rules for HBase

Trino

Beta Give feedback

1. Add support for Open Policy Agent trinodb/trino#19532
   cla-signed +1
2. Define and implement abstraction layer according to guidelines set out in ADR trino-operator#479
   +0
3. Trino Authentication V1 trino-operator#26
   epic +1
4. Implement Rego rule file for abstraction layer
5. Implement abstraction layer in CRDs
6. Documentation: Document all possible Rego resources trino-operator#295
   +0

Druid

Beta Give feedback

1. OpenID Connect support druid-operator#473
   customer-request +1
   
2. Authorization withouth an authenticator - how does it work? druid-operator#368
   +0
3. Define abstraction layer according to guidelines set out in ADR
4. Implement Rego rule file for abstraction layer
5. Implement abstraction layer in CRDs
6. Interconnection LDAP auth with an OPA authorization druid-operator#384
   0 of 1
   priority/high type/feature-new +2

NiFi

Beta Give feedback

1. Spike: Add a NiFi Authorizer that interfaces with OPA #47
   +0

Miscelaneous Tickets

Things related to the initiative but not to any particular epic

Tasks

Beta Give feedback

1. Decision logging currently disabled opa-operator#422
   2 of 2
   changelog/highlight customer-request +2
   
2. Rego rules are not deleted when the CM is deleted opa-operator#505
   size/S type/bug +2
   
3. Make OPA telemetry opt-in opa-operator#489
   size/S +1
   
4. bundle builder: How can the bundle builder access the ConfigMaps if API access requires authentication? opa-operator#514
   +0
5. Airflow Authorization airflow-operator#446
   +0

[fhennig]

This is very broadly also related: #124

Since this ticket is an initiative now, maybe we can have another tasklist with "Ideas/Nice to Have" or something where tickets like the one above can go?