10.3. Configuration de la politique du journal d'audit avec des règles personnalisées
Vous pouvez configurer une politique de journal d'audit qui définit des règles personnalisées. Vous pouvez spécifier plusieurs groupes et définir le profil à utiliser pour chaque groupe.
Ces règles personnalisées ont la priorité sur le champ de profil de niveau supérieur. Les règles personnalisées sont évaluées de haut en bas, et la première qui correspond est appliquée.
Conditions préalables
-
Vous avez accès au cluster en tant qu'utilisateur ayant le rôle
cluster-admin
.
Procédure
Modifier la ressource
APIServer
:oc edit apiserver cluster
$ oc edit apiserver cluster
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Ajouter le champ
spec.audit.customRules
:Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- Ajoutez un ou plusieurs groupes et spécifiez le profil à utiliser pour ce groupe. Ces règles personnalisées ont la priorité sur le champ de profil de niveau supérieur. Les règles personnalisées sont évaluées de haut en bas, et la première qui correspond est appliquée.
- 2
- Définissez
Default
,WriteRequestBodies
,AllRequestBodies
ouNone
. Si vous ne définissez pas ce champ de niveau supérieuraudit.profile
, le profilDefault
est utilisé par défaut.
AvertissementIl n'est pas recommandé de désactiver la journalisation des audits à l'aide du profil
None
, sauf si vous êtes pleinement conscient des risques liés à l'absence de journalisation de données qui peuvent s'avérer utiles lors de la résolution de problèmes. Si vous désactivez la journalisation des audits et qu'une situation d'assistance se présente, vous devrez peut-être activer la journalisation des audits et reproduire le problème afin de le résoudre correctement.- Enregistrez le fichier pour appliquer les modifications.
Vérification
Vérifiez qu'une nouvelle révision des pods du serveur Kubernetes API est déployée. La mise à jour de tous les nœuds vers la nouvelle révision peut prendre plusieurs minutes.
oc get kubeapiserver -o=jsonpath='{range .items[0].status.conditions[?(@.type=="NodeInstallerProgressing")]}{.reason}{"\n"}{.message}{"\n"}'
$ oc get kubeapiserver -o=jsonpath='{range .items[0].status.conditions[?(@.type=="NodeInstallerProgressing")]}{.reason}{"\n"}{.message}{"\n"}'
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Examinez la condition d'état
NodeInstallerProgressing
pour le serveur API Kubernetes afin de vérifier que tous les nœuds sont à la dernière révision. La sortie indiqueAllNodesAtLatestRevision
lorsque la mise à jour est réussie :AllNodesAtLatestRevision 3 nodes are at revision 12
AllNodesAtLatestRevision 3 nodes are at revision 12
1 Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- Dans cet exemple, le dernier numéro de révision est
12
.
Si la sortie affiche un message similaire à l'un des messages suivants, la mise à jour est toujours en cours. Attendez quelques minutes et réessayez.
-
3 nodes are at revision 11; 0 nodes have achieved new revision 12
-
2 nodes are at revision 11; 1 nodes are at revision 12