5.10. Gestion des résultats de l'opérateur de conformité et remédiation

Par défaut, les objets ComplianceCheckResult sont étiquetés avec plusieurs étiquettes utiles qui vous permettent d'interroger les contrôles et de décider des étapes suivantes une fois les résultats générés.

Liste des chèques appartenant à une suite spécifique :

$ oc get -n openshift-compliance compliancecheckresults \
  -l compliance.openshift.io/suite=workers-compliancesuite

Liste des chèques appartenant à une analyse spécifique :

$ oc get -n openshift-compliance compliancecheckresults \
-l compliance.openshift.io/scan=workers-scan

Tous les objets ComplianceCheckResult ne créent pas d'objets ComplianceRemediation. Seuls les objets ComplianceCheckResult qui peuvent être remédiés automatiquement le font. Un objet ComplianceCheckResult a une remédiation associée s'il est étiqueté avec le label compliance.openshift.io/automated-remediation. Le nom de la remédiation est le même que celui du contrôle.

Dressez la liste de tous les contrôles défaillants qui peuvent être corrigés automatiquement :

$ oc get -n openshift-compliance compliancecheckresults \
-l 'compliance.openshift.io/check-status=FAIL,compliance.openshift.io/automated-remediation'

Liste de tous les contrôles défaillants, classés par gravité :

$ oc get compliancecheckresults -n openshift-compliance \
-l 'compliance.openshift.io/check-status=FAIL,compliance.openshift.io/check-severity=high'

NAME                                                           STATUS   SEVERITY
nist-moderate-modified-master-configure-crypto-policy          FAIL     high
nist-moderate-modified-master-coreos-pti-kernel-argument       FAIL     high
nist-moderate-modified-master-disable-ctrlaltdel-burstaction   FAIL     high
nist-moderate-modified-master-disable-ctrlaltdel-reboot        FAIL     high
nist-moderate-modified-master-enable-fips-mode                 FAIL     high
nist-moderate-modified-master-no-empty-passwords               FAIL     high
nist-moderate-modified-master-selinux-state                    FAIL     high
nist-moderate-modified-worker-configure-crypto-policy          FAIL     high
nist-moderate-modified-worker-coreos-pti-kernel-argument       FAIL     high
nist-moderate-modified-worker-disable-ctrlaltdel-burstaction   FAIL     high
nist-moderate-modified-worker-disable-ctrlaltdel-reboot        FAIL     high
nist-moderate-modified-worker-enable-fips-mode                 FAIL     high
nist-moderate-modified-worker-no-empty-passwords               FAIL     high
nist-moderate-modified-worker-selinux-state                    FAIL     high
ocp4-moderate-configure-network-policies-namespaces            FAIL     high
ocp4-moderate-fips-mode-enabled-on-all-nodes                   FAIL     high

Dressez la liste de tous les contrôles défaillants qui doivent être corrigés manuellement :

$ oc get -n openshift-compliance compliancecheckresults \
-l 'compliance.openshift.io/check-status=FAIL,!compliance.openshift.io/automated-remediation'

Les étapes de remédiation manuelle sont généralement stockées dans l'attribut description de l'objet ComplianceCheckResult.

Examinez l'objet ComplianceRemediation et l'objet ComplianceCheckResult qui possède la remédiation. L'objet ComplianceCheckResult contient des descriptions lisibles par l'homme de ce que fait le contrôle et du durcissement qu'il tente d'empêcher, ainsi que d'autres informations metadata telles que la gravité et les contrôles de sécurité associés. L'objet ComplianceRemediation représente un moyen de résoudre le problème décrit dans l'objet ComplianceCheckResult. Après la première analyse, vérifiez les mesures correctives avec l'état MissingDependencies.

Vous trouverez ci-dessous un exemple de contrôle et de remédiation appelé sysctl-net-ipv4-conf-all-accept-redirects. Cet exemple est expurgé pour ne montrer que spec et status et omet metadata:

spec:
  apply: false
  current:
  object:
    apiVersion: machineconfiguration.openshift.io/v1
    kind: MachineConfig
    spec:
      config:
        ignition:
          version: 3.2.0
        storage:
          files:
            - path: /etc/sysctl.d/75-sysctl_net_ipv4_conf_all_accept_redirects.conf
              mode: 0644
              contents:
                source: data:,net.ipv4.conf.all.accept_redirects%3D0
  outdated: {}
status:
  applicationState: NotApplied

Le payload de la remédiation est stocké dans l'attribut spec.current. Le payload peut être n'importe quel objet Kubernetes, mais comme cette remédiation a été produite par un scan de nœud, le payload de remédiation dans l'exemple ci-dessus est un objet MachineConfig. Pour les analyses de plateforme, la charge utile de la remédiation est souvent un autre type d'objet (par exemple, un objet ConfigMap ou Secret ), mais l'application de cette remédiation est généralement du ressort de l'administrateur, car sinon l'opérateur de conformité aurait eu besoin d'un ensemble très large de permissions pour manipuler n'importe quel objet Kubernetes générique. Un exemple de remédiation d'un contrôle de plateforme est fourni plus loin dans le texte.

Pour voir exactement ce que fait la remédiation lorsqu'elle est appliquée, le contenu de l'objet MachineConfig utilise les objets Ignition pour la configuration. Voir la spécification Ignition pour plus d'informations sur le format. Dans notre exemple, l'attribut the spec.config.storage.files[0].path spécifie le fichier créé par cette remédiation (/etc/sysctl.d/75-sysctl_net_ipv4_conf_all_accept_redirects.conf) et l'attribut spec.config.storage.files[0].contents.source spécifie le contenu de ce fichier.

Utilisez le script Python suivant pour afficher le contenu :

$ echo "net.ipv4.conf.all.accept_redirects%3D0" | python3 -c "import sys, urllib.parse; print(urllib.parse.unquote(''.join(sys.stdin.readlines())))"

net.ipv4.conf.all.accept_redirects=0

Lorsque vous créez une MachineConfigPool personnalisée, ajoutez une étiquette à la MachineConfigPool afin que la machineConfigPoolSelector présente dans la KubeletConfig puisse faire correspondre l'étiquette à la MachineConfigPool.

L'infrastructure d'OpenShift Container Platform peut contenir des fichiers de configuration incomplets au moment de l'exécution, et les nœuds supposent des valeurs de configuration par défaut pour les options de configuration manquantes. Certaines options de configuration peuvent être transmises en tant qu'arguments de ligne de commande. Par conséquent, l'opérateur de conformité ne peut pas vérifier si le fichier de configuration sur le nœud est complet car il peut manquer des options utilisées dans les vérifications de règles.

Pour éviter les résultats faussement négatifs lorsque la valeur de configuration par défaut passe le contrôle, l'opérateur de conformité utilise l'API Node/Proxy pour récupérer la configuration de chaque nœud d'un groupe de nœuds, puis toutes les options de configuration qui sont cohérentes entre les nœuds du groupe de nœuds sont stockées dans un fichier qui représente la configuration de tous les nœuds de ce groupe de nœuds. Cela permet d'améliorer la précision des résultats de l'analyse.

Aucune modification supplémentaire de la configuration n'est nécessaire pour utiliser cette fonction avec les configurations par défaut des pools de nœuds master et worker.

L'opérateur de conformité ne conserve pas de copie de la configuration de chaque groupe de nœuds. Il regroupe les options de configuration cohérentes pour tous les nœuds d'un pool de nœuds unique dans une copie du fichier de configuration. L'opérateur de conformité utilise ensuite le fichier de configuration pour un groupe de nœuds particulier afin d'évaluer les règles applicables aux nœuds de ce groupe.

Si votre cluster utilise des pools de nœuds personnalisés en dehors des pools de nœuds par défaut worker et master, vous devez fournir des variables supplémentaires pour que l'Opérateur de Conformité agrège un fichier de configuration pour ce pool de nœuds.

L'opérateur de conformité vérifie la version d'exécution KubeletConfig à l'aide de l'objet API Node/Proxy et utilise ensuite des variables telles que ocp-var-role-master et ocp-var-role-worker pour déterminer les nœuds sur lesquels il effectue le contrôle. Sur le site ComplianceCheckResult, les règles KubeletConfig sont affichées sous la forme ocp4-cis-kubelet-*. L'analyse n'est réussie que si tous les nœuds sélectionnés passent cette vérification.

KubeletConfig des étiquettes de remédiation peuvent être appliquées aux sous-pools de MachineConfigPool.

L'attribut booléen spec.apply contrôle si la remédiation doit être appliquée par l'opérateur de conformité. Vous pouvez appliquer la remédiation en définissant l'attribut sur true:

$ oc -n openshift-compliance \
patch complianceremediations/<scan-name>-sysctl-net-ipv4-conf-all-accept-redirects \
--patch '{"spec":{"apply":true}}' --type=merge

Une fois que l'opérateur de conformité a traité la correction appliquée, l'attribut status.ApplicationState devient Applied ou Error s'il est incorrect. Lorsqu'une remédiation de la configuration de la machine est appliquée, cette remédiation ainsi que toutes les autres remédiations appliquées sont rendues dans un objet MachineConfig nommé 75-$scan-name-$suite-name. Cet objet MachineConfig est ensuite rendu par l'opérateur de configuration de machine et finalement appliqué à tous les nœuds d'un pool de configuration de machine par une instance du démon de contrôle de machine s'exécutant sur chaque nœud.

Notez que lorsque l'opérateur de configuration des machines applique un nouvel objet MachineConfig aux nœuds d'un pool, tous les nœuds appartenant au pool sont redémarrés. Cela peut s'avérer gênant lors de l'application de plusieurs remédiations, chacune d'entre elles restituant l'objet composite 75-$scan-name-$suite-name MachineConfig . Pour éviter d'appliquer la remédiation immédiatement, vous pouvez mettre en pause le pool de configuration de machines en définissant l'attribut .spec.paused d'un objet MachineConfigPool sur true.

L'opérateur de conformité peut appliquer des remédiations automatiquement. Définissez autoApplyRemediations: true dans l'objet de premier niveau ScanSetting.

Les contrôles des analyses de la plate-forme doivent généralement être effectués manuellement par l'administrateur, et ce pour deux raisons :

Lorsqu'une nouvelle version du contenu de conformité est utilisée, elle peut fournir une version nouvelle et différente d'une remédiation par rapport à la version précédente. L'opérateur de conformité conservera l'ancienne version de la remédiation appliquée. L'administrateur d'OpenShift Container Platform est également notifié de la nouvelle version à réviser et à appliquer. Un objet ComplianceRemediation qui avait été appliqué précédemment, mais qui a été mis à jour, change de statut et devient Outdated. Les objets obsolètes sont étiquetés de manière à pouvoir être recherchés facilement.

Le contenu de la remédiation précédemment appliquée serait alors stocké dans l'attribut spec.outdated d'un objet ComplianceRemediation et le nouveau contenu mis à jour serait stocké dans l'attribut spec.current. Après avoir mis à jour le contenu vers une version plus récente, l'administrateur doit alors revoir la remédiation. Tant que l'attribut spec.outdated existe, il est utilisé pour rendre l'objet MachineConfig résultant. Une fois l'attribut spec.outdated supprimé, l'opérateur de conformité rend à nouveau l'objet MachineConfig qui en résulte, ce qui l'amène à pousser la configuration vers les nœuds.

Il peut être nécessaire d'annuler une mesure corrective déjà appliquée.

KubeletConfig sont incluses dans les profils au niveau des nœuds. Pour supprimer une remédiation KubeletConfig, vous devez la supprimer manuellement des objets KubeletConfig. Cet exemple montre comment supprimer le contrôle de conformité pour la remédiation one-rule-tp-node-master-kubelet-eviction-thresholds-set-hard-imagefs-available.

L'objet ScanSetting répertorie les rôles de nœuds que les analyses de conformité générées à partir des objets ScanSetting ou ScanSettingBinding doivent analyser. Chaque rôle de nœud correspond généralement à un pool de configuration de machine.

Si certains résultats sont différents des autres, l'opérateur de conformité signale un objet ComplianceCheckResult dont certains nœuds seront signalés comme étant INCONSISTENT. Tous les objets ComplianceCheckResult sont également étiquetés avec compliance.openshift.io/inconsistent-check.

Comme le nombre de machines dans un pool peut être très important, l'opérateur de conformité tente de trouver l'état le plus courant et de dresser la liste des nœuds qui diffèrent de l'état courant. L'état le plus courant est stocké dans l'annotation compliance.openshift.io/most-common-status et l'annotation compliance.openshift.io/inconsistent-source contient des paires de hostname:status d'états de contrôle qui diffèrent de l'état le plus courant. Si aucun état commun ne peut être trouvé, toutes les paires hostname:status sont répertoriées dans l'annotation compliance.openshift.io/inconsistent-source annotation.

Si possible, une remédiation est encore créée afin que le cluster puisse converger vers un statut conforme. Cependant, cela n'est pas toujours possible et la correction de la différence entre les nœuds doit être effectuée manuellement. L'analyse de conformité doit être réexécutée pour obtenir un résultat cohérent en annotant l'analyse avec l'option compliance.openshift.io/rescan=:

$ oc -n openshift-compliance \
annotate compliancescans/rhcos4-e8-worker compliance.openshift.io/rescan=