Narrative

RH-SSO Operator supported limited management of Realms, Clients and Users. While the RHBK Operator offers RealmImport CR for limited Realm management, it currently lacks any means to manage Clients and Users. Users management is currently out of scope of the RHBK Operator as RHBK itself offers a different means considered best practices to do this via e.g. user federation or identity providers.
 

Value Proposition

Customers will be able to manage RHBK Clients in a cloud-native way through Kubernetes CRs, similarly to what they're used to from our competing products, e.g. Dex.
 

Acceptance Criteria

• Ability to create, update and delete managed clients through a Keycloak Client CR
  • Supporting all fields in a new Client Representation that are derived from the existing ClientRepresentation
    • As a result, in the first iteration of the Client CR the management capabilities in terms of number of available fields will be limited.
  • Updates to the Keycloak Client CR should be reflected in the client within Keycloak
  • Deleting the Keycloak Client CR should result in the client being deleted within Keycloak
  • The Keycloak Client CR must be in the same namespace as the Keycloak CR, and supporting creating Keycloak Client CRs in different namespaces is not in scope of this issue

• The Operator should use a dedicated service account when creating and updating clients
  • It should be possible to limit what the Operator is permitted to do through managing roles for the service account
  • It should be possible to limit what the Operator is permitted to do through fine-grained admin permissions
  • It should be possible to limit what the Operator is permitted to do through client policies
  • The service account should be automatically created by the Operator with limited permissions; it should only have access to create new clients, and manage clients itself have created

• No secrets should be added in plain-text to the Keycloak Client CR

• There should be a generic re-usable syncing mechanism for clients; allowing re-use to other means of managing clients in the future (for example a filesystem, Ansible, Terraform, etc.)
  • This generic syncing mechanism should be a foundation for supporting other entities in the future (realm config, identity providers, client scopes, etc.)
  • The Operator part should be a thin layer to wire-in the generic syncing mechanism