Repository navigation
Replies: 1 comment 15 replies
|
@shawkins Does this capture all we've talked about? |
That would break the new authenticator. We could somehow limit pod templates in the cluster-wide mode. |
I thought that only needed access to the mounted certs, not the api server. |
|
If I understand correctly, it needs to load the keys from the API to verify the provided service account token: |
Ah that's no good then. So if we blocked direct access to the api server, there would need to be something like a load balancer in front of the api server with reencrypt that would block any paths outside of what is needed for openid. |
|
The result of our off-line discussion was that we would inhibit setting the service account via the pod template (similar to how we prevent the image from being set). This should be something that we can do selectively cluster wide mode, if not then we'll do #28728 first. |
Uh oh!
There was an error while loading. Please reload this page.
The problem
Currently, we support installing the Operator only in the namespaced mode, i.e. to deploy Keycloak in a namespace, an Operator instance needs to live in the same namespace. This is problematic for a couple of reasons:
The solution: Cluster-wide Operator
With cluster-wide Operator, there can be a single Operator instance for the whole cluster, managing all Keycloak instances in all namespaces.
Considerations
Proposed plan
Milestone 1: basic MVP, supporting a single Keycloak version
To resolve majority of the issues and satisfy the demand from users for the cluster-wide Operator as quickly as possible, we'd expose the cluster-wide mode and document it. It is already implemented and handled by JOSDK but it is hidden in the Keycloak Operator.
The caveat here would be everything mentioned above in "Considerations". Those would need to be explicitly documented. The most prominent limitation would be the 1:1 version mapping of the Operator and Keycloak. Hence, the feature would be marked just as a Preview.
Estimated effort: low. We're just exposing already implemented functionality. What is missing is some basic tests, and docs.
Milestone 2: supporting Keycloak version range
As the next step, a single Operator version would support all Keycloak versions for the same major release. E.g. Operator version 27.3 would support Keycloaks 27.0, ..., 27.3, 27.4, ... 27.8, etc.
This would require the Operator to check the Keycloak version, or possibly better: the enabled features versions. This would cover the scenarios when newer Operator is used with older Keycloak – the Operator would disable some of its features that require features enabled at the Keycloak side. Version awareness would also help with the "rolling updates" consideration – Operator would keep the original fields on the deployment based on the Keycloak version, not Operator version.
Forward compatibility (older Operator, newer Keycloak) is ensured implicitly – we don't introduce breaking changes to Keycloak in minor releases.
Estimated effort: high. We'd need to introduce a mechanism for fetching versioning metadata from Keycloak. Additionally, if features were considered as well, we might need to wait for the future refinement of our features story.
Related
All reactions