In recent times the Keycloak Operator for OpenShift has moved from the old EAP based implementation to a new implementation based on Quarkus. At the same time the Custom Resource Definition for a Keycloak object has moved from apiVersion v1alpha1 to v2alpha1.

While on average this is a good move, and it brings many improvements, some functionality appears to have not made the transition yet, most notably the ability to easily add custom extensions and providers.

Since one of our customers encountered this and asked for our help we went and sought a solution to this, without having to resort to building custom images, as those would add an extra maintenance burden on an already busy team.

Er is veel veranderd door de komst van containers en de container platformen. We kunnen het platform in zijn geheel als een nieuwe computer beschouwen, met Kubernetes als operating system. Net als ieder operating system, is er hier ook een API. Dus waarom gebruiken wij dit niet in onze applicaties?

Je kent het wel, voordat je namespace, of OpenShift project, helemaal klaar is voor gebruik heb je een kleine waslijst van acties die je met de hand moet uitvoeren. Misschien is er een bepaalde deployment die je in elke namespace standaard wil draaien, misschien zijn er service accounts die je nodig hebt, of moet er een specifieke token toegevoegd worden. Het zijn in ieder geval handelingen die je niet met de hand zou willen uitvoeren. Hoe kun je dit nu eenvoudig automatiseren? Lees in dit blog hoe je een operator voor je kan laten werken.