Version : 1.0 — 28/07/2026
Public : Support N2
Criticité : P1 — tout l'écosystème dépend du SSO (Moodle, forge, wikis…). Down 4 jours lors de l'incident du 23/07/2026 : la vitesse de diagnostic ici est décisive.
| Élément | Valeur |
|---|---|
| URL | auth.rber.bj → NAT 102.222.216.6 → HAProxy externe (SNI) → Ingress 10.29.113.201 |
| Namespace | keycloak |
| Pods | keycloak-0, keycloak-1 (StatefulSet, cluster Infinispan, 2 Gi RAM chacun) |
| Base | CNPG keycloak-pg 3 instances — utilisateur applicatif keycloak (pas app : le rôle app généré par CNPG a causé 3 jours de panne le 27/07) |
| Realms | uac (85 477 users), up (41 238), unstim (6 936), una (2 530) — fédération LDAP lecture seule |
| LDAP | UAC 10.24.112.33, UNSTIM 10.21.112.33, UP 10.25.112.33, UNA 10.20.112.33 — port 389 |
| Thèmes | Thèmes custom par université ; logo décodé base64 par init container |
| Sauvegarde | Barman → MinIO, archive_timeout 5 min (perte max théorique 5 min) |
kubectl config current-context # RKE2
kubectl -n keycloak get pods -o wide
kubectl -n keycloak get clusters.postgresql.cnpg.io # "Cluster in healthy state" attendu
kubectl -n keycloak get ingress,endpoints
kubectl -n keycloak logs keycloak-0 --tail=100
| Constat | Aller à |
|---|---|
| auth.rber.bj down, pods non Ready | §3 |
| Une université ne peut plus se connecter, les autres oui | §4 |
| Un utilisateur précis | §5 |
| Base dégradée | §6 |
| Admin console / realm inaccessible | §7 |
describe pod : OOM ? (2 Gi peuvent saturer en pointe) → consigner, redémarrage ciblé kubectl -n keycloak delete pod keycloak-0 (un seul à la fois, attendre son retour Ready avant l'autre — cluster Infinispan).keycloak avec le bon mot de passe :kubectl -n keycloak get secret RENSEIGNER_SECRET_KEYCLOAK_DB -o jsonpath='{.data.username}' | base64 -d
kubectl -n keycloak exec keycloak-pg-1 -- psql -U keycloak -c "SELECT 1"
Désalignement → N3 (restauration du secret d'origine, pas de recréation improvisée).
4. Pods Ready mais URL down → chaîne d'accès (Ingress, NetPol triptyque, HAProxy externe) — même logique que Runbook-N2-Moodle §3.
Cause quasi certaine : LDAP de l'université injoignable (serveur hébergé chez l'université, pas chez RBER).
# Depuis un pod keycloak :
kubectl -n keycloak exec keycloak-0 -- bash -c "timeout 3 bash -c '</dev/tcp/10.21.112.33/389' && echo OK || echo KO"
# Remplacer l'IP selon l'université
User federation du realm → Test connection / Test authentication → si erreur de bind : mot de passe du compte de service LDAP changé côté université → N3 avec la DSI.User federation → Sync changed users.kubectl -n keycloak get backups.postgresql.cnpg.io).| Opération | Où | Condition |
|---|---|---|
| Recherche/consultation utilisateur | Console admin, realm concerné | Compte admin nominatif |
Sync LDAP manuelle (Sync changed users) |
User federation du realm | Consigner |
| Déconnexion forcée d'un utilisateur (sessions) | Users → Sessions → Logout | Demande sécurité tracée |
| Redémarrage pod (un à la fois) | kubectl | Cause identifiée |
kubectl -n keycloak get clusters.postgresql.cnpg.io : healthy, 3/3