First release of userinfo fecher tool (with Keycloak backend)

[soenkeliebau]

Description

The Stackable Data Plattform should integrate with identity providers to allow authorizing access based on arbitrary user attributes from those providers. The most common attributes will probably be groups and roles a user has, but other use cases are certain to come up, so this should be able to retrieve user configurable attributes as well.

Development

The current idea is to develop the userinfofetcher as a module in the opa operator https://github.com/stackabletech/opa-operator, to avoid additional build complexity by spinning this out into a project of its own.
If need be, it can still be moved out of the repo at a later date.

PoC code for this functionality is available in this branch: https://github.com/stackabletech/opa-operator/tree/spike/user-info-fetcher

Functionality

For an initial release the following items must be achieved:

Must Have

Preview Give feedback

1. User Info fetcher: Improve http request error output #509
   +0
   
2. Investigate customer issue
3. Write ADR on CRD changes for UserInfoFetcher #478
   +0
   
4. Discussion about what else is needed for release in 24.3
5. Functionality to retrieve user attributes from Keycloak
6. Cache requests for users information with configurable cache eviction time
7. UserInfoFetcher has to be configurable via CRD (can be the opa crd if that makes sense)
8. Retrieving arbitrary user properties has to be implemented
9. Design has to be modular, so that other backend than Keycloak can be added at a later time
10. The fetcher gets asked: "Which groups is the user sub (random stable identifier in KeyclaoK) part of?"
11. The fetcher also can be asked: "Which groups is the username part of?"
12. Documentation - usage guide
13. User Info Fetcher: Enable TLS with WebPKI trust by default #517
    +0

ADR

Some issues to be covered in the ADR:

• Caching
• Centralized component to minimize components that talk to AD/etc.

CRD Design

Configuration of the userinfofetcher will be done inside of the existing Opa crd.

Option 1

---
apiVersion: opa.stackable.tech/v1alpha1
kind: OpaCluster
metadata:
  name: simple-opa
spec:
  clusterConfig:
    userInfoProvider:
      keycloak:
         url: http://iaeiaeiea:5678 # maybe pull this out into a configmap?
         credentialsSecret:
         tls: TlsConfig
         cache:
            maxEntries: ...  # all the cache settings are to be understood as placeholders
            ttl: ...
            evictionStrategy: ..
         extraAttributes:
            stackableField1: remoteField1
  image:
    productVersion: "0.51.0"
    stackableVersion: "23.7.0"
  servers:
    roleGroups:
      default:
        selector:
          matchLabels:
            kubernetes.io/os: linux

Option 2

@sbernauer : have some decouplign and say its too complicated

Deployment

Currently the proposed deployment is for the UserInfoFetcher to run as a sidecar container in the opa pods. This would allow the userinfofetcher to only listen on the loopback interface and not be available from outside of the pod.
For this reason it should be possible to not run tls for the userinfofetcher, as the pod would need to be breached to compromise it - and at that point in time an attacker would have access to the certificate and key that can be used to authenticate as well.

For the first iteration it is agreed to go with the deployment model shown in the diagram above.

At later stages we may want to look into adding a central userinfofetcher as caching layer to avoid ddos-ing identity providers.

Definition of Done Checklist

• Not all of these items are applicable to all PRs, the author should update this template to only leave the boxes in that are relevant
• Please make sure all these things are done and tick the boxes

Author

Preview Give feedback

1. Changes are OpenShift compatible
2. Helm chart can be installed and deployed operator works
3. Integration tests passed (for non trivial changes)

Reviewer

Preview Give feedback

1. Code contains useful comments
2. (Integration-)Test cases added
3. Documentation added or updated
4. Changelog updated
5. Cargo.toml only contains references to git tags (not specific commits or branches)

Acceptance

Preview Give feedback

1. Feature Tracker has been updated
2. Proper release label has been added

[lfrancke]

Reopening for #517

[sbernauer]

I think I personally would make a new Issue to change the common tls struct to default to webPki (or similar) across all CRDs. But I leave it to you ;)

[lfrancke]

That is to be refined.
If you're interested let us know
https://stackable-workspace.slack.com/archives/C06GWEEG602/p1707484224033069

[sbernauer]

I'm happy to let others refine, just tried to prevent this from some form of feature creeping 😅

[lfrancke]

Closing again, we have the default TLS in a separate ticket now.