5.5. Opérateur de conformité scans
Les API ScanSetting et ScanSettingBinding sont recommandées pour exécuter des analyses de conformité avec l'opérateur de conformité. Pour plus d'informations sur ces objets API, exécutez :
$ oc explain scansettings
ou
$ oc explain scansettingbindings
5.5.1. Exécution d'analyses de conformité
Vous pouvez lancer une analyse à l'aide des profils du Center for Internet Security (CIS). Pour des raisons pratiques, l'Opérateur de Conformité crée un objet ScanSetting avec des valeurs par défaut raisonnables au démarrage. Cet objet ScanSetting est nommé default.
Pour les nœuds de plan de contrôle et de travailleur tout-en-un, l'analyse de conformité s'exécute deux fois sur les nœuds de plan de contrôle et de travailleur. L'analyse de conformité peut générer des résultats incohérents. Vous pouvez éviter les résultats incohérents en ne définissant qu'un seul rôle dans l'objet ScanSetting.
Procédure
Inspecter l'objet
ScanSettingen courant :$ oc describe scansettings default -n openshift-compliance
Exemple de sortie
Name: default Namespace: openshift-compliance Labels: <none> Annotations: <none> API Version: compliance.openshift.io/v1alpha1 Kind: ScanSetting Metadata: Creation Timestamp: 2022-10-10T14:07:29Z Generation: 1 Managed Fields: API Version: compliance.openshift.io/v1alpha1 Fields Type: FieldsV1 fieldsV1: f:rawResultStorage: .: f:nodeSelector: .: f:node-role.kubernetes.io/master: f:pvAccessModes: f:rotation: f:size: f:tolerations: f:roles: f:scanTolerations: f:schedule: f:showNotApplicable: f:strictNodeScan: Manager: compliance-operator Operation: Update Time: 2022-10-10T14:07:29Z Resource Version: 56111 UID: c21d1d14-3472-47d7-a450-b924287aec90 Raw Result Storage: Node Selector: node-role.kubernetes.io/master: Pv Access Modes: ReadWriteOnce 1 Rotation: 3 2 Size: 1Gi 3 Tolerations: Effect: NoSchedule Key: node-role.kubernetes.io/master Operator: Exists Effect: NoExecute Key: node.kubernetes.io/not-ready Operator: Exists Toleration Seconds: 300 Effect: NoExecute Key: node.kubernetes.io/unreachable Operator: Exists Toleration Seconds: 300 Effect: NoSchedule Key: node.kubernetes.io/memory-pressure Operator: Exists Roles: master 4 worker 5 Scan Tolerations: 6 Operator: Exists Schedule: 0 1 * * * 7 Show Not Applicable: false Strict Node Scan: true Events: <none>- 1
- L'opérateur de conformité crée un volume persistant (PV) qui contient les résultats des analyses. Par défaut, le PV utilisera le mode d'accès
ReadWriteOncecar l'opérateur de conformité ne peut pas faire d'hypothèses sur les classes de stockage configurées sur le cluster. De plus, le mode d'accèsReadWriteOnceest disponible sur la plupart des clusters. Si vous avez besoin de récupérer les résultats de l'analyse, vous pouvez le faire en utilisant un pod d'aide, qui lie également le volume. Les volumes qui utilisent le mode d'accèsReadWriteOncene peuvent être montés que par un seul pod à la fois, il est donc important de ne pas oublier de supprimer les pods d'assistance. Sinon, l'opérateur de conformité ne pourra pas réutiliser le volume pour les analyses suivantes. - 2
- L'opérateur de conformité conserve les résultats de trois balayages ultérieurs dans le volume ; les balayages plus anciens font l'objet d'une rotation.
- 3
- L'opérateur de conformité alloue un Go d'espace de stockage pour les résultats de l'analyse.
- 4 5
- Si le paramètre d'analyse utilise des profils qui analysent les nœuds de cluster, analysez ces rôles de nœuds.
- 6
- L'objet du paramètre d'analyse par défaut analyse tous les nœuds.
- 7
- L'objet du paramètre de balayage par défaut exécute des balayages à 01:00 chaque jour.
Pour remplacer le paramètre de numérisation par défaut, vous pouvez utiliser
default-auto-apply, dont les paramètres sont les suivants :Name: default-auto-apply Namespace: openshift-compliance Labels: <none> Annotations: <none> API Version: compliance.openshift.io/v1alpha1 Auto Apply Remediations: true Auto Update Remediations: true Kind: ScanSetting Metadata: Creation Timestamp: 2022-10-18T20:21:00Z Generation: 1 Managed Fields: API Version: compliance.openshift.io/v1alpha1 Fields Type: FieldsV1 fieldsV1: f:autoApplyRemediations: 1 f:autoUpdateRemediations: 2 f:rawResultStorage: .: f:nodeSelector: .: f:node-role.kubernetes.io/master: f:pvAccessModes: f:rotation: f:size: f:tolerations: f:roles: f:scanTolerations: f:schedule: f:showNotApplicable: f:strictNodeScan: Manager: compliance-operator Operation: Update Time: 2022-10-18T20:21:00Z Resource Version: 38840 UID: 8cb0967d-05e0-4d7a-ac1c-08a7f7e89e84 Raw Result Storage: Node Selector: node-role.kubernetes.io/master: Pv Access Modes: ReadWriteOnce Rotation: 3 Size: 1Gi Tolerations: Effect: NoSchedule Key: node-role.kubernetes.io/master Operator: Exists Effect: NoExecute Key: node.kubernetes.io/not-ready Operator: Exists Toleration Seconds: 300 Effect: NoExecute Key: node.kubernetes.io/unreachable Operator: Exists Toleration Seconds: 300 Effect: NoSchedule Key: node.kubernetes.io/memory-pressure Operator: Exists Roles: master worker Scan Tolerations: Operator: Exists Schedule: 0 1 * * * Show Not Applicable: false Strict Node Scan: true Events: <none>Créez un objet
ScanSettingBindingqui se lie à l'objet par défautScanSettinget analyse le cluster à l'aide des profilscisetcis-node. Par exemple :apiVersion: compliance.openshift.io/v1alpha1 kind: ScanSettingBinding metadata: name: cis-compliance namespace: openshift-compliance profiles: - name: ocp4-cis-node kind: Profile apiGroup: compliance.openshift.io/v1alpha1 - name: ocp4-cis kind: Profile apiGroup: compliance.openshift.io/v1alpha1 settingsRef: name: default kind: ScanSetting apiGroup: compliance.openshift.io/v1alpha1Créez l'objet
ScanSettingBindingen exécutant la commande$ oc create -f <file-name>.yaml -n openshift-compliance
A ce stade du processus, l'objet
ScanSettingBindingest rapproché et basé sur les paramètresBindingetBound. L'opérateur de conformité crée un objetComplianceSuiteet les objetsComplianceScanassociés.Suivez la progression de l'analyse de conformité en exécutant le programme :
$ oc get compliancescan -w -n openshift-compliance
Les analyses passent par les phases d'analyse et atteignent finalement la phase
DONElorsqu'elles sont terminées. Dans la plupart des cas, le résultat de l'analyse estNON-COMPLIANT. Vous pouvez examiner les résultats de l'analyse et commencer à appliquer des mesures correctives pour rendre le cluster conforme. Pour plus d'informations, reportez-vous à la section Gestion de la remédiation de l'opérateur de conformité.
5.5.2. Programmation du pod du serveur de résultats sur un nœud de travailleur
Le pod du serveur de résultats monte le volume persistant (PV) qui stocke les résultats bruts de l'analyse au format ARF (Asset Reporting Format). Les attributs nodeSelector et tolerations vous permettent de configurer l'emplacement du module de serveur de résultats.
Cette fonction est utile dans les environnements où les nœuds du plan de contrôle ne sont pas autorisés à monter des volumes persistants.
Procédure
Créer une ressource personnalisée (CR)
ScanSettingpour l'opérateur de conformité :Définissez le CR
ScanSettinget enregistrez le fichier YAML, par exemplers-workers.yaml:apiVersion: compliance.openshift.io/v1alpha1 kind: ScanSetting metadata: name: rs-on-workers namespace: openshift-compliance rawResultStorage: nodeSelector: node-role.kubernetes.io/worker: "" 1 pvAccessModes: - ReadWriteOnce rotation: 3 size: 1Gi tolerations: - operator: Exists 2 roles: - worker - master scanTolerations: - operator: Exists schedule: 0 1 * * *Pour créer le CR
ScanSetting, exécutez la commande suivante :$ oc create -f rs-workers.yaml
Vérification
Pour vérifier que l'objet
ScanSettingest créé, exécutez la commande suivante :$ oc get scansettings rs-on-workers -n openshift-compliance -o yaml
Exemple de sortie
apiVersion: compliance.openshift.io/v1alpha1 kind: ScanSetting metadata: creationTimestamp: "2021-11-19T19:36:36Z" generation: 1 name: rs-on-workers namespace: openshift-compliance resourceVersion: "48305" uid: 43fdfc5f-15a7-445a-8bbc-0e4a160cd46e rawResultStorage: nodeSelector: node-role.kubernetes.io/worker: "" pvAccessModes: - ReadWriteOnce rotation: 3 size: 1Gi tolerations: - operator: Exists roles: - worker - master scanTolerations: - operator: Exists schedule: 0 1 * * * strictNodeScan: true
5.5.3. ScanSetting Ressource personnalisée
La ressource personnalisée ScanSetting vous permet désormais d'outrepasser les limites de mémoire et de CPU par défaut des modules de numérisation grâce à l'attribut scan limits. L'Opérateur de Conformité utilisera les valeurs par défaut de 500Mi de mémoire, 100m CPU pour le conteneur scanner, et 200Mi de mémoire avec 100m CPU pour le conteneur api-resource-collector. Pour définir les limites de mémoire de l'opérateur, modifiez l'objet Subscription s'il est installé via OLM ou le déploiement de l'opérateur lui-même.
Pour augmenter les limites par défaut du CPU et de la mémoire de l'Opérateur de Conformité, voir Increasing Compliance Operator resource limits.
Il est nécessaire d'augmenter la limite de mémoire de l'opérateur de conformité ou des modules de numérisation si les limites par défaut ne sont pas suffisantes et que l'opérateur ou les modules de numérisation se terminent par le processus Out Of Memory (OOM).
5.5.4. Application des demandes et des limites de ressources
Lorsque le kubelet démarre un conteneur dans le cadre d'un pod, il transmet les demandes et les limites de ce conteneur en matière de mémoire et d'unité centrale à l'exécution du conteneur. Sous Linux, l'exécution du conteneur configure les cgroups du noyau qui appliquent et font respecter les limites que vous avez définies.
La limite de CPU définit le temps de CPU que le conteneur peut utiliser. Au cours de chaque intervalle de planification, le noyau Linux vérifie si cette limite est dépassée. Si c'est le cas, le noyau attend avant d'autoriser le cgroup à reprendre son exécution.
Si plusieurs conteneurs différents (cgroups) veulent s'exécuter sur un système contended, les charges de travail ayant des demandes d'UC plus importantes se voient attribuer plus de temps d'UC que les charges de travail ayant des demandes moins importantes. La demande de mémoire est utilisée lors de la planification des pods. Sur un nœud qui utilise cgroups v2, le moteur d'exécution du conteneur peut utiliser la demande de mémoire comme indice pour définir les valeurs memory.min et memory.low.
Si un conteneur tente d'allouer plus de mémoire que cette limite, le sous-système de sortie de mémoire du noyau Linux s'active et intervient en arrêtant l'un des processus du conteneur qui a tenté d'allouer de la mémoire. La limite de mémoire pour le Pod ou le conteneur peut également s'appliquer à des pages dans des volumes adossés à la mémoire, tels qu'un emptyDir.
Le kubelet suit les volumes tmpfs emptyDir au fur et à mesure que la mémoire du conteneur est utilisée, plutôt que comme un stockage éphémère local. Si un conteneur dépasse sa demande de mémoire et que le nœud sur lequel il s'exécute manque de mémoire, le conteneur du pod peut être expulsé.
Un conteneur ne peut pas dépasser sa limite de CPU pendant de longues périodes. Les temps d'exécution des conteneurs n'arrêtent pas les pods ou les conteneurs en cas d'utilisation excessive du processeur. Pour déterminer si un conteneur ne peut pas être planifié ou s'il est tué en raison de limites de ressources, voir Troubleshooting the Compliance Operator.
5.5.5. Ordonnancement des pods avec les demandes de ressources des conteneurs
Lorsqu'un module est créé, le planificateur sélectionne un nœud sur lequel le module doit s'exécuter. Chaque nœud a une capacité maximale pour chaque type de ressource en ce qui concerne la quantité de CPU et de mémoire qu'il peut fournir aux Pods. L'ordonnanceur veille à ce que la somme des demandes de ressources des conteneurs programmés soit inférieure à la capacité des nœuds pour chaque type de ressource.
Même si l'utilisation de la mémoire ou de l'unité centrale sur les nœuds est très faible, le planificateur peut toujours refuser de placer un pod sur un nœud si la vérification de la capacité ne permet pas de se prémunir contre une pénurie de ressources sur un nœud.
Pour chaque conteneur, vous pouvez spécifier les limites de ressources et les demandes suivantes :
spec.containers[].resources.limits.cpu spec.containers[].resources.limits.memory spec.containers[].resources.limits.hugepages-<size> spec.containers[].resources.requests.cpu spec.containers[].resources.requests.memory spec.containers[].resources.requests.hugepages-<size>
Bien que vous puissiez spécifier des demandes et des limites pour des conteneurs individuels, il est également utile de prendre en compte les demandes et les limites de ressources globales pour un module. Pour une ressource particulière, une demande ou une limite de ressource de conteneur est la somme des demandes ou des limites de ressources de ce type pour chaque conteneur dans le module.
Exemple de demandes et de limites de ressources pour les conteneurs
apiVersion: v1
kind: Pod
metadata:
name: frontend
spec:
containers:
- name: app
image: images.my-company.example/app:v4
resources:
requests: 1
memory: "64Mi"
cpu: "250m"
limits: 2
memory: "128Mi"
cpu: "500m"
- name: log-aggregator
image: images.my-company.example/log-aggregator:v6
resources:
requests:
memory: "64Mi"
cpu: "250m"
limits:
memory: "128Mi"
cpu: "500m"
