5.11. Exécution de tâches avancées de l'opérateur de conformité

Bien qu'il soit recommandé aux utilisateurs de tirer parti des objets ScanSetting et ScanSettingBinding pour définir les suites et les balayages, il existe des cas d'utilisation valables pour définir directement les objets ComplianceSuite:

L'exemple suivant montre un site ComplianceSuite qui analyse les machines de travail avec une seule règle :

apiVersion: compliance.openshift.io/v1alpha1
kind: ComplianceSuite
metadata:
  name: workers-compliancesuite
spec:
  scans:
    - name: workers-scan
      profile: xccdf_org.ssgproject.content_profile_moderate
      content: ssg-rhcos4-ds.xml
      contentImage: quay.io/complianceascode/ocp4:latest
      debug: true
      rule: xccdf_org.ssgproject.content_rule_no_direct_root_logins
      nodeSelector:
      node-role.kubernetes.io/worker: ""

L'objet ComplianceSuite et les objets ComplianceScan mentionnés ci-dessus spécifient plusieurs attributs dans un format attendu par OpenSCAP.

Pour connaître les valeurs du profil, du contenu ou de la règle, vous pouvez commencer par créer une suite similaire à partir de ScanSetting et ScanSettingBinding ou inspecter les objets analysés à partir des objets ProfileBundle tels que les règles ou les profils. Ces objets contiennent les identifiants xccdf_org que vous pouvez utiliser pour y faire référence à partir de ComplianceSuite.

Dans les environnements à grande échelle, l'objet par défaut PriorityClass peut être trop bas pour garantir que les pods exécutent les analyses à temps. Pour les clusters qui doivent maintenir la conformité ou garantir l'analyse automatisée, il est recommandé de définir la variable PriorityClass afin de garantir que l'opérateur de conformité est toujours prioritaire dans les situations où les ressources sont limitées.

Alors que la norme TailoredProfile CR permet les opérations d'adaptation les plus courantes, la norme XCCDF offre encore plus de flexibilité dans l'adaptation des profils OpenSCAP. En outre, si votre organisation a déjà utilisé OpenScap, il se peut que vous disposiez d'un fichier d'adaptation XCCDF et que vous puissiez le réutiliser.

L'objet ComplianceSuite contient un attribut facultatif TailoringConfigMap qui permet de pointer vers un fichier d'adaptation personnalisé. La valeur de l'attribut TailoringConfigMap est le nom d'une carte de configuration qui doit contenir une clé appelée tailoring.xml et la valeur de cette clé est le contenu de l'adaptation.

En règle générale, vous souhaitez réexécuter une analyse selon un calendrier défini, par exemple tous les lundis ou tous les jours. Il peut également être utile de réexécuter une analyse après avoir résolu un problème sur un nœud. Pour effectuer une analyse unique, annotez l'analyse avec l'option compliance.openshift.io/rescan=:

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

Un rescan génère quatre mc supplémentaires pour le profil rhcos-moderate:

$ oc get mc

75-worker-scan-chronyd-or-ntpd-specify-remote-server
75-worker-scan-configure-usbguard-auditbackend
75-worker-scan-service-usbguard-enabled
75-worker-scan-usbguard-allow-hid-and-hub

Bien que les ressources personnalisées telles que ComplianceCheckResult représentent un résultat agrégé d'une vérification sur tous les nœuds analysés, il peut être utile d'examiner les résultats bruts tels qu'ils sont produits par l'analyseur. Les résultats bruts sont produits au format ARF et peuvent être volumineux (des dizaines de mégaoctets par nœud), il n'est pas pratique de les stocker dans une ressource Kubernetes soutenue par le magasin de valeurs clés etcd. Au lieu de cela, chaque analyse crée un volume persistant (PV) dont la taille par défaut est de 1 Go. En fonction de votre environnement, vous pouvez augmenter la taille du PV en conséquence. Cela se fait à l'aide de l'attribut rawResultStorage.size qui est exposé dans les ressources ScanSetting et ComplianceScan.

Un paramètre connexe est rawResultStorage.rotation, qui détermine le nombre de balayages conservés dans le PV avant que les balayages les plus anciens ne fassent l'objet d'une rotation. La valeur par défaut est de 3. En fixant la politique de rotation à 0, vous désactivez la rotation. Compte tenu de la politique de rotation par défaut et d'une estimation de 100 Mo pour un rapport d'analyse ARF brut, vous pouvez calculer la taille du PV adaptée à votre environnement.

apiVersion: compliance.openshift.io/v1alpha1
kind: ScanSetting
metadata:
  name: default
  namespace: openshift-compliance
rawResultStorage:
  storageClassName: standard
  rotation: 10
  size: 10Gi
roles:
- worker
- master
scanTolerations:
- effect: NoSchedule
  key: node-role.kubernetes.io/master
  operator: Exists
schedule: '0 1 * * *'

Bien que vous puissiez utiliser le paramètre booléen autoApplyRemediations dans un objet ComplianceSuite, vous pouvez également annoter l'objet avec compliance.openshift.io/apply-remediations. Cela permet à l'opérateur d'appliquer toutes les mesures correctives créées.

$ oc -n openshift-compliance \
annotate compliancesuites/workers-compliancesuite compliance.openshift.io/apply-remediations=

Dans certains cas, une analyse avec un contenu plus récent peut marquer les remédiations comme OUTDATED. En tant qu'administrateur, vous pouvez appliquer l'annotation compliance.openshift.io/remove-outdated pour appliquer de nouvelles mesures correctives et supprimer celles qui sont obsolètes.

$ oc -n openshift-compliance \
annotate compliancesuites/workers-compliancesuite compliance.openshift.io/remove-outdated=

Vous pouvez également activer l'indicateur autoUpdateRemediations dans un objet ScanSetting ou ComplianceSuite pour mettre à jour les mesures correctives automatiquement.

Dans certains environnements, vous devez créer un fichier de contraintes de contexte de sécurité (SCC) personnalisé pour vous assurer que les autorisations correctes sont disponibles pour l'opérateur de conformité api-resource-collector.