keycloak-community
keycloak-community copied to clipboard
keycloak
KEYCLOAK-10319 Long-term Keycloak Operator architecture
This Pull Request contains a High Level Architecture overview of Keycloak Operator and its long-term vision.
Better preview is available here: https://github.com/slaskawi/keycloak-community/blob/Operator-high-level-architecture/design/operator-architecture.asciidoc
Why .asciidoc when all other designs are in markdown? Would be good to just keep it all in one format
Why .asciidoc when all other designs are in markdown? Would be good to just keep it all in one format
@stianst I wanted to use a block with a feature implementation example. This functionality is not available in Markdown. To me, Asciidoc formats documents much better and we also use it in other projects, such as Keycloak Web and Keycloak Documentation.
I'd rather keep things consistent here. If you want to propose changing the format that's fine, but otherwise stick to what is already done. Consistency matters.
Personas and use-cases - describe related personas and use-cases for the personas
@stianst Added usecases
More details on being opinionated and providing a high-level usability, rather than low-level toggles
@stianst added "a way to deliver a high level usability rather than low-level toggles" to the manifesto.
How we will avoid feature creep - I can easily see lots of request for small things to be added, which in the end results in a complicated beast rather than a simple to use opinionated
@stianst To me, this sounds exactly the (although in different words) than the previous point.
Avoiding logic in the operator - a bit more expanding on the section on where features should be implemented to describe that advanced logic doesn't belong in the operator
@stianst Added "the thinnest possible layer, with the least possible logic, on top of Keycloak Container and Keycloak Server." to the manifesto.
Section capability levels and how we plan to properly address them
@stianst I can add you a dedicated section, but let me push the use cases first. Maybe that will be enough for you.
@davidffrench @stianst @mposolda Thank you gentlemen for the review. I addressed your comments and pushed a new version.
@slaskawi Does make sense to list the CRDs used by the Operator? I found one quick reference to the Keycloak CRD but not others currently supported by the operator.
Considering they play an important role, maybe a specific section about CRDs could make this part of the architecture more clear. Especially if provided:
-
Their lifecycle. For instance, those implicitly managed by the operator such as the
KeycloakCRD and the others representing the state that map to entities in Keycloak such asUser,RealmClient, etc. -
Limitations and Use-Cases. Is it feasible to manage 100 realms + 1000 users + 100 clients using the operator. Considering Openshift, how that would work when the user is managing the cluster through the Openshift Console ? Is the operator going to support all the configuration we have in Keycloak for these entities?
-
Reconciliation. How reconciliation works in regards to CRDs. What happens when updating a CRD or the corresponding entity in Keycloak? Would the operator keep both sides in sync all the time ?
-
Relationship between CRDs. How the operator knows that a
User JownCRD is mapped to aRealm My RealmCRD?
Does make sense to list the CRDs used by the Operator? I found one quick reference to the Keycloak CRD but not others currently supported by the operator.
@pedroigor This is coming in updated documentation, see https://github.com/keycloak/keycloak-documentation/pull/796
Their lifecycle. For instance, those implicitly managed by the operator such as the Keycloak CRD and the others representing the state that map to entities in Keycloak such as User, Realm Client, etc.
@pedroigor I don't want to be too specific about those CRs in this architecture vision as I see them as an implementation detail. However, this is the second time I see someone asking for a list of CRs, so let me add it.
Limitations and Use-Cases. Is it feasible to manage 100 realms + 1000 users + 100 clients using the operator. Considering Openshift, how that would work when the user is managing the cluster through the Openshift Console ? Is the operator going to support all the configuration we have in Keycloak for these entities?
@pedroigor I see those are Keycloak limitations (not necessarily the Operator). Perhaps we should have a Keycloak long term vision somewhere and put this there? What do you think, @stianst ?
Reconciliation. How reconciliation works in regards to CRDs. What happens when updating a CRD or the corresponding entity in Keycloak? Would the operator keep both sides in sync all the time ?
@pedroigor I believe this has been covered in Operator SDK manual, so repeating it here doesn't make much sense (to me).
Relationship between CRDs. How the operator knows that a User Jown CRD is mapped to a Realm My Realm CRD?
@pedroigor That's a good point. Let me mention here the way it has been implemented.
Please change format to markdown to make this consistent with everything else.
@slaskawi hey there, I'm working on a project where I'm considering using the keycloak operator as a component. In my use case, I think it would be useful to be able to add and update Identity/User Storage Providers via CRDs. Just wondering, would something like that be out of the scope of this project? I mainly just want a way to easily add additional authentication pieces, each bundled with its relevant keycloak configuration, to a big sso system in k8s. And extending this operator to handle those type of CRDs is one idea I had, and doesn't seem terribly hard for me to do, but that could be overkill. Thanks and great job!
