Red Hat Summit Red Hat SummitSupportConsoleDéveloppeursCommencer un essaiContact

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

Chaque ComplianceCheckResult représente le résultat d'un contrôle de la règle de conformité. Si la règle peut être corrigée automatiquement, un objet ComplianceRemediation portant le même nom et appartenant à ComplianceCheckResult est créé. Sauf demande, les remédiations ne sont pas appliquées automatiquement, ce qui donne à l'administrateur d'OpenShift Container Platform la possibilité d'examiner ce que fait la remédiation et de n'appliquer une remédiation qu'une fois qu'elle a été vérifiée.

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
Copy to Clipboard Toggle word wrap

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

$ oc get -n openshift-compliance compliancecheckresults \
-l compliance.openshift.io/scan=workers-scan
Copy to Clipboard Toggle word wrap

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'
Copy to Clipboard Toggle word wrap

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'
Copy to Clipboard Toggle word wrap

Exemple de sortie

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
Copy to Clipboard Toggle word wrap

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'
Copy to Clipboard Toggle word wrap

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

Expand
Tableau 5.3. Statut du résultat du contrôle de conformité
Statut du résultat du contrôle de conformitéDescription

PASSER

Le contrôle de conformité s'est déroulé jusqu'à son terme et s'est avéré concluant.

ÉCHEC

Le contrôle de conformité s'est déroulé jusqu'à son terme et a échoué.

INFO

Le contrôle de conformité s'est déroulé jusqu'à son terme et a révélé un problème qui n'est pas suffisamment grave pour être considéré comme une erreur.

MANUEL

Le contrôle de conformité n'a pas de moyen d'évaluer automatiquement le succès ou l'échec et doit être vérifié manuellement.

INCONSISTANT

Le contrôle de conformité signale différents résultats provenant de différentes sources, généralement des nœuds de cluster.

ERREUR

Le contrôle de conformité a été exécuté, mais n'a pas pu se terminer correctement.

NON-APPLICABLE

Le contrôle de conformité n'a pas été exécuté parce qu'il n'est pas applicable ou n'est pas sélectionné.

5.10.2. Révision d'une mesure corrective
Copier lien

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
Copy to Clipboard Toggle word wrap

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.

Note

Le contenu des fichiers est codé en URL.

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())))"
Copy to Clipboard Toggle word wrap

Exemple de sortie

net.ipv4.conf.all.accept_redirects=0
Copy to Clipboard Toggle word wrap

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.

Important

Ne définissez pas protectKernelDefaults: false dans le fichier KubeletConfig, car l'objet MachineConfigPool pourrait ne pas se débloquer de manière inattendue une fois que l'opérateur de conformité a fini d'appliquer la remédiation.

Procédure

  1. Dresser la liste des nœuds. 

    $ oc get nodes -n openshift-compliance
    Copy to Clipboard Toggle word wrap

    Exemple de sortie

    NAME                                       STATUS  ROLES  AGE    VERSION
ip-10-0-128-92.us-east-2.compute.internal  Ready   master 5h21m  v1.25.0
ip-10-0-158-32.us-east-2.compute.internal  Ready   worker 5h17m  v1.25.0
ip-10-0-166-81.us-east-2.compute.internal  Ready   worker 5h17m  v1.25.0
ip-10-0-171-170.us-east-2.compute.internal Ready   master 5h21m  v1.25.0
ip-10-0-197-35.us-east-2.compute.internal  Ready   master 5h22m  v1.25.0
    Copy to Clipboard Toggle word wrap

  2. Ajouter une étiquette aux nœuds. 

    $ oc -n openshift-compliance \
label node ip-10-0-166-81.us-east-2.compute.internal \
node-role.kubernetes.io/<machine_config_pool_name>=
    Copy to Clipboard Toggle word wrap

    Exemple de sortie

    node/ip-10-0-166-81.us-east-2.compute.internal labeled
    Copy to Clipboard Toggle word wrap

  3. Créer des MachineConfigPool CR personnalisés. 

    apiVersion: machineconfiguration.openshift.io/v1
kind: MachineConfigPool
metadata:
  name: <machine_config_pool_name>
  labels:
    pools.operator.machineconfiguration.openshift.io/<machine_config_pool_name>: ''
    1 
    
spec:
  machineConfigSelector:
  matchExpressions:
  - {key: machineconfiguration.openshift.io/role, operator: In, values: [worker,<machine_config_pool_name>]}
  nodeSelector:
  matchLabels:
    node-role.kubernetes.io/<machine_config_pool_name>: ""
    Copy to Clipboard Toggle word wrap
    1
    Le champ labels définit le nom de l'étiquette à ajouter pour le pool de configuration de la machine (MCP).

  4. Vérifier que le MCP a été créé avec succès. 

    $ oc get mcp -w
    Copy to Clipboard Toggle word wrap

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.

5.10.5. Analyse des pools de nœuds personnalisés
Copier lien

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.

Procédure

  1. Pour vérifier la configuration par rapport à tous les pools d'un exemple de cluster contenant les pools de nœuds master, worker et example personnalisé, définissez la valeur des champs ocp-var-role-master et opc-var-role-worker sur example dans l'objet TailoredProfile: 

    apiVersion: compliance.openshift.io/v1alpha1
kind: TailoredProfile
metadata:
  name: cis-example-tp
spec:
  extends: ocp4-cis
  title: My modified NIST profile to scan example nodes
  setValues:
  - name: ocp4-var-role-master
    value: example
    rationale: test for example nodes
  - name: ocp4-var-role-worker
    value: example
    rationale: test for example nodes
  description: cis-example-scan
    Copy to Clipboard Toggle word wrap

  2. Ajoutez le rôle example à l'objet ScanSetting qui sera stocké dans le CR ScanSettingBinding: 

    apiVersion: compliance.openshift.io/v1alpha1
kind: ScanSetting
metadata:
  name: default
  namespace: openshift-compliance
rawResultStorage:
  rotation: 3
  size: 1Gi
roles:
- worker
- master
- example
scanTolerations:
- effect: NoSchedule
  key: node-role.kubernetes.io/master
  operator: Exists
schedule: '0 1 * * *'
    Copy to Clipboard Toggle word wrap

  3. Créez un scan qui utilise le ScanSettingBinding CR : 

    apiVersion: compliance.openshift.io/v1alpha1
kind: ScanSettingBinding
metadata:
  name: cis
  namespace: openshift-compliance
profiles:
- apiGroup: compliance.openshift.io/v1alpha1
  kind: Profile
  name: ocp4-cis
- apiGroup: compliance.openshift.io/v1alpha1
  kind: Profile
  name: ocp4-cis-node
- apiGroup: compliance.openshift.io/v1alpha1
  kind: TailoredProfile
  name: cis-example-tp
settingsRef:
  apiGroup: compliance.openshift.io/v1alpha1
  kind: ScanSetting
  name: default
    Copy to Clipboard Toggle word wrap

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.

Vérification

  • Les règles de Platform KubeletConfig sont vérifiées par le biais de l'objet Node/Proxy. Vous pouvez trouver ces règles en exécutant la commande suivante : 

    $ oc get rules -o json | jq '.items[] | select(.checkType == "Platform") | select(.metadata.name | contains("ocp4-kubelet-")) | .metadata.name'
    Copy to Clipboard Toggle word wrap

5.10.6. Assainissement des sous-piscines KubeletConfig
Copier lien

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

Procédure

  • Ajouter une étiquette au sous-pool MachineConfigPool CR : 

    $ oc label mcp <sub-pool-name> pools.operator.machineconfiguration.openshift.io/<sub-pool-name>=
    Copy to Clipboard Toggle word wrap

5.10.7. Application d'une remédiation
Copier lien

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
Copy to Clipboard Toggle word wrap

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.

Note

Assurez-vous que les pools ne sont pas interrompus lorsque la rotation des certificats d'AC a lieu. Si les MCP sont en pause, le MCO ne peut pas envoyer les nouveaux certificats à ces nœuds. Cela entraîne la dégradation du cluster et l'échec de plusieurs commandes oc, notamment oc debug, oc logs, oc exec et oc attach. Vous recevez des alertes dans l'interface utilisateur d'alerte de la console Web d'OpenShift Container Platform si un MCP est mis en pause lors de la rotation des certificats.

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

Avertissement

L'application automatique de mesures correctives ne doit se faire qu'après mûre réflexion.

5.10.8. Remédier manuellement à un contrôle de plate-forme
Copier lien

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 :

  • Il n'est pas toujours possible de déterminer automatiquement la valeur qui doit être définie. L'un des contrôles exige qu'une liste des registres autorisés soit fournie, mais l'analyseur n'a aucun moyen de savoir quels registres l'organisation souhaite autoriser.
  • Différentes vérifications modifient différents objets API, ce qui nécessite une remédiation automatisée pour posséder root ou un accès superutilisateur pour modifier les objets dans le cluster, ce qui n'est pas conseillé.

Procédure

  1. L'exemple ci-dessous utilise la règle ocp4-ocp-allowed-registries-for-import, qui échouerait sur une installation par défaut d'OpenShift Container Platform. Inspectez la règle oc get rule.compliance/ocp4-ocp-allowed-registries-for-import -oyaml, qui limite les registres à partir desquels les utilisateurs sont autorisés à importer des images en définissant l'attribut allowedRegistriesForImport. L'attribut warning de la règle indique également l'objet API vérifié, de sorte qu'il peut être modifié et remédier au problème : 

    $ oc edit image.config.openshift.io/cluster
    Copy to Clipboard Toggle word wrap

    Exemple de sortie

    apiVersion: config.openshift.io/v1
kind: Image
metadata:
  annotations:
    release.openshift.io/create-only: "true"
  creationTimestamp: "2020-09-10T10:12:54Z"
  generation: 2
  name: cluster
  resourceVersion: "363096"
  selfLink: /apis/config.openshift.io/v1/images/cluster
  uid: 2dcb614e-2f8a-4a23-ba9a-8e33cd0ff77e
spec:
  allowedRegistriesForImport:
  - domainName: registry.redhat.io
status:
  externalRegistryHostnames:
  - default-route-openshift-image-registry.apps.user-cluster-09-10-12-07.devcluster.openshift.com
  internalRegistryHostname: image-registry.openshift-image-registry.svc:5000
    Copy to Clipboard Toggle word wrap

  2. Exécutez à nouveau l'analyse : 

    $ oc -n openshift-compliance \
annotate compliancescans/rhcos4-e8-worker compliance.openshift.io/rescan=
    Copy to Clipboard Toggle word wrap

5.10.9. Mise à jour des mesures correctives
Copier lien

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.

Procédure

  1. Recherchez les mesures correctives périmées : 

    $ oc -n openshift-compliance get complianceremediations \
-l complianceoperator.openshift.io/outdated-remediation=
    Copy to Clipboard Toggle word wrap

    Exemple de sortie

    NAME                              STATE
workers-scan-no-empty-passwords   Outdated
    Copy to Clipboard Toggle word wrap

    La remédiation actuellement appliquée est stockée dans l'attribut Outdated et la nouvelle remédiation non appliquée est stockée dans l'attribut Current. Si vous êtes satisfait de la nouvelle version, supprimez le champ Outdated. Si vous souhaitez conserver le contenu mis à jour, supprimez les attributs Current et Outdated.

  2. Appliquer la version la plus récente de la remédiation : 

    $ oc -n openshift-compliance patch complianceremediations workers-scan-no-empty-passwords \
--type json -p '[{"op":"remove", "path":/spec/outdated}]'
    Copy to Clipboard Toggle word wrap

  3. L'état de remédiation passera de Outdated à Applied: 

    $ oc get -n openshift-compliance complianceremediations workers-scan-no-empty-passwords
    Copy to Clipboard Toggle word wrap

    Exemple de sortie

    NAME                              STATE
workers-scan-no-empty-passwords   Applied
    Copy to Clipboard Toggle word wrap

  4. Les nœuds appliqueront la version de remédiation la plus récente et redémarreront.

5.10.10. Non-application d'une mesure corrective
Copier lien

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

Procédure

  1. Fixer le drapeau apply à false: 

    $ oc -n openshift-compliance \
patch complianceremediations/rhcos4-moderate-worker-sysctl-net-ipv4-conf-all-accept-redirects \
--patch '{"spec":{"apply":false}}' --type=merge
    Copy to Clipboard Toggle word wrap

  2. Le statut de l'assainissement passera à NotApplied et l'objet composite MachineConfig sera redessiné pour ne pas inclure l'assainissement.

    Important

    Tous les nœuds concernés par la remédiation seront redémarrés.

5.10.11. Suppression d'une remédiation KubeletConfig
Copier lien

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.

Procédure

  1. Localisez le site scan-name et vérifiez la conformité de l'assainissement du site one-rule-tp-node-master-kubelet-eviction-thresholds-set-hard-imagefs-available: 

    $ oc -n openshift-compliance get remediation \ one-rule-tp-node-master-kubelet-eviction-thresholds-set-hard-imagefs-available -o yaml
    Copy to Clipboard Toggle word wrap

    Exemple de sortie

    apiVersion: compliance.openshift.io/v1alpha1
kind: ComplianceRemediation
metadata:
  annotations:
    compliance.openshift.io/xccdf-value-used: var-kubelet-evictionhard-imagefs-available
  creationTimestamp: "2022-01-05T19:52:27Z"
  generation: 1
  labels:
    compliance.openshift.io/scan-name: one-rule-tp-node-master
    1 
    
    compliance.openshift.io/suite: one-rule-ssb-node
  name: one-rule-tp-node-master-kubelet-eviction-thresholds-set-hard-imagefs-available
  namespace: openshift-compliance
  ownerReferences:
  - apiVersion: compliance.openshift.io/v1alpha1
    blockOwnerDeletion: true
    controller: true
    kind: ComplianceCheckResult
    name: one-rule-tp-node-master-kubelet-eviction-thresholds-set-hard-imagefs-available
    uid: fe8e1577-9060-4c59-95b2-3e2c51709adc
  resourceVersion: "84820"
  uid: 5339d21a-24d7-40cb-84d2-7a2ebb015355
spec:
  apply: true
  current:
    object:
      apiVersion: machineconfiguration.openshift.io/v1
      kind: KubeletConfig
      spec:
        kubeletConfig:
          evictionHard:
            imagefs.available: 10%
    2 
    
  outdated: {}
  type: Configuration
status:
  applicationState: Applied
    Copy to Clipboard Toggle word wrap

    1
    Le nom de l'analyse de la remédiation.
    2
    La remédiation qui a été ajoutée aux objets KubeletConfig.
    Note

    Si la remédiation invoque une configuration kubelet evictionHard, vous devez spécifier tous les paramètres evictionHard: memory.available nodefs.available , nodefs.inodesFree, imagefs.available et imagefs.inodesFree. Si vous ne spécifiez pas tous les paramètres, seuls les paramètres spécifiés sont appliqués et la remédiation ne fonctionnera pas correctement.

  2. Retirer l'assainissement :

    1. Définir apply à false pour l'objet de remédiation : 

      $ oc -n openshift-compliance patch \
complianceremediations/one-rule-tp-node-master-kubelet-eviction-thresholds-set-hard-imagefs-available \
-p '{"spec":{"apply":false}}' --type=merge
      Copy to Clipboard Toggle word wrap

    2. A l'aide de scan-name, trouvez l'objet KubeletConfig auquel la remédiation a été appliquée : 

      $ oc -n openshift-compliance get kubeletconfig \
--selector compliance.openshift.io/scan-name=one-rule-tp-node-master
      Copy to Clipboard Toggle word wrap

      Exemple de sortie

      NAME                                 AGE
compliance-operator-kubelet-master   2m34s
      Copy to Clipboard Toggle word wrap

    3. Supprimez manuellement la remédiation, imagefs.available: 10%, de l'objet KubeletConfig: 

      $ oc edit -n openshift-compliance KubeletConfig compliance-operator-kubelet-master
      Copy to Clipboard Toggle word wrap
      Important

      Tous les nœuds concernés par la remédiation seront redémarrés.

Note

Vous devez également exclure la règle de toutes les analyses planifiées dans vos profils personnalisés qui appliquent automatiquement la correction, sinon la correction sera réappliquée lors de la prochaine analyse planifiée.

5.10.12. ComplianceScan incohérent
Copier lien

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.

Important

Il est prévu que toutes les machines d'un pool de configuration soient identiques et que tous les résultats d'analyse des nœuds d'un pool soient identiques.

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=
Copy to Clipboard Toggle word wrap
Retour au début
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. Découvrez nos récentes mises à jour.

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 le Blog 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.

Theme

© 2025 Red Hat