6.4. Comprendre l'opérateur d'intégrité des fichiers
L'opérateur d'intégrité des fichiers est un opérateur de la plateforme de conteneurs OpenShift qui exécute continuellement des contrôles d'intégrité des fichiers sur les nœuds du cluster. Il déploie un ensemble de démons qui initialise et exécute des conteneurs AIDE (advanced intrusion detection environment) privilégiés sur chaque nœud, en fournissant un objet d'état avec un journal des fichiers modifiés lors de l'exécution initiale des pods de l'ensemble de démons.
Actuellement, seuls les nœuds Red Hat Enterprise Linux CoreOS (RHCOS) sont pris en charge.
6.4.1. Création de la ressource personnalisée FileIntegrity
Une instance d'une ressource personnalisée (CR) FileIntegrity
représente un ensemble d'analyses continues de l'intégrité des fichiers pour un ou plusieurs nœuds.
Chaque CR FileIntegrity
est soutenu par un ensemble de démons exécutant AIDE sur les nœuds correspondant à la spécification du CR FileIntegrity
.
Procédure
Créez l'exemple suivant
FileIntegrity
CR nomméworker-fileintegrity.yaml
pour activer les analyses sur les nœuds de travail :Exemple de FileIntegrity CR
apiVersion: fileintegrity.openshift.io/v1alpha1 kind: FileIntegrity metadata: name: worker-fileintegrity namespace: openshift-file-integrity spec: nodeSelector: 1 node-role.kubernetes.io/worker: "" tolerations: 2 - key: "myNode" operator: "Exists" effect: "NoSchedule" config: 3 name: "myconfig" namespace: "openshift-file-integrity" key: "config" gracePeriod: 20 4 maxBackups: 5 5 initialDelay: 60 6 debug: false status: phase: Active 7
- 1
- Définit le sélecteur pour la planification des analyses de nœuds.
- 2
- Spécifier
tolerations
pour planifier les nœuds avec des taches personnalisées. Si elle n'est pas spécifiée, une tolérance par défaut permettant l'exécution sur les nœuds principaux et infra est appliquée. - 3
- Définir un site
ConfigMap
contenant une configuration AIDE à utiliser. - 4
- Nombre de secondes de pause entre les contrôles d'intégrité AIDE. Les contrôles AIDE fréquents sur un nœud peuvent être gourmands en ressources, il peut donc être utile de spécifier un intervalle plus long. La valeur par défaut est de 900 secondes (15 minutes).
- 5
- Le nombre maximum de sauvegardes de la base de données et des journaux AIDE (restes du processus de réinitialisation) à conserver sur un nœud. Les anciennes sauvegardes au-delà de ce nombre sont automatiquement élaguées par le démon. La valeur par défaut est de 5.
- 6
- Nombre de secondes à attendre avant de lancer le premier contrôle d'intégrité AIDE. La valeur par défaut est 0.
- 7
- L'état d'exécution de l'instance
FileIntegrity
. Les statuts sontInitializing
,Pending
, ouActive
.
Initializing
L'objet
FileIntegrity
est en train d'initialiser ou de réinitialiser la base de données AIDE.Pending
Le déploiement de
FileIntegrity
est toujours en cours de création.Active
Les analyses sont actives et en cours.
Appliquer le fichier YAML à l'espace de noms
openshift-file-integrity
:$ oc apply -f worker-fileintegrity.yaml -n openshift-file-integrity
Vérification
Confirmez que l'objet
FileIntegrity
a été créé avec succès en exécutant la commande suivante :$ oc get fileintegrities -n openshift-file-integrity
Exemple de sortie
NAME AGE worker-fileintegrity 14s
6.4.2. Vérification de l'état de la ressource personnalisée FileIntegrity
La ressource personnalisée (CR) FileIntegrity
signale son état par l'intermédiaire de la sous-ressource .status.phase
.
Procédure
Pour demander l'état de
FileIntegrity
CR, exécutez la commande suivante :$ oc get fileintegrities/worker-fileintegrity -o jsonpath="{ .status.phase }"
Exemple de sortie
Active
6.4.3. Phases de ressources personnalisées FileIntegrity
-
Pending
- Phase qui suit la création de la ressource personnalisée (CR). -
Active
- Phase au cours de laquelle le démon de sauvegarde est opérationnel. -
Initializing
- Phase de réinitialisation de la base de données AIDE.
6.4.4. Comprendre l'objet FileIntegrityNodeStatuses
Les résultats de l'analyse du CR FileIntegrity
sont consignés dans un autre objet appelé FileIntegrityNodeStatuses
.
$ oc get fileintegritynodestatuses
Exemple de sortie
NAME AGE worker-fileintegrity-ip-10-0-130-192.ec2.internal 101s worker-fileintegrity-ip-10-0-147-133.ec2.internal 109s worker-fileintegrity-ip-10-0-165-160.ec2.internal 102s
Les résultats de l'objet FileIntegrityNodeStatus
peuvent prendre un certain temps avant d'être disponibles.
Il y a un objet de résultat par nœud. L'attribut nodeName
de chaque objet FileIntegrityNodeStatus
correspond au nœud analysé. L'état de l'analyse de l'intégrité du fichier est représenté dans le tableau results
, qui contient les conditions d'analyse.
$ oc get fileintegritynodestatuses.fileintegrity.openshift.io -ojsonpath='{.items[*].results}' | jq
L'objet fileintegritynodestatus
signale le dernier état d'une exécution AIDE et indique l'état sous la forme Failed
, Succeeded
ou Errored
dans un champ status
.
$ oc get fileintegritynodestatuses -w
Exemple de sortie
NAME NODE STATUS example-fileintegrity-ip-10-0-134-186.us-east-2.compute.internal ip-10-0-134-186.us-east-2.compute.internal Succeeded example-fileintegrity-ip-10-0-150-230.us-east-2.compute.internal ip-10-0-150-230.us-east-2.compute.internal Succeeded example-fileintegrity-ip-10-0-169-137.us-east-2.compute.internal ip-10-0-169-137.us-east-2.compute.internal Succeeded example-fileintegrity-ip-10-0-180-200.us-east-2.compute.internal ip-10-0-180-200.us-east-2.compute.internal Succeeded example-fileintegrity-ip-10-0-194-66.us-east-2.compute.internal ip-10-0-194-66.us-east-2.compute.internal Failed example-fileintegrity-ip-10-0-222-188.us-east-2.compute.internal ip-10-0-222-188.us-east-2.compute.internal Succeeded example-fileintegrity-ip-10-0-134-186.us-east-2.compute.internal ip-10-0-134-186.us-east-2.compute.internal Succeeded example-fileintegrity-ip-10-0-222-188.us-east-2.compute.internal ip-10-0-222-188.us-east-2.compute.internal Succeeded example-fileintegrity-ip-10-0-194-66.us-east-2.compute.internal ip-10-0-194-66.us-east-2.compute.internal Failed example-fileintegrity-ip-10-0-150-230.us-east-2.compute.internal ip-10-0-150-230.us-east-2.compute.internal Succeeded example-fileintegrity-ip-10-0-180-200.us-east-2.compute.internal ip-10-0-180-200.us-east-2.compute.internal Succeeded
6.4.5. Types de statut FileIntegrityNodeStatus CR
Ces conditions sont signalées dans le tableau de résultats de l'état FileIntegrityNodeStatus
CR correspondant :
-
Succeeded
- Le contrôle d'intégrité a réussi ; les fichiers et répertoires couverts par le contrôle AIDE n'ont pas été modifiés depuis la dernière initialisation de la base de données. -
Failed
- Le contrôle d'intégrité a échoué ; certains fichiers ou répertoires couverts par le contrôle AIDE ont été modifiés depuis la dernière initialisation de la base de données. -
Errored
- Le scanner AIDE a rencontré une erreur interne.
6.4.5.1. FileIntegrityNodeStatus CR exemple de réussite
Exemple de sortie d'une condition avec un statut de réussite
[ { "condition": "Succeeded", "lastProbeTime": "2020-09-15T12:45:57Z" } ] [ { "condition": "Succeeded", "lastProbeTime": "2020-09-15T12:46:03Z" } ] [ { "condition": "Succeeded", "lastProbeTime": "2020-09-15T12:45:48Z" } ]
Dans ce cas, les trois scanners ont réussi et il n'y a jusqu'à présent aucune autre condition.
6.4.5.2. FileIntegrityNodeStatus Exemple de statut d'échec CR
Pour simuler une condition d'échec, modifiez l'un des fichiers suivis par AIDE. Par exemple, modifiez /etc/resolv.conf
sur l'un des nœuds de travail :
$ oc debug node/ip-10-0-130-192.ec2.internal
Exemple de sortie
Creating debug namespace/openshift-debug-node-ldfbj ... Starting pod/ip-10-0-130-192ec2internal-debug ... To use host binaries, run `chroot /host` Pod IP: 10.0.130.192 If you don't see a command prompt, try pressing enter. sh-4.2# echo "# integrity test" >> /host/etc/resolv.conf sh-4.2# exit Removing debug pod ... Removing debug namespace/openshift-debug-node-ldfbj ...
Au bout d'un certain temps, la condition Failed
est signalée dans le tableau des résultats de l'objet FileIntegrityNodeStatus
correspondant. La condition Succeeded
précédente est conservée, ce qui vous permet de déterminer le moment où la vérification a échoué.
$ oc get fileintegritynodestatuses.fileintegrity.openshift.io/worker-fileintegrity-ip-10-0-130-192.ec2.internal -ojsonpath='{.results}' | jq -r
Alternativement, si vous ne mentionnez pas le nom de l'objet, exécutez :
$ oc get fileintegritynodestatuses.fileintegrity.openshift.io -ojsonpath='{.items[*].results}' | jq
Exemple de sortie
[ { "condition": "Succeeded", "lastProbeTime": "2020-09-15T12:54:14Z" }, { "condition": "Failed", "filesChanged": 1, "lastProbeTime": "2020-09-15T12:57:20Z", "resultConfigMapName": "aide-ds-worker-fileintegrity-ip-10-0-130-192.ec2.internal-failed", "resultConfigMapNamespace": "openshift-file-integrity" } ]
La condition Failed
pointe vers une carte de configuration qui donne plus de détails sur ce qui a échoué et pourquoi :
$ oc describe cm aide-ds-worker-fileintegrity-ip-10-0-130-192.ec2.internal-failed
Exemple de sortie
Name: aide-ds-worker-fileintegrity-ip-10-0-130-192.ec2.internal-failed Namespace: openshift-file-integrity Labels: file-integrity.openshift.io/node=ip-10-0-130-192.ec2.internal file-integrity.openshift.io/owner=worker-fileintegrity file-integrity.openshift.io/result-log= Annotations: file-integrity.openshift.io/files-added: 0 file-integrity.openshift.io/files-changed: 1 file-integrity.openshift.io/files-removed: 0 Data integritylog: ------ AIDE 0.15.1 found differences between database and filesystem!! Start timestamp: 2020-09-15 12:58:15 Summary: Total number of files: 31553 Added files: 0 Removed files: 0 Changed files: 1 --------------------------------------------------- Changed files: --------------------------------------------------- changed: /hostroot/etc/resolv.conf --------------------------------------------------- Detailed information about changes: --------------------------------------------------- File: /hostroot/etc/resolv.conf SHA512 : sTQYpB/AL7FeoGtu/1g7opv6C+KT1CBJ , qAeM+a8yTgHPnIHMaRlS+so61EN8VOpg Events: <none>
En raison de la limite de taille des données de la carte de configuration, les journaux AIDE de plus de 1 Mo sont ajoutés à la carte de configuration des défaillances sous la forme d'une archive gzip codée en base64. Dans ce cas, vous souhaitez diriger la sortie de la commande ci-dessus vers base64 --decode | gunzip
. Les journaux compressés sont indiqués par la présence d'une clé d'annotation file-integrity.openshift.io/compressed
dans la carte de configuration.
6.4.6. Comprendre les événements
Les transitions dans l'état des objets FileIntegrity
et FileIntegrityNodeStatus
sont enregistrées par events. L'heure de création de l'événement reflète la dernière transition, par exemple de Initializing
à Active
, et pas nécessairement le dernier résultat de l'analyse. Cependant, l'événement le plus récent reflète toujours l'état le plus récent.
$ oc get events --field-selector reason=FileIntegrityStatus
Exemple de sortie
LAST SEEN TYPE REASON OBJECT MESSAGE 97s Normal FileIntegrityStatus fileintegrity/example-fileintegrity Pending 67s Normal FileIntegrityStatus fileintegrity/example-fileintegrity Initializing 37s Normal FileIntegrityStatus fileintegrity/example-fileintegrity Active
Lorsqu'une analyse de nœud échoue, un événement est créé avec les informations add/changed/removed
et config map.
$ oc get events --field-selector reason=NodeIntegrityStatus
Exemple de sortie
LAST SEEN TYPE REASON OBJECT MESSAGE 114m Normal NodeIntegrityStatus fileintegrity/example-fileintegrity no changes to node ip-10-0-134-173.ec2.internal 114m Normal NodeIntegrityStatus fileintegrity/example-fileintegrity no changes to node ip-10-0-168-238.ec2.internal 114m Normal NodeIntegrityStatus fileintegrity/example-fileintegrity no changes to node ip-10-0-169-175.ec2.internal 114m Normal NodeIntegrityStatus fileintegrity/example-fileintegrity no changes to node ip-10-0-152-92.ec2.internal 114m Normal NodeIntegrityStatus fileintegrity/example-fileintegrity no changes to node ip-10-0-158-144.ec2.internal 114m Normal NodeIntegrityStatus fileintegrity/example-fileintegrity no changes to node ip-10-0-131-30.ec2.internal 87m Warning NodeIntegrityStatus fileintegrity/example-fileintegrity node ip-10-0-152-92.ec2.internal has changed! a:1,c:1,r:0 \ log:openshift-file-integrity/aide-ds-example-fileintegrity-ip-10-0-152-92.ec2.internal-failed
Toute modification du nombre de fichiers ajoutés, modifiés ou supprimés entraîne un nouvel événement, même si l'état du nœud n'a pas changé.
$ oc get events --field-selector reason=NodeIntegrityStatus
Exemple de sortie
LAST SEEN TYPE REASON OBJECT MESSAGE 114m Normal NodeIntegrityStatus fileintegrity/example-fileintegrity no changes to node ip-10-0-134-173.ec2.internal 114m Normal NodeIntegrityStatus fileintegrity/example-fileintegrity no changes to node ip-10-0-168-238.ec2.internal 114m Normal NodeIntegrityStatus fileintegrity/example-fileintegrity no changes to node ip-10-0-169-175.ec2.internal 114m Normal NodeIntegrityStatus fileintegrity/example-fileintegrity no changes to node ip-10-0-152-92.ec2.internal 114m Normal NodeIntegrityStatus fileintegrity/example-fileintegrity no changes to node ip-10-0-158-144.ec2.internal 114m Normal NodeIntegrityStatus fileintegrity/example-fileintegrity no changes to node ip-10-0-131-30.ec2.internal 87m Warning NodeIntegrityStatus fileintegrity/example-fileintegrity node ip-10-0-152-92.ec2.internal has changed! a:1,c:1,r:0 \ log:openshift-file-integrity/aide-ds-example-fileintegrity-ip-10-0-152-92.ec2.internal-failed 40m Warning NodeIntegrityStatus fileintegrity/example-fileintegrity node ip-10-0-152-92.ec2.internal has changed! a:3,c:1,r:0 \ log:openshift-file-integrity/aide-ds-example-fileintegrity-ip-10-0-152-92.ec2.internal-failed