Rechercher

6.4. Comprendre l'opérateur d'intégrité des fichiers

download PDF

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.

Important

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

  1. 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 sont Initializing, Pending, ou Active.

    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.

  2. 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

Note

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

Red Hat logoGithubRedditYoutubeTwitter

Apprendre

Essayez, achetez et vendez

Communautés

À propos de la documentation Red Hat

Nous aidons les utilisateurs de Red Hat à innover et à atteindre leurs objectifs grâce à nos produits et services avec un contenu auquel ils peuvent faire confiance.

Rendre l’open source plus inclusif

Red Hat s'engage à remplacer le langage problématique dans notre code, notre documentation et nos propriétés Web. Pour plus de détails, consultez leBlog Red Hat.

À propos de Red Hat

Nous proposons des solutions renforcées qui facilitent le travail des entreprises sur plusieurs plates-formes et environnements, du centre de données central à la périphérie du réseau.

© 2024 Red Hat, Inc.