Docs

Journal d'audit

À quoi sert cet écran

Le journal d’audit consigne ce que les personnes ont fait via Cluster Console — et, tout aussi important, ce qui leur a été refusé. Parce que Cluster Console agit directement sur des clusters en production, c’est cette trace qui rend la chose acceptable.

Avant de commencer

Pour faire ceci Il vous faut
Ouvrir le journal d’audit cluster-console.read

Ouvrir l’écran

URL directe : /cluster-console/audit

L’interface

📸 Capture d’écran : Le journal d’audit avec plusieurs entrées, dont une refusée. Repères : (1) la colonne When, (2) la colonne Outcome avec une entrée refusée, (3) Action, (4) User, (5) Cluster, (6) Target, (7) Reason.

Colonne Ce qu’elle vous dit
When L’heure de la tentative
Outcome Si elle a réussi ou a été refusée
Action L’action tentée
User Qui l’a tentée
Cluster Sur quel cluster
Target Sur quelle ressource
Reason Pourquoi elle a été refusée — affiché sur l’entrée refusée

Le couple Outcome / Reason est ce qui fait de cet écran autre chose qu’un journal des modifications. Une entrée refusée vous apprend que quelqu’un a tenté quelque chose et qu’un garde-fou ou une permission l’a arrêté — information utile, qu’il s’agisse d’une erreur ou du signe que ses accès ne correspondent pas à son travail.

Procédures

Savoir qui a modifié quelque chose

  1. Ouvrez le journal d’audit.
  2. Cherchez la ressource dans Target autour du moment où la modification est apparue.
  3. User et Action vous donnent la réponse.

Comprendre un refus

Trouvez l’entrée refusée et lisez Reason. Elle distingue les deux cas qui paraissent identiques à la personne qui les rencontre :

  • un garde-fou — le namespace ou le type est protégé ;
  • une permission — le droit correspondant à cette action lui manque.

Le correctif diffère selon le cas : lisez le motif avant d’agir sur un signalement.

Examiner l’activité après un incident

Filtrez sur le cluster et la fenêtre entourant l’incident. La combinaison des entrées réussies et refusées reconstitue en général ce que quelqu’un cherchait à faire, ce qui est plus utile que l’une ou l’autre isolément.

Scénario

Quelque chose a changé en production et personne ne s’est manifesté.

  1. Ouvrez le journal d’audit et cherchez la ressource dans Target, autour du moment où le comportement a changé.
  2. S’il existe une entrée correspondante, User et Action répondent directement, et vous avez terminé.
  3. S’il n’y a aucune entrée, c’est en soi une information : la modification n’est pas passée par Cluster Console. Regardez du côté de Déploiements pour une release, ou de l’onglet Events de l’environnement pour une réconciliation.
  4. Pendant que vous y êtes, cherchez les entrées refusées sur la même ressource. Un refus peu avant la modification montre souvent quelqu’un essayant une voie, se faisant arrêter, puis en empruntant une autre.
  5. Si les refus montrent une personne régulièrement bloquée sur ce dont son travail a besoin, c’est un constat de permissions et non de discipline. Corrigez dans Personnes et accès.

L’étape 3 est celle que l’on oublie. Un journal d’audit vide n’est pas « aucune réponse » : il écarte toute une voie et vous oriente vers les deux autres.

En cas de problème

Symptôme Cause Comment vérifier Solution
Impossible d’ouvrir le journal d’audit Il manque cluster-console.read Access Explorer Demandez un rôle qui l’accorde
Aucune entrée pour une modification pourtant réelle Elle n’est pas passée par Cluster Console Déploiements, ou l’onglet Events de l’environnement Cherchez sur la voie réellement empruntée
Beaucoup d’entrées refusées pour un même utilisateur Ses permissions ne correspondent pas à son travail La colonne Reason Ajustez son rôle, ou expliquez le garde-fou
Un refus indique « protégé » Un garde-fou, pas un manque de permission Le texte de Reason Nécessite cluster-console.protected.override, ou une voie plus sûre
Des entrées manquent pour un autre cluster La visibilité est déterminée cluster par cluster — Comportement attendu ; demandez l’accès à ce cluster

Pour aller plus loin