01
Client OIDC
customer-portal existe dans Keycloak avec le callback déclaré. Une modification du manifeste est réconciliée et vérifiable côté fournisseur.
HankoShell Operatorv1.0.1
Votre IAM.
Dans votre Git.
Déclarez l’identité et les accès de vos applications dans Kubernetes. L’opérateur maintient Keycloak en phase avec vos manifestes.
Apache-2.0 Helm OCI Linux AMD64 & ARM64
customer-portal.yamlKubernetes → Keycloak
apiVersion: hanko.sh/v1alpha1
kind: HankoApplication
metadata:
name: customer-portal
namespace: auth
spec:
realmRef: example
clientID: customer-portal
type: spa
redirectURIs:
- https://portal.example.com/callbackExemple pour un realm « example » déjà géré par l’opérateur.
Déclarez dans Git
Un changement relu en pull request.
Appliquez dans Kubernetes
L’opérateur réconcilie les objets gérés.
Vérifiez l’état
Les ressources exposent leur état de réconciliation.
De la déclaration au résultat
Un navigateur. Un vrai cluster.
Un cluster Kubernetes jetable, un Keycloak de test et les trois parcours ci-dessous. Le lab prépare l’environnement pour vous, sans installation locale.
Prévoyez environ 20 minutes, plus le téléchargement initial des images. Un compte Killercoda gratuit est nécessaire ; la session dure au maximum une heure.
Découvrir le lab interactifDans le terminal du lab
kubectl -n auth apply -f /root/lab/customer-portal.yaml
bash /root/lab/lab.sh check-oidc
bash /root/lab/lab.sh client customer-portalChaque étape compare la déclaration Kubernetes à l’état réel dans Keycloak. Killercoda supprime l’environnement à la fin de la session.
02
Adoption explicite
existing-portal passe de l’observation à la gestion après approbation du candidat exact, en conservant son UUID.
03
Identité machine
report-worker utilise le Secret créé par l’opérateur pour obtenir un véritable jeton client_credentials.
Le callback après réconciliation
Extrait de la réponse de l’API Keycloak après modification du manifeste dans le lab. Le client est Ready pour la génération courante et conserve son UUID.
{
"clientId": "customer-portal",
"publicClient": true,
"redirectUris": [
"https://portal.example.com/oidc/callback"
]
}Le lab utilise la version publiée 1.0.0 de l’opérateur et Keycloak 26.8.1. Il vérifie la configuration et l’authentification machine ; il ne déploie pas d’application web et ne qualifie pas la haute disponibilité.
- Git
- CI / GitOps
- Kubernetes
- HankoShell Operator
- Keycloak
Votre Keycloak existe déjà ?
Adopter un objet est une décision.
01
Observer
Inventoriez le périmètre pris en charge avec un compte Keycloak en lecture seule.
02
Examiner
Relisez l’identité de l’objet et le candidat d’adoption proposé.
03
Approuver
Un administrateur approuve ce candidat exact. L’acquisition ajoute les marqueurs de propriété.
04
Gérer
Passez explicitement en Manage pour réconcilier la configuration déclarée.
Un candidat modifié doit être réexaminé. Un objet détenu par un autre gestionnaire n’est pas repris silencieusement. La reprise reste limitée aux ressources et champs couverts par le contrat d’adoption.
Lire le parcours administrateurLe même workflow que votre application
L’IAM entre dans votre chaîne de livraison.
L’identité de vos applications
Realms, clients OIDC pour SPA, web et services : leur configuration accompagne celle de vos applications.
Des accès explicites
Rôles, composites, permissions d’API et affectations aux organisations se déclarent et se relisent dans Git.
Les identités machine aussi
Rotation des identifiants, fédération de workloads et livraison de Secrets aux destinations autorisées.
Un point de départ existant
Observez et importez les configurations prises en charge avant de décider explicitement de leur adoption.
Premiers pas
Votre cluster. Votre Keycloak.
Un chart Helm public. Aucun compte HankoShell requis. Commencez par la configuration et les permissions de votre installation.
Voir le chart sur Artifact Hub- 01 — Préparez operator-values.yaml
URL HTTPS Keycloak, Secret dédié, empreinte d’image et règles réseau : suivez le guide du chart autonome.
- 02 — Installez la version publiée 1.0.1
helm upgrade --install hankoshell-operator \ oci://ghcr.io/alien6-studio/charts/hankoshell-operator \ --version 1.0.1 \ --namespace auth --create-namespace \ --values operator-values.yaml --wait --timeout 5m - 03 — Déclarez une première application
Créez votre realm et votre client, puis consultez leur état : l’exemple complet.
API Kubernetes expérimentale : hanko.sh/v1alpha1. Vérifiez le périmètre et la migration des CRD avant toute mise à niveau.
Autonome, et connecté si vous le souhaitez
Une brique ouverte du plan de contrôle HankoShell.
L’opérateur applique la configuration dans votre cluster. La plateforme HankoShell ajoute le pilotage des organisations, des applications et des opérations à travers son Hub, son API et son dashboard. Adoptez l’opérateur seul ou intégrez-le à ce plan de contrôle.
Découvrir la plateformeFAQ
Questions fréquentes.
Faut-il la plateforme HankoShell ?
Non. L’opérateur fonctionne seul, sans Hub, API ou dashboard HankoShell. La plateforme ajoute une surface de pilotage et de gouvernance pour les équipes qui en ont besoin.
Remplace-t-il l’opérateur officiel Keycloak ?
Il peut travailler avec un Keycloak existant, y compris une instance gérée par l’opérateur officiel. Keycloak assure l’authentification ; HankoShell Operator réconcilie les objets IAM dont il est propriétaire. Un même objet doit avoir un seul gestionnaire.
Quelles versions sont prises en charge ?
La fenêtre de compatibilité décrit les versions qualifiées de Kubernetes et Keycloak, ainsi que les prérequis de chaque capacité. Consultez-la avant une installation ou une mise à niveau ; la prise en charge ne se limite pas à une liste figée de correctifs Keycloak.
La version 1.0.1 stabilise-t-elle les CRD ?
Les 17 ressources utilisent encore l’API expérimentale hanko.sh/v1alpha1. Upgrade, Clone et DBSwitch sont expérimentaux et désactivés par défaut. Le contrat d’API et la politique de migration documentent les limites de cette version.