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).

Implementation ideas:

• The operator deploys a "rego library" that matches the product version. This is what we developed in the decision layer.
• The operator can read ACL CRDs and then creates json data that can be read by the RegoRules.

The basic idea shown in the diagram above is, that users write TrinoAcl/KafkaAcl/... CRDs, which the operators transform into configmaps or secrets, which in turn the bundle-builder makes available to Opa as external data to be used in the rego rules.

The snippet below shows an example of how this might look like in the config, this would retrieve the field remoteFieldName1 from keycloak or ldap and make it available in the rego rules as stackableFieldName1 hence allowing us to normalize to a certain extent if needed.

---
kind: UserInfoFetcherConfig
spec:
  backend:
    keycloak:
      config: ...
       # keycloak has a defined way of thinking about username and group infromation
          no need to have them configurable here
       extraInformation:
             stackableFieldName1: remoteFieldName1
             stackableFieldName2: remoteFieldName2
    ldap: 
       config: ...
       identityFieldName: upn
       groupFieldName: groups
       extraInformation:
             stackableFieldName1: remoteFieldName1
             stackableFieldName2: remoteFieldName2 
   static: 
   # for demos and simple use cases we should support our static group concept as well
      config: ...

Referring to these custom properties in ACLs might then look like this:

---
kind: TrinoAcl
spec:
  who: 
    identity: sonke
    group: admin
     custom:
           stackableFieldName1: suit
  operation: write
  object:
    table:
      - customers
      - nexttable

Research

I remembered reading about Google Zanzibar a while ago and went looking at it again in case we could borrow some concepts for our plattform there.
These are a few links to read up on:

• https://authzed.com/zanzibar
• https://authzed.com/blog/what-is-google-zanzibar
• https://gruchalski.com/posts/2022-05-07-zanzibar-style-acls-with-opa-rego/
• https://www.permit.io/blog/oparebac
• https://www.permit.io/blog/policy-engines

### Tasks
- [ ] https://github.com/stackabletech/documentation/pull/531
- [ ] more tasks to be refined