Aller au contenu principal
TechLedger Registre technique
kubernetessécurité

Authentification SSO du Kubernetes API Server via Keycloak (OIDC Provider)

La gestion des accès à Kubernetes api server peut rapidement devenir complexe, surtout dans des environnements avec de nombreux utilisateurs et équipes. Pour simplifier et sécuriser cette…

coolibra08 juil. 2026665 vues

La gestion des accès à Kubernetes api server peut rapidement devenir complexe, surtout dans des environnements avec de nombreux utilisateurs et équipes. Pour simplifier et sécuriser cette authentification, il est possible de mettre en place un Single Sign-On (SSO) pour l’API Server Kubernetes en utilisant Keycloak comme porvider OpenID Connect (OIDC).

SSO pour Kubernetes

Kubernetes offre nativement des mécanismes d’accès tels que les certificats client ou les tokens statiques, et il est courant de partager le kubeconfig administrateur entre plusieurs utilisateurs. Le SSO résout ce problèmes en centralisant l’authentification via un fournisseur d’identité, permettant aux utilisateurs de se connecter à Kubernetes avec leurs identifiants existants.

Keycloak comme fournisseur OIDC

En configurant Kubernetes pour utiliser Keycloak comme Identity Provider OIDC, l’API Server délègue l’authentification à Keycloak, ce qui permet de :

  • Vérifier automatiquement les jetons JWT émis par Keycloak.

  • Mapper les rôles Keycloak aux roles Kubernetes (RBAC).

  • Simplifier la gestion des utilisateurs et groupes dans Kubernetes.

Comment ça fonctionne ?

  1. L’utilisateur ouvre son kubeconfig et tente de se connecter à l’API Server.

  2. L’API Server redirige l’utilisateur vers Keycloak pour l’authentification.

  3. Keycloak valide l’identité et renvoie un jeton JWT à l’utilisateur.

  4. L’API Server vérifie le jeton et applique les droits RBAC associés.

Requirements:

Installer krew

(
  set -x; cd "$(mktemp -d)" &&
  OS="$(uname | tr '[:upper:]' '[:lower:]')" &&
  ARCH="$(uname -m | sed -e 's/x86_64/amd64/' -e 's/\(arm\)\(64\)\?.*/\1\2/' -e 's/aarch64$/arm64/')" &&
  KREW="krew-${OS}_${ARCH}" &&
  curl -fsSLO "https://github.com/kubernetes-sigs/krew/releases/latest/download/${KREW}.tar.gz" &&
  tar zxvf "${KREW}.tar.gz" &&
  ./"${KREW}" install krew
)

 

export PATH="${KREW_ROOT:-$HOME/.krew}/bin:$PATH"
echo 'export PATH="${KREW_ROOT:-$HOME/.krew}/bin:$PATH"' >> ~/.bashrc
source ~/.bashrc

 

Installer kubelogin

    • Une fois krew installer, on peut installer le plugin oidc-login avec kubectl
kubectl krew install oidc-login

kubectl oidc-login version

 

Configuration du client dans keycloak

  • Créer un nouveau client

    1. Dans keycloak sélectionne le realm dans lequel on veut créer le client

    2. Dans le menu de gauche, clique sur Clients → Create.

    3. Remplis les champs principaux :

      • General settings

        • Client ID : kubernetes (ou un nom pertinent).

        • Client Protocol : openid-connect.

        • Description: kubernetes SSO (une description)
        • Always display in UI: Disabled

 

        • Web origins: /*
        • Admin URL: laisse vide

 

      •  Capability config
        • Authentication flow: Enabled
        • Direct access grants: Enabled  

 

      • Login settings et logout settings
        • Front channel logout: Enabled
        • Front-channel logout session required: Enabled
        • Clique sur Save

 

      • Dans client > kubernetes > roles
        • Créer ces deux roles: 
          • kube-admin-role pour cuex qui auront les droits admin sur les clusters kubernetes
          • kube-readonly-role pour ceux qui auront les droits read only sur les clusters kubernetes

 

      • Dans clients > kubernetes > dedicated scopes
        • clic sur kubernetes-dedicated > add mapper > by configuration > select User Client Role
        • Name : roles
        • Client ID : kubernetes (il s'agit du nom du client créé précédemment)
        • Client Role prefix : laisse vide
        • Multivalued : enabled
        • Token Claim Name : roles (ce nom sera ajouté à la configuration de l’API Server)
        • Claim JSON Type : String
        • Add to ID token : enabled
        • Add to access token : disabled
        • Add to userinfo : disabled
        • Add to token introspection : disabled
        • Clic sur save

 

      • Mappage des groupes aux roles keycloal
        • Créer le groupe des administrateurs et le groupe des readonly. dans mon cas j'ai techledger-admins et techledger-readonly avec des users dedans.
        • Dans keycloak > groups > select le groupe > Role mapping > Assign role > client role > select kube-admin-role pour le group des admin et kube-readonly-role pour le group des readonly

La configuration de keycloak est terminée, nou allons passer à l'api server de kubernetes

Configuration de l'api server de kubernetes

Selon la distribution de kubernetes, il faut adapter la conf:

    • Pour kubeadm
apiServer:
  extraArgs:
    oidc-issuer-url: "https://keycloak-domaine/realms/your-realm"
    oidc-client-id: "kubernetes"
    oidc-username-claim: "email"
    oidc-username-prefix: "oidc:"
    oidc-groups-claim: "roles"
    oidc-groups-prefix: "oidc:"

 

    • Pour RKE2
kube-apiserver-arg:
  - "oidc-issuer-url=https://keycloak-domaine/realms/your-realm"
  - "oidc-client-id=kubernetes"
  - "oidc-username-claim=email"
  - "oidc-username-prefix=oidc:"
  - "oidc-groups-claim=roles"
  - "oidc-groups-prefix=oidc:"

 

Une fois l'api-server configuré et le cluster lancé, il faut créer des clusterRoles et clusterRoleBindings relatifs aux groups keycloak

  • Pour notre exemple on va prendre les clusterRoles par defaut cluster-admin pour les adminstrateurs du cluster et view pour les readonly du cluster
  • Le clusterRoleBindings sont
    • cluster-role-binding.yaml
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: oidc-cluster-admin
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: cluster-admin
subjects:
  - kind: Group
    name: oidc:kube-admin-role
    apiGroup: rbac.authorization.k8s.io
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: oidc-cluster-view
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: view
subjects:
  - kind: Group
    name: oidc:kube-readonly-role
    apiGroup: rbac.authorization.k8s.io

 

kubectl apply -f cluster-role-binding.yaml

 

Une fois appliqué, on peut tester. kubelogin dejà installé je suppose 

kubectl oidc-login setup \
  --oidc-issuer-url=https://keycloak-domaine/realms/master \
  --oidc-client-id=kubernetes --oidc-pkce-method=S256

 

On vois bien le token retourné avec les claims

 

 

On execute la commande 4 pour generer le kubeconfig

kubectl config set-credentials <cluster_name_or_custom_name> \
  --exec-api-version=client.authentication.k8s.io/v1 \
  --exec-interactive-mode=Never \
  --exec-command=kubectl \
  --exec-arg=oidc-login \
  --exec-arg=get-token \
  --exec-arg="--oidc-issuer-url=https://auth.techledger.io/realms/master" \
  --exec-arg="--oidc-client-id=kubernetes" \
  --exec-arg="--oidc-pkce-method=S256"

 

      • A adapter
apiVersion: v1
clusters:
- cluster:
    certificate-authority-data: LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0tCk1JSUJlRENDQVIrZ0F3SUJ
    server: https://10.10.10.11:6443
  name: rke2-debian-cluster
contexts:
- context:
   cluster: rke2-debian-cluster
   user: rke2-debian-cluster
   namespace: default
  name: rke2-debian-cluster
current-context: rke2-debian-cluster
kind: Config
preferences: {}
users:
- name: rke2-debian-cluster
  user:
    exec:
      apiVersion: client.authentication.k8s.io/v1
      args:
      - oidc-login
      - get-token
      - --oidc-issuer-url=https://auth.techledger.io/realms/master
      - --oidc-client-id=kubernetes
      - --oidc-pkce-method=S256
      command: kubectl
      env: null
      interactiveMode: Never
      provideClusterInfo: false

 

Le kubeconfig

L'adminstrateur generera un fichier semblable pour tous les clusters et les partager avec les équipes. Au lance de k9s ou kubectl kubellogin va nous rediriger sur la page d'authent keycloak afin d'accorder les bons droits rbac.

Avantages

  • Centralisation de l’authentification et des identités.

  • Renforcement de la sécurité grâce à Keycloak et aux MFA.

  • Expérience utilisateur simplifiée : un seul login pour tous les services.

  • Conformité et traçabilité améliorées grâce aux logs centralisés

 

Conclusion

Ce mécanisme facilite la gestion des identités, renforce la sécurité et simplifie l’administration des environnement Kubernetes.

Les administrateurs devront créer les groupes, les clusterRoles et les CluserRoleBindings selon le besoin.

Commentaires

Connectez-vous pour rejoindre la discussion.

Aucun commentaire pour le moment.