Authentification OIDC avec Keycloak pour Kubernetes

La gestion des accès aux clusters Kubernetes représente un défi récurrent pour les équipes de développement. Le partage de fichiers kubeconfig avec des privilèges inadaptés (trop larges ou trop restrictifs) génère des risques de sécurité et des difficultés opérationnelles.

Ce guide présente l'implémentation du protocole OpenID Connect (OIDC) avec Keycloak pour centraliser l'authentification des utilisateurs sur un cluster Kubernetes. Cette approche permet de :

• Utiliser un fichier kubeconfig unique partageable entre tous les utilisateurs
• Hériter automatiquement des droits RBAC basés sur les groupes Keycloak
• Centraliser la gestion des identités et des accès
• Révoquer instantanément les droits sans redistribuer de fichiers
• Tracer précisément les actions par utilisateur

Prérequis

Avant de débuter, assurez-vous de disposer de :

• Une instance Keycloak accessible pour vos utilisateurs avec accès administrateur
• Un cluster Kubernetes chez SdV avec le kubeconfig administrateur
• kubectl installé localement sur votre poste (version compatible avec le cluster)
• Droits suffisants pour créer des ressources RBAC dans le cluster

Architecture et flux d'authentification

Schéma du flux OIDC

Voici le déroulement complet d'une authentification OIDC avec Kubernetes :

Composants de l'architecture

Sécurité du flux

Le flux utilise plusieurs mécanismes de sécurité :

• PKCE (Proof Key for Code Exchange) : Protection contre l'interception du code d'autorisation
• State parameter : Protection contre les attaques CSRF
• Signature JWT : Garantie de l'intégrité et de l'authenticité du token (RS256/ES256)
• HTTPS obligatoire : Chiffrement de tous les échanges avec Keycloak
• Token courte durée : Limitation de la fenêtre d'exploitation en cas de compromission
• Redirect URI restreinte : Seul localhost:8000 est autorisé (pas de redirection externe)

Paramétrage de Keycloak

Création du client Keycloak

La première étape pour nous va être de déclarer une nouvelle application Keycloak dans votre realm.
C'est grâce à celle-ci que nous serons en mesure de configurer l'OIDC sur votre cluster Kubernetes.

Rendez-vous dans le panneau d'administration de votre instance Keycloak et identifiez-vous avec un compte administrateur.

Sélectionnez le realm avec lequel vous souhaitez faire le lien avec votre cluster Kubernetes. Dans notre cas, ce sera kubernetes.

Dans le menu de gauche, cliquez sur Configure > Clients. Cliquez sur le bouton Create en haut à droite de la liste des clients existants.
Vous voyez apparaître le formulaire suivant.

Remplissez le formulaire de création de client avec les informations suivantes :

Cliquez sur Save, vous êtes redirigé vers la page d'édition du client Keycloak que vous venez de créer.

Sur cette page, modifiez les éléments suivants :

Une fois ces paramètres changés, un nouvel onglet Credentials apparaît dans la console Keycloak. Cliquez dessus.

Vous aurez besoin de ces informations pour les dernières étapes de configuration :

• Client ID (selon le nommage réalisé lors de la création du client)
• Client Secret (depuis l'onglet Credentials)

Création du mapping de groupes

Par défaut, lorsque l'utilisateur validera son authentification au travers du client que vous venez de créer, les informations sur les groupes auxquels l'utilisateur appartient ne remontent pas dans le token JWT renvoyé à kubectl. Nous devons activer cela en faisant un mapping de groupes.

Rendez-vous sur l'onglet Mappers, puis cliquez sur le bouton Create en haut à droite de la liste des mappings déjà existants (qui devrait être vide à ce stade).

Sur cette page, ajoutez les informations comme sur la capture :

Validez en cliquant sur Save.

Activer l'OIDC sur votre Cluster

Contactez l'équipe Système de SdV et demandez l'activation de l'OIDC sur votre cluster Kubernetes.

Les élements de configuration à communiquer sont les suivants :

Lorsqu'un utilisateur se voit identifié dans Keycloak, Kubernetes va vérifier ses droits dans les RBAC du cluster. L'identifiant de l'utilisateur sera oidcuser:XXXX-XXXX-XXXX-XXXX pour un utilisateur et oidcgroup:YYYY-YYYY-YYYY-YYYY pour un groupe. Cela permet d'utiliser ces notations pour la création des ClusterRoleBindings et RoleBindings.

Création du fichier kubeconfig générique

Le fichier kubeconfig suivant utilise le mécanisme exec pour déléguer l'authentification au plugin kubelogin. Ce fichier peut être partagé avec tous les utilisateurs sans compromettre la sécurité.

apiVersion: v1
kind: Config
preferences: {}
 
# Définition du cluster Kubernetes
clusters:
- cluster:
    # URL de l'API Server Kubernetes (fournie par SdV)
    server: [CLUSTER-API-ENDPOINT]
    # Certificat racine du cluster (fourni par SdV)
    certificate-authority-data: [CLUSTER-CA-CRT]
  name: kubernetes-oidc
 
# Définition des utilisateurs (authentification déléguée à OIDC)
users:
- name: oidc-user
  user:
    exec:
      # Version de l'API d'authentification client
      apiVersion: client.authentication.k8s.io/v1beta1
      # Commande kubectl (qui délègue à kubelogin via plugin)
      command: kubectl
      # Arguments passés au plugin kubelogin
      args:
      - oidc-login
      - get-token
      - --oidc-issuer-url=https://[KEYCLOAK-URL]/auth/realms/[KEYCLOAK-REALM]
      - --oidc-client-id=[KEYCLOAK-CLIENT-ID]
      - --oidc-client-secret=[KEYCLOAK-CLIENT-SECRET]
      - --oidc-extra-scope=email
      - --grant-type=authcode
      env: null
 
# Définition des contextes (association cluster + utilisateur + namespace par défaut)
contexts:
- context:
    cluster: kubernetes-oidc
    user: oidc-user
    namespace: default  # Namespace par défaut (modifiable selon vos besoins)
  name: oidc-context
 
# Contexte actif par défaut
current-context: oidc-context

Remplacez les valeurs entourées de crochets dans le yaml ci-dessus, selon le tableau suivant :

Valider le fonctionnement du kubeconfig

Maintenant que vous disposez d'un fichier kubeconfig, il faut valider le bon fonctionnement lors de son utilisation.

En premier lieu, nous créerons un utilisateur Keycloak, ensuite nous créerons un groupe, ainsi que les droits associés dans le cluster Kubernetes au travers des RBAC.

Création des utilisateurs

Connectez-vous à la console d'administration de votre instance Keycloak et sélectionnez le realm adéquat. Dans le menu de gauche, rendez-vous dans Manage > Users puis cliquez sur le bouton Add user en haut à droite de la liste des utilisateurs (vide par défaut).

Remplissez le formulaire en veillant bien à ce que :

• User Enabled soit à On
• Email Verified soit à On

Validez la création en cliquant sur Save. Vous êtes redirigé sur le formulaire de gestion de l'utilisateur nouvellement créé.

Cliquez sur l'onglet Credentials, et définissez un mot de passe pour l'utilisateur en remplissant les champs Password et Password Confirmation. Décochez Temporary pour ne pas forcer la redéfinition du mot de passe de l'utilisateur à sa première connexion. Validez en cliquant sur Set Password.

Répétez l'opération pour disposer d'un second utilisateur. Pour notre guide, nous avons créé :

• oidc-admin-user qui sera associé aux droits d'administration sur le cluster Kubernetes
• oidc-regular-user qui n'aura de droits que dans l'un des Namespaces du cluster Kubernetes

Création des groupes

Nous disposons des utilisateurs, nous allons désormais créer les groupes et les y associer.

Rendez-vous dans la console d'administration Keycloak, dans le menu de gauche, cliquez sur Manage > Groups puis cliquez sur le bouton New en haut à droite de la liste des groupes.

Dans le formulaire qui suit, vous n'avez qu'à saisir le nom du groupe souhaité.

Nous créons deux groupes, l'un pour les administrateurs du cluster, l'autre pour les utilisateurs verrouillés dans un Namespace :

• ClusterAdmins
• DefaultNamespace

Nous devons désormais associer nos utilisateurs à chaque groupe.

Rendez-vous dans la console d'administration Keycloak, dans le menu de gauche, cliquez sur Manage > Users.

Dans la liste des utilisateurs, sélectionnez oidc-admin-user, puis rendez-vous dans l'onglet Groups.

Sélectionnez le groupe ClusterAdmins et cliquez sur le bouton Join. Le groupe apparaît désormais dans la liste Group Membership.

Retournez sur la liste des utilisateurs via Manage > Users, et répétez l'opération pour associer oidc-regular-user au groupe DefaultNamespace.

Création des RBAC

Au niveau du cluster Kubernetes, l'authentification se fera au travers du groupe auquel l'utilisateur identifié est associé.

Pour se faire, nous aurons besoin de créer des ClusterRoleBinding et des ClusterRole.

Groupe des Administrateurs de Cluster

Kubernetes embarque nativement déjà un ClusterRole nommé cluster-admin qui donne les droits complets sur le cluster.

Nous n'avons donc qu'à créer un ClusterRoleBinding pour associer le groupe ClusterAdmins à cluster-admin.

Créez un fichier comme qui suit :

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: oidc-cluster-admins
  labels:
    app.kubernetes.io/component: rbac
    app.kubernetes.io/managed-by: kubectl
    app.kubernetes.io/part-of: oidc-auth
roleRef:
  # Référence au ClusterRole natif cluster-admin (droits complets)
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: cluster-admin
subjects:
- apiGroup: rbac.authorization.k8s.io
  kind: Group
  # Groupe Keycloak préfixé selon configuration OIDC
  name: oidcgroup:ClusterAdmins

Appliquez cette configuration à votre cluster en utilisant le fichier kubeconfig fourni par SdV (avec droits admin) :

kubectl apply -f oidc-cluster-admins.yml
# Output:
# clusterrolebinding.rbac.authorization.k8s.io/oidc-cluster-admins created
 
# Vérification
kubectl get clusterrolebinding oidc-cluster-admins -o yaml

Groupe des utilisateurs verrouillés

Pour notre exemple, nous allons verrouiller nos utilisateurs appartenant au groupe DefaultNamespace dans le Namespace default. Pour pouvoir faire cela, nous aurons à créer un Role ainsi qu'un RoleBinding.

A la différence du ClusterRoleBinding créé pour le groupe d'administration, le RoleBinding est namespacée dans l'espace de nom où l'utilisateur est verrouillé.

Créez les fichiers comme qui suit :

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: oidc-default-namespace-clusterrole
  labels:
    app.kubernetes.io/component: rbac
    app.kubernetes.io/managed-by: kubectl
    app.kubernetes.io/part-of: oidc-auth
rules:
# Permissions complètes sur toutes les ressources
# (dans le cadre d'un RoleBinding, limité au namespace ciblé)
- apiGroups:
  - '*'  # Tous les API groups
  resources:
  - '*'  # Toutes les ressources
  verbs:
  - '*'  # Toutes les actions (get, list, create, update, delete, etc.)

Appliquez ces RBAC dans votre cluster Kubernetes (avec le kubeconfig admin SdV) :

# Application du ClusterRole
kubectl apply -f oidc-default-namespace-clusterrole.yml
# Output:
# clusterrole.rbac.authorization.k8s.io/oidc-default-namespace-clusterrole created
 
# Application du RoleBinding dans le namespace default
kubectl apply -f oidc-default-namespace.yml
# Output:
# rolebinding.rbac.authorization.k8s.io/oidc-default-namespace created
 
# Vérification
kubectl get clusterrole oidc-default-namespace-clusterrole
kubectl get rolebinding -n default oidc-default-namespace

Utilisation de l'OIDC sur votre cluster

Nous disposons désormais de :

• Un cluster Kubernetes configuré pour accepter l'authentification OIDC
• Un fichier kubeconfig qui redirige l'utilisateur de kubectl vers le serveur OIDC Keycloak
• Un utilisateur Keycloak oidc-admin-user associé au groupe ClusterAdmins
• Un ClusterRoleBinding associant le groupe oidcgroup:ClusterAdmins au ClusterRole nommé cluster-admin
• Un utilisateur Keyclaok oidc-regular-user associé au groupe DefaultNamespace
• Un RoleBinding associant le groupe oidcgroup:DefaultNamespace au ClusterRole nommé oidc-default-namespace-clusterrole dans le Namespace default
• Un ClusterRole nommé oidc-default-namespace-clusterrole définissant des droits spécifiques sur le cluster Kubernetes

Pour tester cette mise en œuvre, les utilisateurs devront installer le plugin kubectl nommé kubelogin (aussi appelé kubectl-oidc_login).

Installation de kubelogin

Les instructions complètes sont disponibles sur la page du projet kubelogin.

# macOS via Homebrew
brew install int128/kubelogin/kubelogin

# Vérification de l'installation
kubectl oidc-login --version

Tester l'utilisateur oidc-admin-user

Définissez la variable KUBECONFIG pour pointer vers le fichier kubeconfig que vous avez créé dans ce guide :

export KUBECONFIG=/path/to/your/custom/kubeconfig-oidc.yaml
 
# Vérification du contexte actif
kubectl config current-context
# Output: oidc-context

Puis demandez le listing des Namespaces du cluster Kubernetes :

kubectl get namespaces

Votre navigateur ouvre un onglet sur le serveur Keycloak et invite l'utilisateur à s'authentifier.
Utilisez le compte oidc-admin-user. Une fois identifié, l'onglet affiche une page sur localhost:8000 avec la confirmation de la connexion. Vous pouvez fermer cet onglet.

Retournez sur votre terminal, vous devriez voir la liste des Namespaces de votre cluster, puisque vous disposez des droits complets sur le cluster.

Tester l'utilisateur oidc-regular-user

Vous êtes déjà identifié avec le compte oidc-admin-user, donc pour continuer vous aurez besoin de vous déconnecter de Keycloak.

Si vous ne connaissez pas l'URL de déconnexion, vous pouvez la reconstituer : https://[KEYCLOAK-URL]/auth/realms/[KEYCLOAK-REALM]/account puis cliquer sur le bouton Sign Out situé en haut à droite de la page.

Vous pouvez également supprimer le cache kubectl sur votre poste pour forcer une nouvelle authentification :

rm -rf ~/.kube/cache
 
# Alternative : supprimer uniquement le cache OIDC
rm -rf ~/.kube/cache/oidc-login

En utilisant le même fichier kubeconfig qu'à l'étape précédente, demandez le listing des Namespaces du cluster Kubernetes :

export KUBECONFIG=/path/to/your/custom/kubeconfig-oidc.yaml
kubectl get namespaces

Votre navigateur ouvre à nouveau un onglet sur le serveur Keyclaok et vous invite à vous identifier.
Utilisez le compte oidc-regular-user. Une fois identifié, l'onglet affiche une page sur localhost:8000 avec la confirmation de connexion. Vous pouvez fermer cet onglet.

Retournez sur votre terminal, vous devriez avoir une erreur comme qui suit :

$ kubectl get namespaces
Error from server (Forbidden): namespaces is forbidden: User "oidcuser:xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx" cannot list resource "namespaces" in API group "" at the cluster scope

Vous n'avez en effet pas le droit de visualiser la liste des Namespaces, puisque vous êtes limité au Namespace default par le RoleBinding.

Listez les ressources déployées dans le Namespace default :

kubectl -n default get all
 
# Output:
# NAME                 TYPE        CLUSTER-IP   EXTERNAL-IP   PORT(S)   AGE
# service/kubernetes   ClusterIP   10.43.0.1    <none>        443/TCP   385d

Vous voyez bien le service kubernetes qui est situé dans ce Namespace. Vous disposez donc bien du droit uniquement sur ce Namespace.

Si vous tentez de visualiser d'autres objets ailleurs dans le cluster Kubernetes, vous aurez d'autres types d'erreurs :

$ kubectl -n probes get all
Error from server (Forbidden): pods is forbidden: User "oidcuser:xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx" cannot list resource "pods" in API group "" in the namespace "probes"
Error from server (Forbidden): replicationcontrollers is forbidden: User "oidcuser:xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx" cannot list resource "replicationcontrollers" in API group "" in the namespace "probes"
Error from server (Forbidden): services is forbidden: User "oidcuser:xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx" cannot list resource "services" in API group "" in the namespace "probes"
Error from server (Forbidden): daemonsets.apps is forbidden: User "oidcuser:xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx" cannot list resource "daemonsets" in API group "apps" in the namespace "probes"
Error from server (Forbidden): deployments.apps is forbidden: User "oidcuser:xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx" cannot list resource "deployments" in API group "apps" in the namespace "probes"
Error from server (Forbidden): replicasets.apps is forbidden: User "oidcuser:xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx" cannot list resource "replicasets" in API group "apps" in the namespace "probes"
Error from server (Forbidden): statefulsets.apps is forbidden: User "oidcuser:xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx" cannot list resource "statefulsets" in API group "apps" in the namespace "probes"
Error from server (Forbidden): horizontalpodautoscalers.autoscaling is forbidden: User "oidcuser:xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx" cannot list resource "horizontalpodautoscalers" in API group "autoscaling" in the namespace "probes"
Error from server (Forbidden): jobs.batch is forbidden: User "oidcuser:xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx" cannot list resource "jobs" in API group "batch" in the namespace "probes"
Error from server (Forbidden): cronjobs.batch is forbidden: User "oidcuser:xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx" cannot list resource "cronjobs" in API group "batch" in the namespace "probes"

Félicitations, vous venez d'activer avec succès une authentification OIDC sur votre cluster Kubernetes à l'aide de Keycloak.

Bonnes pratiques et recommandations

Sécurité

• Durée de vie des tokens : Configurez une durée courte (5-10 minutes) pour minimiser la fenêtre d'exploitation en cas de compromission
• Rotation du Client Secret : Changez périodiquement le Client Secret Keycloak (tous les 90 jours minimum)
• HTTPS obligatoire : Assurez-vous que Keycloak est accessible uniquement en HTTPS pour éviter l'interception des tokens
• Multi-Factor Authentication (MFA) : Activez l'authentification multi-facteurs dans Keycloak pour renforcer la sécurité
• Audit des sessions : Surveillez régulièrement les sessions actives dans Keycloak (Sessions tab)

Gestion des groupes et RBAC

• Principe du moindre privilège : Accordez uniquement les permissions strictement nécessaires
• Groupes granulaires : Créez des groupes Keycloak par rôle fonctionnel (ex: dev-readers, prod-deployers, monitoring-viewers)
• Séparation des environnements : Utilisez des groupes distincts pour dev, staging et production
• Documentation des rôles : Documentez clairement les responsabilités et permissions de chaque groupe
• Revue périodique : Auditez régulièrement les membres des groupes et les RBAC associés

Opérations

• Fichier kubeconfig versionné : Stockez le fichier kubeconfig générique dans un dépôt Git (sans secrets sensibles)
• Distribution sécurisée : Partagez le kubeconfig via des canaux sécurisés (pas par email non chiffré)
• Monitoring : Surveillez les échecs d'authentification dans les logs de l'API Server Kubernetes
• Sauvegarde Keycloak : Sauvegardez régulièrement la configuration Keycloak (realm export)
• Plan de repli : Conservez toujours un kubeconfig admin traditionnel en cas de défaillance de Keycloak

Performance

• Mise en cache des tokens : Le cache local (~/.kube/cache/oidc-login) évite les ré-authentifications répétées
• Connexions réseau : Assurez-vous d'une latence faible entre les utilisateurs et Keycloak
• Resource limits : Dimensionnez correctement votre instance Keycloak selon le nombre d'utilisateurs

Cas d'usage avancés

FAQ

Est-il possible de révoquer l'accès à un utilisateur ?

Oui, l'un des principaux avantages de l'authentification OIDC centralisée est la possibilité de révoquer instantanément les accès. Plusieurs méthodes existent :

• Rendez-vous dans Manage > Users dans Keycloak
• Sélectionnez l'utilisateur concerné
• Basculez User Enabled sur Off
• L'utilisateur ne pourra plus s'authentifier dès la prochaine tentative

• Accédez à l'onglet Groups de l'utilisateur
• Retirez-le de tous les groupes ayant des droits Kubernetes
• Les permissions RBAC ne s'appliqueront plus

• Allez dans Manage > Users > [Utilisateur] > Sessions
• Cliquez sur Logout pour invalider toutes les sessions actives
• Les tokens JWT actuels seront révoqués immédiatement

Comment régler la durée de vie du token JWT ?

1. Connectez-vous à la console d'administration Keycloak
2. Accédez à Configure > Clients
3. Sélectionnez le client OIDC créé pour Kubernetes (ex: kube-oidc)
4. Descendez dans la section Advanced Settings
5. Modifiez le paramètre Access Token Lifespan

• SSO Session Idle : Durée avant expiration d'une session inactive (recommandé : 30 minutes)
• SSO Session Max : Durée maximale d'une session (recommandé : 8-10 heures)
• Client Session Idle : Durée d'inactivité avant reconnexion (recommandé : 15 minutes)

Est-il possible d'avoir deux sources de connexion OIDC pour un cluster Kubernetes ?

Non, Kubernetes ne supporte qu'un seul provider OIDC par cluster. C'est une limitation technique de l'API Server Kubernetes.

1. Utiliser les Identity Providers de Keycloak
   Keycloak peut fédérer plusieurs sources d'authentification externes (Google, GitHub, Azure AD, LDAP, etc.)

   • Rendez-vous dans Configure > Identity Providers dans Keycloak
   • Ajoutez les providers souhaités (GitHub, Google, StackOverflow, Microsoft, etc.)
   • Les utilisateurs choisiront leur méthode d'authentification lors du login
   • Tous passeront par le même endpoint OIDC Keycloak côté Kubernetes
2. Synchronisation LDAP/Active Directory
   • Configurez Keycloak pour synchroniser les utilisateurs depuis votre annuaire d'entreprise
   • Les utilisateurs s'authentifient avec leurs credentials habituels
   • Les groupes peuvent être synchronisés automatiquement
3. Fédération SAML
   • Si votre organisation utilise SAML, Keycloak peut agir comme pont SAML ↔ OIDC

Est-ce que l'OIDC empêche de continuer à utiliser des kubeconfig originels ?

Non, l'OIDC est une méthode d'authentification complémentaire. Kubernetes supporte simultanément plusieurs mécanismes :

• Utilisateurs interactifs → OIDC (via Keycloak)
• Pipelines CI/CD → ServiceAccounts avec RBAC dédiés
• Break-glass admin → Certificat client classique (stocké en coffre-fort)
• Outils d'exploitation → ServiceAccounts avec permissions restreintes

Comment procéder pour authentifier un automate, comme le CI/CD ?

Les automates ne doivent PAS utiliser OIDC. OIDC est conçu pour l'authentification interactive (navigateur). Pour les automatisations, utilisez des ServiceAccounts Kubernetes.

apiVersion: v1
kind: ServiceAccount
metadata:
  name: cicd-deployer
  namespace: default
  labels:
    app.kubernetes.io/component: automation
    app.kubernetes.io/managed-by: kubectl

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: cicd-deployer-role
  namespace: default
rules:
- apiGroups: ["apps"]
  resources: ["deployments", "replicasets"]
  verbs: ["get", "list", "create", "update", "patch"]
- apiGroups: [""]
  resources: ["services", "configmaps", "secrets"]
  verbs: ["get", "list", "create", "update", "patch"]

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: cicd-deployer-binding
  namespace: default
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: Role
  name: cicd-deployer-role
subjects:
- kind: ServiceAccount
  name: cicd-deployer
  namespace: default

# Récupérer le token du ServiceAccount (Kubernetes 1.24+)
kubectl -n default create token cicd-deployer --duration=87600h > sa-token.txt
 
# Construire le kubeconfig
kubectl config set-cluster my-cluster \
  --server=https://[CLUSTER-API-ENDPOINT] \
  --certificate-authority=/path/to/ca.crt \
  --embed-certs=true \
  --kubeconfig=kubeconfig-cicd
 
kubectl config set-credentials cicd-deployer \
  --token=$(cat sa-token.txt) \
  --kubeconfig=kubeconfig-cicd
 
kubectl config set-context cicd-context \
  --cluster=my-cluster \
  --user=cicd-deployer \
  --namespace=default \
  --kubeconfig=kubeconfig-cicd
 
kubectl config use-context cicd-context --kubeconfig=kubeconfig-cicd

deploy:
  stage: deploy
  script:
    - export KUBECONFIG=./kubeconfig-cicd
    - kubectl apply -f deployment.yaml
  only:
    - main

Pour plus de détails sur la gestion des RBAC et ServiceAccounts, consultez le guide RBAC.

Comment déboguer les problèmes d'authentification OIDC ?

# Afficher le token JWT décodé
kubectl oidc-login get-token \
  --oidc-issuer-url=https://[KEYCLOAK-URL]/auth/realms/[REALM] \
  --oidc-client-id=[CLIENT-ID] \
  --oidc-client-secret=[SECRET] \
  | jq -R 'split(".") | .[1] | @base64d | fromjson'
 
# Tester l'authentification sans cache
rm -rf ~/.kube/cache/oidc-login
kubectl get nodes -v=8  # Mode verbose pour voir les détails
 
# Vérifier les logs de l'API Server (côté SdV)
# Contactez l'équipe SdV pour analyser les logs si nécessaire

# Tester l'endpoint OIDC discovery
curl https://[KEYCLOAK-URL]/auth/realms/[REALM]/.well-known/openid-configuration | jq
 
# Vérifier que l'issuer correspond exactement
# Comparer avec la valeur dans votre kubeconfig

Commandes kubectl utiles

Une fois l'authentification OIDC configurée, voici les commandes essentielles pour l'exploitation quotidienne :

# Vérifier l'identité actuelle (utilisateur OIDC)
kubectl auth whoami
 
# Lister les permissions de l'utilisateur courant
kubectl auth can-i --list
 
# Tester une permission spécifique
kubectl auth can-i create deployments -n default
kubectl auth can-i get pods --all-namespaces
 
# Afficher le contexte actif et le kubeconfig utilisé
kubectl config current-context
kubectl config view
 
# Forcer une ré-authentification (vider le cache)
rm -rf ~/.kube/cache/oidc-login
kubectl get nodes  # Déclenchera une nouvelle authentification
 
# Consulter les informations du token JWT (debug)
kubectl oidc-login get-token \
  --oidc-issuer-url=https://[KEYCLOAK-URL]/auth/realms/[REALM] \
  --oidc-client-id=[CLIENT-ID] \
  --oidc-client-secret=[SECRET]
 
# Vérifier les RoleBindings appliqués à un groupe OIDC
kubectl get rolebinding,clusterrolebinding -A -o json \
  | jq '.items[] | select(.subjects[]?.name | contains("oidcgroup:"))'
 
# Lister les ClusterRoles disponibles
kubectl get clusterrole | grep -i admin
 
# Voir les détails d'un ClusterRoleBinding
kubectl describe clusterrolebinding oidc-cluster-admins

Récapitulatif

Vous avez maintenant configuré une authentification OIDC complète pour votre cluster Kubernetes. Cette mise en place permet :

• Gestion centralisée : Un seul point de gestion des identités (Keycloak)
• Sécurité renforcée : Révocation instantanée, MFA, audit centralisé
• Expérience utilisateur : Un fichier kubeconfig partageable, authentification transparente
• Conformité : Traçabilité précise des actions par utilisateur
• Scalabilité : Ajout/suppression d'utilisateurs sans redistribuer de secrets

1. Configurez des groupes Keycloak selon vos équipes et projets
2. Créez des ClusterRoles granulaires adaptés à vos besoins
3. Activez la MFA dans Keycloak pour renforcer la sécurité
4. Mettez en place un processus d'onboarding/offboarding documenté
5. Configurez la surveillance des événements d'authentification (Keycloak Events)
6. Planifiez la rotation du Client Secret Keycloak
7. Documentez votre politique RBAC pour les nouveaux arrivants

Pour aller plus loin :

• Consultez le guide RBAC pour des exemples de politiques d'autorisation avancées
• Explorez la documentation Keycloak pour les fonctionnalités avancées (Identity Brokering, User Federation, Custom Authenticators)
• Lisez la documentation Kubernetes sur l'authentification pour comprendre les options de configuration de l'API Server