5.12. Dépannage de l'opérateur de conformité
Cette section décrit comment dépanner l'Opérateur de Conformité. Les informations peuvent être utiles pour diagnostiquer un problème ou pour fournir des informations dans un rapport de bogue. Quelques conseils généraux :
L'opérateur de conformité émet des événements Kubernetes lorsque quelque chose d'important se produit. Vous pouvez afficher tous les événements dans le cluster à l'aide de la commande :
$ oc get events -n openshift-compliance
Vous pouvez également afficher les événements d'un objet tel qu'un balayage à l'aide de la commande :
$ oc describe -n openshift-compliance compliancescan/cis-compliance
L'opérateur de conformité se compose de plusieurs contrôleurs, environ un par objet API. Il pourrait être utile de filtrer uniquement les contrôleurs qui correspondent à l'objet API qui pose problème. Si un
ComplianceRemediationne peut pas être appliqué, affichez les messages du contrôleurremediationctrl. Vous pouvez filtrer les messages d'un seul contrôleur en les analysant avecjq:$ oc -n openshift-compliance logs compliance-operator-775d7bddbd-gj58f \ | jq -c 'select(.logger == "profilebundlectrl")'Les horodatages sont enregistrés en secondes depuis l'époque UNIX en UTC. Pour les convertir en une date lisible par l'homme, utilisez
date -d @timestamp --utc, par exemple :$ date -d @1596184628.955853 --utc
-
De nombreuses ressources personnalisées, notamment
ComplianceSuiteetScanSetting, permettent de définir l'optiondebug. L'activation de cette option augmente la verbosité des pods d'analyse OpenSCAP, ainsi que d'autres pods d'aide. -
Si une seule règle réussit ou échoue de manière inattendue, il peut être utile d'exécuter un seul balayage ou une suite avec uniquement cette règle pour trouver l'ID de la règle à partir de l'objet
ComplianceCheckResultcorrespondant et l'utiliser comme valeur d'attributruledans un CRScan. Ensuite, avec l'optiondebugactivée, les journaux du conteneurscannerdans le pod scanner montreraient les journaux bruts d'OpenSCAP.
5.12.1. Anatomie d'un scan
Les sections suivantes décrivent les composantes et les étapes de l'analyse de l'opérateur de conformité.
5.12.1.1. Sources de conformité
Le contenu de la conformité est stocké dans des objets Profile générés à partir d'un objet ProfileBundle. L'opérateur de conformité crée un objet ProfileBundle pour le cluster et un autre pour les nœuds du cluster.
$ oc get -n openshift-compliance profilebundle.compliance
$ oc get -n openshift-compliance profile.compliance
Les objets ProfileBundle sont traités par les déploiements portant le nom Bundle. Pour résoudre un problème avec Bundle, vous pouvez trouver le déploiement et consulter les journaux des pods dans un déploiement :
$ oc logs -n openshift-compliance -lprofile-bundle=ocp4 -c profileparser
$ oc get -n openshift-compliance deployments,pods -lprofile-bundle=ocp4
$ oc logs -n openshift-compliance pods/<pod-name>
oc describe -n openshift-compliance pod/<pod-name> -c profileparser
5.12.1.2. Cycle de vie des objets ScanSetting et ScanSettingBinding et débogage
Avec des sources de contenu de conformité valides, les objets de haut niveau ScanSetting et ScanSettingBinding peuvent être utilisés pour générer des objets ComplianceSuite et ComplianceScan:
apiVersion: compliance.openshift.io/v1alpha1
kind: ScanSetting
metadata:
name: my-companys-constraints
debug: true
# For each role, a separate scan will be created pointing
# to a node-role specified in roles
roles:
- worker
---
apiVersion: compliance.openshift.io/v1alpha1
kind: ScanSettingBinding
metadata:
name: my-companys-compliance-requirements
profiles:
# Node checks
- name: rhcos4-e8
kind: Profile
apiGroup: compliance.openshift.io/v1alpha1
# Cluster checks
- name: ocp4-e8
kind: Profile
apiGroup: compliance.openshift.io/v1alpha1
settingsRef:
name: my-companys-constraints
kind: ScanSetting
apiGroup: compliance.openshift.io/v1alpha1
Les objets ScanSetting et ScanSettingBinding sont gérés par le même contrôleur étiqueté avec logger=scansettingbindingctrl. Ces objets n'ont pas de statut. Tout problème est communiqué sous la forme d'événements :
Events: Type Reason Age From Message ---- ------ ---- ---- ------- Normal SuiteCreated 9m52s scansettingbindingctrl ComplianceSuite openshift-compliance/my-companys-compliance-requirements created
Un objet ComplianceSuite est alors créé. Le flux continue à réconcilier l'objet nouvellement créé ComplianceSuite.
5.12.1.3. Cycle de vie et débogage des ressources personnalisées ComplianceSuite
Le CR ComplianceSuite est une enveloppe autour des CR ComplianceScan. Le CR ComplianceSuite est géré par le contrôleur étiqueté logger=suitectrl. Ce contrôleur s'occupe de créer des analyses à partir d'une suite, de réconcilier et d'agréger les états d'analyse individuels en un seul état de suite. Si une suite est définie pour être exécutée périodiquement, le contrôleur suitectrl gère également la création d'un CR CronJob qui ré-exécute les scans de la suite une fois l'exécution initiale terminée :
$ oc get cronjobs
Exemple de sortie
NAME SCHEDULE SUSPEND ACTIVE LAST SCHEDULE AGE <cron_name> 0 1 * * * False 0 <none> 151m
Pour les questions les plus importantes, des événements sont émis. Vous pouvez les visualiser à l'aide de oc describe compliancesuites/<name>. Les objets Suite ont également une sous-ressource Status qui est mise à jour lorsque l'un des objets Scan appartenant à cette suite met à jour sa sous-ressource Status. Une fois que tous les scans prévus ont été créés, le contrôle est transmis au contrôleur de scan.
5.12.1.4. Cycle de vie et débogage des ressources personnalisées ComplianceScan
Les CR ComplianceScan sont gérés par le contrôleur scanctrl. C'est également là que se déroulent les balayages proprement dits et que sont créés les résultats de ces balayages. Chaque analyse passe par plusieurs phases :
5.12.1.4.1. Phase d'attente
L'exactitude de l'analyse est validée au cours de cette phase. Si certains paramètres, tels que la taille de stockage, ne sont pas valides, l'analyse passe à la phase DONE avec un résultat ERROR, sinon elle passe à la phase Launching.
5.12.1.4.2. Phase de lancement
Dans cette phase, plusieurs cartes de configuration contiennent soit l'environnement pour les modules d'analyse, soit directement le script que les modules d'analyse évalueront. Dressez la liste des cartes de configuration :
$ oc -n openshift-compliance get cm \ -l compliance.openshift.io/scan-name=rhcos4-e8-worker,complianceoperator.openshift.io/scan-script=
Ces cartes de configuration seront utilisées par les pods de l'analyseur. Si vous avez besoin de modifier le comportement du scanner, de changer le niveau de débogage du scanner ou d'imprimer les résultats bruts, vous pouvez modifier les cartes de configuration. Ensuite, un volume persistant est créé pour chaque analyse afin de stocker les résultats bruts de l'ARF :
$ oc get pvc -n openshift-compliance -lcompliance.openshift.io/scan-name=rhcos4-e8-worker
Les PVC sont montés par un déploiement par scanner ResultServer. Le site ResultServer est un simple serveur HTTP sur lequel les différents pods scanners téléchargent les résultats complets de l'ARF. Chaque serveur peut fonctionner sur un nœud différent. Les résultats complets de l'ARF peuvent être très volumineux et vous ne pouvez pas supposer qu'il serait possible de créer un volume qui pourrait être monté à partir de plusieurs nœuds en même temps. Une fois l'analyse terminée, le déploiement de ResultServer est réduit. Le PVC contenant les résultats bruts peut être monté à partir d'un autre pod personnalisé et les résultats peuvent être récupérés ou inspectés. Le trafic entre les modules d'analyse et le site ResultServer est protégé par des protocoles TLS mutuels.
Enfin, les modules d'analyse sont lancés au cours de cette phase : un module d'analyse pour une instance d'analyse Platform et un module d'analyse par nœud correspondant pour une instance d'analyse node. Les modules par nœud sont étiquetés avec le nom du nœud. Chaque module est toujours étiqueté avec le nom ComplianceScan:
$ oc get pods -lcompliance.openshift.io/scan-name=rhcos4-e8-worker,workload=scanner --show-labels
Exemple de sortie
NAME READY STATUS RESTARTS AGE LABELS rhcos4-e8-worker-ip-10-0-169-90.eu-north-1.compute.internal-pod 0/2 Completed 0 39m compliance.openshift.io/scan-name=rhcos4-e8-worker,targetNode=ip-10-0-169-90.eu-north-1.compute.internal,workload=scanner
L'analyse passe ensuite à la phase d'exécution.
5.12.1.4.3. Phase d'exécution
La phase d'exécution attend que les modules d'analyse se terminent. Les termes et processus suivants sont utilisés dans la phase d'exécution :
-
init container: Il existe un conteneur init appelé
content-container. Il lance le conteneur contentImage et exécute une commande unique qui copie le conteneur contentFile dans le répertoire/contentpartagé avec les autres conteneurs de ce pod. -
scanner: Ce conteneur exécute l'analyse. Pour les analyses de nœuds, le conteneur monte le système de fichiers du nœud en tant que
/hostet monte le contenu fourni par le conteneur init. Le conteneur monte également leentrypointConfigMapcréé dans la phase de lancement et l'exécute. Le script par défaut dans le point d'entréeConfigMapexécute OpenSCAP et stocke les fichiers de résultats dans le répertoire/resultspartagé entre les conteneurs du pod. Les journaux de ce module peuvent être consultés pour déterminer ce que l'analyseur OpenSCAP a vérifié. Une sortie plus verbeuse peut être visualisée avec l'optiondebug. logcollector: Le conteneur logcollector attend que le conteneur scanner se termine. Ensuite, il télécharge les résultats ARF complets sur le site
ResultServeret télécharge séparément les résultats XCCDF avec le résultat de l'analyse et le code de résultat OpenSCAP en tant queConfigMap.. Ces cartes de configuration des résultats sont étiquetées avec le nom de l'analyse (compliance.openshift.io/scan-name=rhcos4-e8-worker) :$ oc describe cm/rhcos4-e8-worker-ip-10-0-169-90.eu-north-1.compute.internal-pod
Exemple de sortie
Name: rhcos4-e8-worker-ip-10-0-169-90.eu-north-1.compute.internal-pod Namespace: openshift-compliance Labels: compliance.openshift.io/scan-name-scan=rhcos4-e8-worker complianceoperator.openshift.io/scan-result= Annotations: compliance-remediations/processed: compliance.openshift.io/scan-error-msg: compliance.openshift.io/scan-result: NON-COMPLIANT OpenSCAP-scan-result/node: ip-10-0-169-90.eu-north-1.compute.internal Data ==== exit-code: ---- 2 results: ---- <?xml version="1.0" encoding="UTF-8"?> ...
Les nacelles des scanners Platform sont similaires, à l'exception de ce qui suit :
-
Il existe un conteneur init supplémentaire appelé
api-resource-collectorqui lit le contenu OpenSCAP fourni par le conteneur init content-container, détermine les ressources API que le contenu doit examiner et stocke ces ressources API dans un répertoire partagé où le conteneurscannerles lira. -
Le conteneur
scannern'a pas besoin de monter le système de fichiers de l'hôte.
Lorsque les modules d'analyse sont terminés, les analyses passent à la phase d'agrégation.
5.12.1.4.4. Phase d'agrégation
Dans la phase d'agrégation, le contrôleur d'analyse crée un autre pod appelé pod agrégateur. Son objectif est de prendre les objets ConfigMap, de lire les résultats et de créer l'objet Kubernetes correspondant pour chaque résultat de contrôle. Si l'échec du contrôle peut être corrigé automatiquement, un objet ComplianceRemediation est créé. Pour fournir des métadonnées lisibles par l'homme pour les contrôles et les remédiations, le pod agrégateur monte également le contenu OpenSCAP à l'aide d'un conteneur init.
Lorsqu'une carte de configuration est traitée par un pod agrégateur, elle reçoit l'étiquette compliance-remediations/processed. Le résultat de cette phase est constitué d'objets ComplianceCheckResult:
$ oc get compliancecheckresults -lcompliance.openshift.io/scan-name=rhcos4-e8-worker
Exemple de sortie
NAME STATUS SEVERITY rhcos4-e8-worker-accounts-no-uid-except-zero PASS high rhcos4-e8-worker-audit-rules-dac-modification-chmod FAIL medium
et ComplianceRemediation:
$ oc get complianceremediations -lcompliance.openshift.io/scan-name=rhcos4-e8-worker
Exemple de sortie
NAME STATE rhcos4-e8-worker-audit-rules-dac-modification-chmod NotApplied rhcos4-e8-worker-audit-rules-dac-modification-chown NotApplied rhcos4-e8-worker-audit-rules-execution-chcon NotApplied rhcos4-e8-worker-audit-rules-execution-restorecon NotApplied rhcos4-e8-worker-audit-rules-execution-semanage NotApplied rhcos4-e8-worker-audit-rules-execution-setfiles NotApplied
Une fois ces CR créés, le pod agrégateur se retire et l'analyse passe à la phase Terminé.
5.12.1.4.5. Phase terminée
Lors de la phase finale de l'analyse, les ressources de l'analyse sont nettoyées si nécessaire et le déploiement de ResultServer est soit réduit (si l'analyse est ponctuelle), soit supprimé si l'analyse est continue ; l'instance d'analyse suivante recréera alors le déploiement.
Il est également possible de déclencher une nouvelle exécution d'une analyse dans la phase Terminé en l'annotant :
$ oc -n openshift-compliance \ annotate compliancescans/rhcos4-e8-worker compliance.openshift.io/rescan=
Une fois que l'analyse a atteint la phase Done, rien d'autre ne se produit, sauf si les remédiations sont définies pour être appliquées automatiquement à l'aide de autoApplyRemediations: true. L'administrateur d'OpenShift Container Platform doit alors examiner les remédiations et les appliquer si nécessaire. Si les remédiations sont définies pour être appliquées automatiquement, le contrôleur ComplianceSuite prend le relais dans la phase Done, met en pause le pool de configuration de machines auquel l'analyse est liée et applique toutes les remédiations en une seule fois. Si une correction est appliquée, le contrôleur ComplianceRemediation prend le relais.
5.12.1.5. ConformitéRemédiation Cycle de vie du contrôleur et débogage
L'analyse de l'exemple a fait état de certaines découvertes. L'une des mesures correctives peut être activée en faisant passer son attribut apply à true:
$ oc patch complianceremediations/rhcos4-e8-worker-audit-rules-dac-modification-chmod --patch '{"spec":{"apply":true}}' --type=merge
Le contrôleur ComplianceRemediation (logger=remediationctrl) réconcilie l'objet modifié. Le résultat du rapprochement est un changement de statut de l'objet de remédiation qui est rapproché, mais aussi un changement de l'objet rendu par suite MachineConfig qui contient toutes les remédiations appliquées.
L'objet MachineConfig commence toujours par 75- et porte le nom de l'analyse et de la suite :
$ oc get mc | grep 75-
Exemple de sortie
75-rhcos4-e8-worker-my-companys-compliance-requirements 3.2.0 2m46s
Les remédiations dont se compose actuellement le site mc sont répertoriées dans les annotations de la configuration de la machine :
$ oc describe mc/75-rhcos4-e8-worker-my-companys-compliance-requirements
Exemple de sortie
Name: 75-rhcos4-e8-worker-my-companys-compliance-requirements Labels: machineconfiguration.openshift.io/role=worker Annotations: remediation/rhcos4-e8-worker-audit-rules-dac-modification-chmod:
L'algorithme du contrôleur ComplianceRemediation fonctionne comme suit :
- Toutes les remédiations actuellement appliquées sont lues dans un ensemble de remédiations initial.
- Si la mesure corrective réconciliée est censée être appliquée, elle est ajoutée à l'ensemble.
-
Un objet
MachineConfigest rendu à partir de l'ensemble et annoté avec les noms des remédiations de l'ensemble. Si l'ensemble est vide (la dernière mesure corrective n'a pas été appliquée), l'objetMachineConfigrendu est supprimé. - Si et seulement si la configuration de la machine rendue est différente de celle déjà appliquée dans le cluster, la MC appliquée est mise à jour (ou créée, ou supprimée).
-
La création ou la modification d'un objet
MachineConfigdéclenche un redémarrage des nœuds correspondant à l'étiquettemachineconfiguration.openshift.io/role- voir la documentation Machine Config Operator pour plus de détails.
La boucle de remédiation se termine une fois que la configuration de la machine rendue est mise à jour, si nécessaire, et que le statut de l'objet de remédiation réconcilié est mis à jour. Dans notre cas, l'application de la remédiation déclencherait un redémarrage. Après le redémarrage, annotez l'analyse pour la réexécuter :
$ oc -n openshift-compliance \ annotate compliancescans/rhcos4-e8-worker compliance.openshift.io/rescan=
L'analyse s'exécute et se termine. Vérifiez que la remédiation est réussie :
$ oc -n openshift-compliance \ get compliancecheckresults/rhcos4-e8-worker-audit-rules-dac-modification-chmod
Exemple de sortie
NAME STATUS SEVERITY rhcos4-e8-worker-audit-rules-dac-modification-chmod PASS medium
5.12.1.6. Étiquettes utiles
Chaque module créé par l'opérateur de conformité porte une étiquette spécifique indiquant l'analyse à laquelle il appartient et le travail qu'il effectue. L'identifiant de l'analyse porte l'étiquette compliance.openshift.io/scan-name. L'identifiant de la charge de travail porte l'étiquette workload.
L'opérateur de conformité planifie les charges de travail suivantes :
- scanner: Effectue l'analyse de conformité.
- resultserver: Enregistre les résultats bruts de l'analyse de conformité.
- aggregator: Agrége les résultats, détecte les incohérences et produit des objets de résultat (résultats de contrôle et remédiations).
- suitererunner: Marque une suite pour qu'elle soit exécutée à nouveau (lorsqu'un calendrier est défini).
- profileparser: Analyse un flux de données et crée les profils, règles et variables appropriés.
Lorsque le débogage et les journaux sont nécessaires pour une certaine charge de travail, exécutez :
oc logs -l workload=<workload_name> -c <container_name>
5.12.2. Augmentation des limites de ressources de l'opérateur de conformité
Dans certains cas, l'opérateur de conformité peut avoir besoin de plus de mémoire que les limites par défaut ne le permettent. La meilleure façon de résoudre ce problème est de définir des limites de ressources personnalisées.
Pour augmenter les limites par défaut de la mémoire et de l'unité centrale des modules de numérisation, voir `ScanSetting` Custom resource.
Procédure
Pour augmenter les limites de mémoire de l'opérateur à 500 Mi, créez le fichier patch suivant, nommé
co-memlimit-patch.yaml:spec: config: resources: limits: memory: 500MiAppliquer le fichier patch :
$ oc patch sub compliance-operator -nopenshift-compliance --patch-file co-memlimit-patch.yaml --type=merge
5.12.3. Configuration des contraintes de ressources de l'opérateur
Le champ resources définit les contraintes de ressources pour tous les conteneurs du pod créé par l'Operator Lifecycle Manager (OLM).
Les contraintes de ressources appliquées au cours de ce processus remplacent les contraintes de ressources existantes.
Procédure
Injecter une demande de 0,25 cpu et 64 Mi de mémoire, et une limite de 0,5 cpu et 128 Mi de mémoire dans chaque conteneur en éditant l'objet
Subscription:kind: Subscription metadata: name: custom-operator spec: package: etcd channel: alpha config: resources: requests: memory: "64Mi" cpu: "250m" limits: memory: "128Mi" cpu: "500m"
5.12.4. Configuration du délai d'attente de ScanSetting
L'objet ScanSetting dispose d'une option de délai qui peut être spécifiée dans l'objet ComplianceScanSetting sous la forme d'une chaîne de durée, telle que 1h30m. Si l'analyse n'est pas terminée dans le délai spécifié, elle recommence jusqu'à ce que la limite de maxRetryOnTimeout soit atteinte.
Procédure
Pour définir un
timeoutet unmaxRetryOnTimeoutdans ScanSetting, modifiez un objetScanSettingexistant :apiVersion: compliance.openshift.io/v1alpha1 kind: ScanSetting metadata: name: default namespace: openshift-compliance rawResultStorage: rotation: 3 size: 1Gi roles: - worker - master scanTolerations: - effect: NoSchedule key: node-role.kubernetes.io/master operator: Exists schedule: '0 1 * * *' timeout: '10m0s' 1 maxRetryOnTimeout: 3 2
5.12.5. Obtenir de l'aide
Si vous rencontrez des difficultés avec une procédure décrite dans cette documentation, ou avec OpenShift Container Platform en général, visitez le portail client de Red Hat. À partir du portail client, vous pouvez :
- Recherchez ou parcourez la base de connaissances de Red Hat qui contient des articles et des solutions relatifs aux produits Red Hat.
- Soumettre un cas d'assistance à Red Hat Support.
- Accéder à d'autres documents sur les produits.
Pour identifier les problèmes liés à votre cluster, vous pouvez utiliser Insights dans OpenShift Cluster Manager Hybrid Cloud Console. Insights fournit des détails sur les problèmes et, le cas échéant, des informations sur la manière de les résoudre.
Si vous avez une suggestion pour améliorer cette documentation ou si vous avez trouvé une erreur, soumettez un problème Jira pour le composant de documentation le plus pertinent. Veuillez fournir des détails spécifiques, tels que le nom de la section et la version d'OpenShift Container Platform.
