Having your Keycloak managed by an operator is a cool thing, for sure 😀
Yet, its usage is hardly bound to a very important factor, it being the managed Keycloak instance is only managed by a single owner.
In that case, resource management conflicts should not occur, allowing the operator to follow the Kubernetes reconciliation spec nicely.
As of that, the operator takes full control over its managed resources (instance, realm, you name it).
In the real world, especially in a highly constrained environment with KRITIS or NIST requirements, it is very likely that the targeted Keycloak instance cannot follow that ownership pattern.
Imagine you wanna deploy your workload on an managed environment, where Keycloak is provided as a service. The infrastructure teams that are responsible for pre-configuring things for you, will never allow access to various things of the managed instance due to security and compliance constraints.
Better by example:
- infrastructure team will want to pre-configure realm settings
- infrastructure team will want to pre-configure issuer uris, other redirect uris
- infrastructure team will want to pre-configure SSO, federation- or synchronisation providers
- and so on...
Why - you should not need know about such things, no need to over-expose e.g. an LDAP URL to app teams. At least that is often the argumentation.
In that case the targeted Keycloak realm will become the shared resource adapter between infrastructure provider and the other team, both holding there stakes on the Keycloak realm:
- infrastructure team will want to keep the realm as secure, not exposing e.g. URLs, secrets etc.
- infrastructure team will want to not have the realm config changed (without approval)
and opposing to that:
- the team using the platform infrastructure will want to take full leverage of the operator for automation reasons
This creates a classical resource ownership management conflict, that to my current knowledge is not solved by any other Keycloak operator.
The reason is obvious, its going to be a bit of a challenge.
As discussed with @MariusSchmidt, I am opening this feature request, to brainstorm potential solutions, so that they could potentially be incorporated into rustcloak.
Taking the nature of the problem, this would for sure build and competitive advantage of the rustcloak-operator.
Having your Keycloak managed by an operator is a cool thing, for sure 😀
Yet, its usage is hardly bound to a very important factor, it being the managed Keycloak instance is only managed by a single owner.
In that case, resource management conflicts should not occur, allowing the operator to follow the Kubernetes reconciliation spec nicely.
As of that, the operator takes full control over its managed resources (instance, realm, you name it).
In the real world, especially in a highly constrained environment with KRITIS or NIST requirements, it is very likely that the targeted Keycloak instance cannot follow that ownership pattern.
Imagine you wanna deploy your workload on an managed environment, where Keycloak is provided as a service. The infrastructure teams that are responsible for pre-configuring things for you, will never allow access to various things of the managed instance due to security and compliance constraints.
Better by example:
Why - you should not need know about such things, no need to over-expose e.g. an LDAP URL to app teams. At least that is often the argumentation.
In that case the targeted Keycloak realm will become the shared resource adapter between infrastructure provider and the other team, both holding there stakes on the Keycloak realm:
and opposing to that:
This creates a classical resource ownership management conflict, that to my current knowledge is not solved by any other Keycloak operator.
The reason is obvious, its going to be a bit of a challenge.
As discussed with @MariusSchmidt, I am opening this feature request, to brainstorm potential solutions, so that they could potentially be incorporated into rustcloak.
Taking the nature of the problem, this would for sure build and competitive advantage of the
rustcloak-operator.