Pepr management of groups and roles?

[bburky]

Configuration of Keycloak groups and roles may be app-specific. Much like configuring the Keycloak client already is, but that's handled well by the Package CR and uds-core Pepr operator.

Often groups "standard user", "limited admin" and "super admin" can be created that are broad enough to capture use cases for many apps. But if a cluster admin wants to practice least privilege and create a specific "app-foo admin" role, this is app specific. Similarly, Keycloak client roles are always app specific, and cannot be configured at all until after the client is created.

In some projects, there may be separate teams (maybe even gov or other contractors) integrating each app, with Defense Unicorns performing configuration of uds-core and lower level configuration (OS, etc).

The mostly-well-supported solution today seems to be the Keycloak Tofu provider for this use case. However, the obvious approach to implementation would have the definition of all groups and roles in a shared git repository. This introduces friction between teams, other teams must modify a second repo to add their app-specific groups. The CI system must be careful to execute Tofu after all apps have deployed if it is configuring client roles. To support developers modifying both repositories at once (app and tofu), CI must support temporarily overriding the version to the not-yet-merged update of the Tofu config.

An alternate Tofu proof of concept I implemented, puts a keycloak-tofu.$CLIENT_ID ConfigMap in each namespace allowing apps to provision groups, client roles and association of client roles to groups, all self service. However, this is very non-standard looking Tofu code and its design is far closer to what a k8s operator would usually do, with a CR.

(The code is a bit insane and still a proof of concept, you are warned: https://gist.github.com/bburky/4a5de3927063ce10e7b470b834c16550)

With any Tofu approach, cluster administrators must ensure that Tofu is re-run anytime app configuration changes if it needs new groups.

This issue is mostly to ask "is there any desire to implement management of groups, realm roles, client roles, and association of groups to roles in Pepr itself?"