fhennig
commented
10 months ago This is very broadly also related: https://github.com/stackabletech/issues/issues/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?
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
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
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. https://github.com/stackabletech/issues/issues/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
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 (https://github.com/stackabletech/issues/issues/439). The actual design and implementation of the decisions from the ADR will then happen in the operator issues (e.g. https://github.com/stackabletech/trino-operator/issues/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: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.
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:
For the rest of the tools we'll need individual tickets in the operators (e.g. https://github.com/stackabletech/hdfs-operator/issues/400). In some cases it might not make sense, we'll need to determine this per product (e.g. https://github.com/stackabletech/issues/issues/120#issuecomment-1044696630).
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 (https://github.com/stackabletech/hdfs-operator/issues/401).
Miscelaneous Tickets
Things related to the initiative but not to any particular epic