SupportConsoleDéveloppeursCommencer un essaiContact

Chapitre 5. Opérateur de conformité

5.1. Notes de mise à jour de l'opérateur de conformité

L'opérateur de conformité permet aux administrateurs d'OpenShift Container Platform de décrire l'état de conformité requis d'un cluster et leur fournit un aperçu des lacunes et des moyens d'y remédier.

Ces notes de version suivent le développement de l'opérateur de conformité dans la plateforme OpenShift Container.

Pour une vue d'ensemble de l'Opérateur de Conformité, voir Comprendre l'Opérateur de Conformité.

Pour accéder à la dernière version, voir Mise à jour de l'opérateur de conformité.

5.1.1. OpenShift Compliance Operator 1.0.0

L'avis suivant est disponible pour OpenShift Compliance Operator 1.0.0 :

5.1.1.1. Nouvelles fonctionnalités et améliorations

5.1.1.2. Bug fixes

  • Avant cette mise à jour, la métrique compliance_operator_compliance_scan_error_total avait une étiquette ERROR avec une valeur différente pour chaque message d'erreur. Avec cette mise à jour, la métrique compliance_operator_compliance_scan_error_total n'augmente pas en valeur. (OCPBUGS-1803)
  • Avant cette mise à jour, la règle ocp4-api-server-audit-log-maxsize entraînait l'état FAIL. Avec cette mise à jour, le message d'erreur a été supprimé de la métrique, ce qui réduit la cardinalité de la métrique conformément aux meilleures pratiques. (OCPBUGS-7520)
  • Avant cette mise à jour, la description de la règle rhcos4-enable-fips-mode induisait en erreur en indiquant que le système FIPS pouvait être activé après l'installation. Avec cette mise à jour, la description de la règle rhcos4-enable-fips-mode précise que le FIPS doit être activé au moment de l'installation. (OCPBUGS-8358)

5.1.2. OpenShift Compliance Operator 0.1.61

L'avis suivant est disponible pour l'OpenShift Compliance Operator 0.1.61 :

5.1.2.1. Nouvelles fonctionnalités et améliorations

  • L'opérateur de conformité prend désormais en charge la configuration du délai d'attente pour les Scanner Pods. Le délai est spécifié dans l'objet ScanSetting. Si l'analyse n'est pas terminée dans le délai imparti, elle recommence jusqu'à ce que le nombre maximum de tentatives soit atteint. Pour plus d'informations, consultez la section Configuration du délai d'attente de ScanSetting.

5.1.2.2. Bug fixes

  • Avant cette mise à jour, les remédiations de l'opérateur de conformité nécessitaient des variables en entrée. Les remédiations sans variables définies étaient appliquées à l'ensemble du cluster et entraînaient des nœuds bloqués, même s'il semblait que la remédiation s'appliquait correctement. Avec cette mise à jour, l'Opérateur de Conformité valide si une variable doit être fournie en utilisant TailoredProfile pour une remédiation. (OCPBUGS-3864)
  • Avant cette mise à jour, les instructions pour ocp4-kubelet-configure-tls-cipher-suites étaient incomplètes, obligeant les utilisateurs à affiner la requête manuellement. Avec cette mise à jour, la requête fournie dans ocp4-kubelet-configure-tls-cipher-suites renvoie les résultats réels pour effectuer les étapes de l'audit. (OCPBUGS-3017)
  • Avant cette mise à jour, les objetsScanSettingBinding créés sans variable settingRef n'utilisaient pas de valeur par défaut appropriée. Avec cette mise à jour, les objets ScanSettingBinding sans variable settingRef utilisent la valeur default. (OCPBUGS-3420)
  • Avant cette mise à jour, les paramètres réservés au système n'étaient pas générés dans les fichiers de configuration kubelet, ce qui faisait que l'opérateur de conformité ne parvenait pas à débloquer le pool de configuration de la machine. Avec cette mise à jour, l'opérateur de conformité omet les paramètres réservés au système lors de l'évaluation du pool de configuration de la machine. (OCPBUGS-4445)
  • Avant cette mise à jour, les objets ComplianceCheckResult n'avaient pas de descriptions correctes. Avec cette mise à jour, l'opérateur de conformité extrait les informations de ComplianceCheckResult de la description de la règle. (OCPBUGS-4615)
  • Avant cette mise à jour, l'Opérateur de Conformité ne vérifiait pas la présence de fichiers de configuration kubelet vides lors de l'analyse des configurations des machines. En conséquence, l'Opérateur de Conformité paniquait et se plantait. Avec cette mise à jour, l'Opérateur de Conformité met en œuvre une vérification améliorée de la structure de données de la configuration kubelet et ne continue que si elle est entièrement rendue. (OCPBUGS-4621)
  • Avant cette mise à jour, l'opérateur de conformité générait des remédiations pour les évictions de kubelets en fonction du nom du pool de configuration de la machine et d'une période de grâce, ce qui entraînait plusieurs remédiations pour une seule règle d'éviction. Avec cette mise à jour, l'opérateur de conformité applique toutes les mesures correctives pour une seule règle. (OCPBUGS-4338)
  • Avant cette mise à jour, la ré-exécution d'analyses sur des remédiations qui se trouvaient auparavant à l'adresse Applied pouvait être marquée comme Outdated après la ré-exécution des analyses, bien que le contenu de la remédiation n'ait pas été modifié. La comparaison des analyses ne prenait pas correctement en compte les métadonnées de la remédiation. Avec cette mise à jour, les remédiations conservent le statut Applied généré précédemment. (OCPBUGS-6710)
  • Avant cette mise à jour, une régression se produisait lors de la création d'un site ScanSettingBinding utilisant un site TailoredProfile avec un site MachineConfigPool qui n'était pas par défaut et qui marquait le site ScanSettingBinding en tant que site Failed. Avec cette mise à jour, la fonctionnalité est rétablie et les ScanSettingBinding personnalisés utilisant un TailoredProfile fonctionnent correctement. (OCPBUGS-6827)

  • Avant cette mise à jour, certains paramètres de configuration des kubelets n'avaient pas de valeurs par défaut. Avec cette mise à jour, les paramètres suivants contiennent des valeurs par défaut (OCPBUGS-6708) :

    • ocp4-cis-kubelet-enable-streaming-connections
    • ocp4-cis-kubelet-eviction-thresholds-set-hard-imagefs-available
    • ocp4-cis-kubelet-eviction-thresholds-set-hard-imagefs-inodesfree
    • ocp4-cis-kubelet-eviction-thresholds-set-hard-memory-available
    • ocp4-cis-kubelet-eviction-thresholds-set-hard-nodefs-available
  • Avant cette mise à jour, la règle selinux_confinement_of_daemons ne fonctionnait pas sur le kubelet en raison des permissions nécessaires à son exécution. Avec cette mise à jour, la règle selinux_confinement_of_daemons est désactivée. (OCPBUGS-6968)

5.1.3. OpenShift Compliance Operator 0.1.59

L'avis suivant est disponible pour l'OpenShift Compliance Operator 0.1.59 :

5.1.3.1. Nouvelles fonctionnalités et améliorations

  • L'opérateur de conformité prend désormais en charge les profils PCI-DSS (Payment Card Industry Data Security Standard) ocp4-pci-dss et ocp4-pci-dss-node sur l'architecture ppc64le.

5.1.3.2. Bug fixes

  • Auparavant, l'Opérateur de Conformité ne prenait pas en charge les profils Payment Card Industry Data Security Standard (PCI DSS) ocp4-pci-dss et ocp4-pci-dss-node sur différentes architectures telles que ppc64le. Désormais, l'opérateur de conformité prend en charge les profils ocp4-pci-dss et ocp4-pci-dss-node sur l'architecture ppc64le. (OCPBUGS-3252)
  • Auparavant, après la récente mise à jour vers la version 0.1.57, le compte de service rerunner (SA) n'était plus détenu par la version de service du cluster (CSV), ce qui entraînait la suppression du SA lors de la mise à niveau de l'opérateur. Désormais, le CSV possède le SA rerunner dans la version 0.1.59, et les mises à niveau à partir d'une version antérieure n'entraîneront pas de SA manquant. (OCPBUGS-3452)
  • Dans la version 0.1.57, l'opérateur a démarré le point de terminaison des métriques du contrôleur en écoutant sur le port 8080. Cela a donné lieu à des alertes TargetDown car le port attendu par la surveillance des clusters est 8383. Avec la version 0.1.59, l'opérateur lance l'écoute sur le port 8383 comme prévu. (OCPBUGS-3097)

5.1.4. OpenShift Compliance Operator 0.1.57

L'avis suivant est disponible pour l'OpenShift Compliance Operator 0.1.57 :

5.1.4.1. Nouvelles fonctionnalités et améliorations

5.1.4.2. Bug fixes

  • Auparavant, l'opérateur de conformité codait en dur les notifications dans l'espace de noms par défaut openshift-compliance. Si l'opérateur était installé dans un espace de noms autre que celui par défaut, les notifications ne fonctionnaient pas comme prévu. Désormais, les notifications fonctionnent dans les espaces de noms autres que openshift-compliance. (BZ#2060726)
  • Auparavant, l'opérateur de conformité n'était pas en mesure d'évaluer les configurations par défaut utilisées par les objets kubelet, ce qui entraînait des résultats inexacts et des faux positifs. Cette nouvelle fonctionnalité évalue la configuration des kubelets et produit désormais un rapport précis. (BZ#2075041)
  • Auparavant, l'opérateur de conformité signalait la règle ocp4-kubelet-configure-event-creation dans un état FAIL après avoir appliqué une remédiation automatique parce que la valeur eventRecordQPS était supérieure à la valeur par défaut. Désormais, la remédiation de la règle ocp4-kubelet-configure-event-creation définit la valeur par défaut et la règle s'applique correctement. (BZ#2082416)
  • La règle ocp4-configure-network-policies nécessite une intervention manuelle pour être efficace. De nouvelles instructions descriptives et des mises à jour de la règle augmentent l'applicabilité de la règle ocp4-configure-network-policies pour les clusters utilisant des CNI Calico. (BZ#2091794)
  • Auparavant, l'opérateur de conformité ne nettoyait pas les pods utilisés pour analyser l'infrastructure lors de l'utilisation de l'option debug=true dans les paramètres d'analyse. Les pods restaient donc sur le cluster même après la suppression de ScanSettingBinding. Désormais, les pods sont toujours supprimés lorsqu'un ScanSettingBinding est supprimé.(BZ#2092913)
  • Auparavant, l'opérateur de conformité utilisait une ancienne version de la commande operator-sdk qui provoquait des alertes concernant des fonctionnalités obsolètes. Maintenant, une version mise à jour de la commande operator-sdk est incluse et il n'y a plus d'alertes concernant des fonctionnalités obsolètes. (BZ#2098581)
  • Auparavant, l'opérateur de conformité ne parvenait pas à appliquer les remédiations s'il ne pouvait pas déterminer la relation entre les configurations des kubelets et des machines. Désormais, l'opérateur de conformité a amélioré la gestion des configurations de machines et est capable de déterminer si une configuration de kubelet est un sous-ensemble d'une configuration de machine. (BZ#2102511)
  • Auparavant, la règle pour ocp4-cis-node-master-kubelet-enable-cert-rotation ne décrivait pas correctement les critères de réussite. Par conséquent, les exigences pour RotateKubeletClientCertificate n'étaient pas claires. Désormais, la règle pour ocp4-cis-node-master-kubelet-enable-cert-rotation produit un rapport précis quelle que soit la configuration présente dans le fichier de configuration du kubelet. (BZ#2105153)
  • Auparavant, la règle de vérification des délais d'inactivité des flux ne prenait pas en compte les valeurs par défaut, ce qui entraînait des rapports de règles inexacts. Désormais, des contrôles plus robustes garantissent une plus grande précision des résultats basés sur les valeurs de configuration par défaut. (BZ#2105878)
  • Auparavant, l'Opérateur de Conformité ne parvenait pas à récupérer les ressources de l'API lors de l'analyse des configurations de machines sans spécifications Ignition, ce qui provoquait le plantage en boucle des processus api-check-pods. Désormais, l'Opérateur de Conformité gère correctement les pools de configurations de machines qui n'ont pas de spécifications d'allumage. (BZ#2117268)
  • Auparavant, les règles évaluant la configuration modprobe échouaient même après l'application des remédiations en raison d'une incohérence dans les valeurs de la configuration modprobe. Désormais, les mêmes valeurs sont utilisées pour la configuration modprobe dans les vérifications et les remédiations, ce qui garantit des résultats cohérents. (BZ#2117747)

5.1.4.3. Dépréciations

  • Le fait de spécifier Install into all namespaces in the cluster ou de définir la variable d'environnement WATCH_NAMESPACES sur "" n'affecte plus tous les espaces de noms. Toutes les ressources API installées dans des espaces de noms non spécifiés au moment de l'installation de l'Opérateur de conformité ne sont plus opérationnelles. Les ressources API peuvent nécessiter une création dans l'espace de noms sélectionné ou dans l'espace de noms openshift-compliance par défaut. Ce changement améliore l'utilisation de la mémoire de l'Opérateur de Conformité.

5.1.5. OpenShift Compliance Operator 0.1.53

L'avis suivant est disponible pour l'OpenShift Compliance Operator 0.1.53 :

5.1.5.1. Bug fixes

  • Auparavant, la règle ocp4-kubelet-enable-streaming-connections contenait une comparaison de variables incorrecte, ce qui entraînait des résultats d'analyse faussement positifs. Désormais, l'opérateur de conformité fournit des résultats d'analyse précis lorsqu'il définit streamingConnectionIdleTimeout. (BZ#2069891)
  • Auparavant, la propriété du groupe pour /etc/openvswitch/conf.db était incorrecte sur les architectures IBM Z, ce qui entraînait des échecs du contrôle de ocp4-cis-node-worker-file-groupowner-ovs-conf-db. Désormais, le contrôle est marqué NOT-APPLICABLE sur les systèmes d'architecture IBM Z. (BZ#2072597)
  • Auparavant, la règle ocp4-cis-scc-limit-container-allowed-capabilities était signalée dans l'état FAIL en raison de données incomplètes concernant les règles de contraintes de contexte de sécurité (SCC) dans le déploiement. Désormais, le résultat est MANUAL, ce qui est cohérent avec d'autres contrôles nécessitant une intervention humaine. (BZ#2077916)

  • Auparavant, les règles suivantes ne tenaient pas compte des chemins de configuration supplémentaires pour les serveurs API et les certificats et clés TLS, ce qui entraînait des échecs même si les certificats et les clés étaient correctement définis :

    • ocp4-cis-api-server-kubelet-client-cert
    • ocp4-cis-api-server-kubelet-client-key
    • ocp4-cis-kubelet-configure-tls-cert
    • ocp4-cis-kubelet-configure-tls-key

    Désormais, les règles produisent des rapports précis et respectent les chemins d'accès aux fichiers hérités spécifiés dans le fichier de configuration de la kubelet. (BZ#2079813)

  • Auparavant, la règle content_rule_oauth_or_oauthclient_inactivity_timeout ne tenait pas compte d'un délai configurable défini par le déploiement lors de l'évaluation de la conformité des délais. La règle échouait donc même si le délai était valide. Désormais, l'opérateur de conformité utilise la variable var_oauth_inactivity_timeout pour définir la durée du délai d'attente. (BZ#2081952)
  • Auparavant, l'opérateur de conformité utilisait des autorisations administratives sur des espaces de noms qui n'étaient pas étiquetés de manière appropriée pour une utilisation privilégiée, ce qui entraînait des messages d'avertissement concernant des violations du niveau de sécurité des pods. Désormais, l'opérateur de conformité dispose des étiquettes d'espace de noms appropriées et des ajustements de permissions pour accéder aux résultats sans enfreindre les permissions. (BZ#2088202)
  • Auparavant, l'application de remédiations automatiques pour rhcos4-high-master-sysctl-kernel-yama-ptrace-scope et rhcos4-sysctl-kernel-core-pattern entraînait l'échec de ces règles dans les résultats de l'analyse, même si elles avaient été remédiées. Désormais, les règles signalent PASS avec précision, même après l'application de mesures correctives.(BZ#2094382)
  • Auparavant, l'opérateur de conformité échouait dans un état CrashLoopBackoff en raison d'exceptions hors mémoire. Désormais, l'Opérateur de Conformité est amélioré pour gérer de grands ensembles de données de configuration de machine en mémoire et fonctionner correctement. (BZ#2094854)

5.1.5.2. Problème connu

  • Lorsque "debug":true est défini dans l'objet ScanSettingBinding, les pods générés par l'objet ScanSettingBinding ne sont pas supprimés lorsque cette liaison est supprimée. Pour contourner ce problème, exécutez la commande suivante pour supprimer les pods restants : 

    $ oc delete pods -l compliance.openshift.io/scan-name=ocp4-cis

    (BZ#2092913)

5.1.6. OpenShift Compliance Operator 0.1.52

L'avis suivant est disponible pour l'OpenShift Compliance Operator 0.1.52 :

5.1.6.1. Nouvelles fonctionnalités et améliorations

  • Le profil FedRAMP high SCAP est désormais disponible pour une utilisation dans les environnements OpenShift Container Platform. Pour plus d'informations, voir Profils de conformité pris en charge.

5.1.6.2. Bug fixes

  • Auparavant, le conteneur OpenScap se bloquait en raison d'un problème de permission de montage dans un environnement de sécurité où la capacité DAC_OVERRIDE est abandonnée. Désormais, les autorisations de montage des exécutables sont appliquées à tous les utilisateurs. (BZ#2082151)
  • Auparavant, la règle de conformité ocp4-configure-network-policies pouvait être configurée comme MANUAL. Désormais, la règle de conformité ocp4-configure-network-policies est configurée sous la forme AUTOMATIC. (BZ#2072431)
  • Auparavant, le Cluster Autoscaler ne parvenait pas à se mettre à l'échelle parce que les pods d'analyse de l'opérateur de conformité n'étaient jamais supprimés après une analyse. Désormais, les modules sont supprimés de chaque nœud par défaut, sauf s'ils sont explicitement sauvegardés à des fins de débogage. (BZ#2075029)
  • Auparavant, l'application de l'opérateur de conformité à l'adresse KubeletConfig entraînait l'entrée du nœud dans l'état NotReady en raison de la désactivation prématurée des pools de configuration de machines. Désormais, les pools de configuration de machines sont désactivés de manière appropriée et le nœud fonctionne correctement. (BZ#2071854)
  • Auparavant, l'opérateur de configuration des machines utilisait le code base64 au lieu de url-encoded dans la dernière version, ce qui entraînait l'échec de la remédiation de l'opérateur de conformité. Désormais, l'opérateur de conformité vérifie l'encodage pour gérer les codes de configuration machine base64 et url-encoded et la remédiation s'applique correctement. (BZ#2082431)

5.1.6.3. Problème connu

  • Lorsque "debug":true est défini dans l'objet ScanSettingBinding, les pods générés par l'objet ScanSettingBinding ne sont pas supprimés lorsque cette liaison est supprimée. Pour contourner ce problème, exécutez la commande suivante pour supprimer les pods restants : 

    $ oc delete pods -l compliance.openshift.io/scan-name=ocp4-cis

    (BZ#2092913)

5.1.7. OpenShift Compliance Operator 0.1.49

L'avis suivant est disponible pour l'OpenShift Compliance Operator 0.1.49 :

5.1.7.1. Nouvelles fonctionnalités et améliorations

  • L'opérateur de conformité est désormais pris en charge sur les architectures suivantes :

    • IBM Power
    • IBM Z
    • IBM LinuxONE

5.1.7.2. Bug fixes

  • Auparavant, le contenu de openshift-compliance n'incluait pas les contrôles spécifiques à la plateforme pour les types de réseau. Par conséquent, les contrôles spécifiques à OVN et SDN s'affichaient comme failed au lieu de not-applicable en fonction de la configuration du réseau. Désormais, les nouvelles règles contiennent des contrôles de plateforme pour les règles de mise en réseau, ce qui permet une évaluation plus précise des contrôles spécifiques au réseau. (BZ#1994609)
  • Auparavant, la règle ocp4-moderate-routes-protected-by-tls vérifiait incorrectement les paramètres TLS, ce qui entraînait l'échec de la règle, même si la connexion était sécurisée par le protocole SSL/TLS. Désormais, la vérification évalue correctement les paramètres TLS qui sont cohérents avec les conseils de mise en réseau et les recommandations de profil. (BZ#2002695)
  • Auparavant, ocp-cis-configure-network-policies-namespace utilisait la pagination lors de la demande d'espaces de noms. Cela entraînait l'échec de la règle car les déploiements tronquaient les listes de plus de 500 espaces de noms. Désormais, la liste complète des espaces de noms est demandée et la règle de vérification des stratégies réseau configurées fonctionne pour les déploiements comportant plus de 500 espaces de noms. (BZ#2038909)
  • Auparavant, les remédiations utilisant les macros sshd jinja étaient codées en dur sur des configurations sshd spécifiques. En conséquence, les configurations n'étaient pas cohérentes avec le contenu que les règles vérifiaient et la vérification échouait. Désormais, la configuration sshd est paramétrée et les règles s'appliquent avec succès. (BZ#2049141)
  • Auparavant, le site ocp4-cluster-version-operator-verify-integrity vérifiait toujours la première entrée dans l'historique du Cluter Version Operator (CVO). Par conséquent, la mise à niveau échouait dans les situations où les versions suivantes de {nom-du-produit} étaient vérifiées. Désormais, le résultat du contrôle de conformité pour ocp4-cluster-version-operator-verify-integrity est capable de détecter les versions vérifiées et est précis avec l'historique CVO. (BZ#2053602)
  • Auparavant, la règle ocp4-api-server-no-adm-ctrl-plugins-disabled ne vérifiait pas la présence d'une liste de plugins de contrôleurs d'admission vides. Par conséquent, la règle échouait toujours, même si tous les plugins d'admission étaient activés. Désormais, la règle ocp4-api-server-no-adm-ctrl-plugins-disabled fait l'objet d'une vérification plus rigoureuse et passe avec succès lorsque tous les plugins de contrôleurs d'admission sont activés. (BZ#2058631)
  • Auparavant, les analyses ne contenaient pas de vérifications de plate-forme pour l'exécution contre des nœuds de travail Linux. Par conséquent, l'exécution d'analyses sur des nœuds de travail qui n'étaient pas basés sur Linux entraînait une boucle d'analyse sans fin. Désormais, l'analyse est planifiée de manière appropriée en fonction du type de plate-forme et les étiquettes se terminent avec succès. (BZ#2056911)

5.1.8. OpenShift Compliance Operator 0.1.48

L'avis suivant est disponible pour l'OpenShift Compliance Operator 0.1.48 :

5.1.8.1. Bug fixes

  • Auparavant, certaines règles associées à des définitions OVAL (Open Vulnerability and Assessment Language) étendues avaient un checkType de None. Cela était dû au fait que l'opérateur de conformité ne traitait pas les définitions OVAL étendues lors de l'analyse des règles. Avec cette mise à jour, le contenu des définitions OVAL étendues est analysé de sorte que ces règles ont maintenant un checkType de Node ou Platform. (BZ#2040282)
  • Auparavant, un objet MachineConfig créé manuellement pour KubeletConfig empêchait la génération d'un objet KubeletConfig pour la remédiation, laissant la remédiation dans l'état Pending. Avec cette version, un objet KubeletConfig est créé par la remédiation, même s'il existe un objet MachineConfig créé manuellement pour KubeletConfig. Par conséquent, les remédiations KubeletConfig fonctionnent désormais comme prévu. (BZ#2040401)

5.1.9. OpenShift Compliance Operator 0.1.47

L'avis suivant est disponible pour l'OpenShift Compliance Operator 0.1.47 :

5.1.9.1. Nouvelles fonctionnalités et améliorations

  • L'opérateur de conformité prend désormais en charge les critères de conformité suivants pour la norme de sécurité des données de l'industrie des cartes de paiement (PCI DSS) :

    • ocp4-pci-dss
    • ocp4-pci-dss-node
  • Des règles et des remédiations supplémentaires pour le niveau d'impact modéré de FedRAMP sont ajoutées aux profils OCP4-moderate, OCP4-moderate-node et rhcos4-moderate.
  • Les remédiations pour KubeletConfig sont maintenant disponibles dans les profils au niveau des nœuds.

5.1.9.2. Bug fixes

  • Auparavant, si votre cluster exécutait OpenShift Container Platform 4.6 ou une version antérieure, les remédiations pour les règles liées à USBGuard échouaient pour le profil modéré. En effet, les remédiations créées par l'opérateur de conformité étaient basées sur une ancienne version d'USBGuard qui ne prenait pas en charge les répertoires de dépôt. Désormais, les remédiations invalides pour les règles liées à USBGuard ne sont pas créées pour les clusters utilisant OpenShift Container Platform 4.6. Si votre cluster utilise OpenShift Container Platform 4.6, vous devez créer manuellement des remédiations pour les règles liées à USBGuard.

    En outre, les mesures correctives ne sont créées que pour les règles qui satisfont aux exigences minimales en matière de version. (BZ#1965511)

  • Auparavant, lors du rendu des remédiations, l'opérateur de conformité vérifiait que la remédiation était bien formée en utilisant une expression régulière trop stricte. Par conséquent, certaines mesures correctives, telles que celles qui rendent sshd_config, ne passaient pas le contrôle de l'expression régulière et n'étaient donc pas créées. L'expression régulière s'est avérée inutile et a été supprimée. Les remédiations sont maintenant rendues correctement. (BZ#2033009)

5.1.10. OpenShift Compliance Operator 0.1.44

L'avis suivant est disponible pour l'OpenShift Compliance Operator 0.1.44 :

5.1.10.1. Nouvelles fonctionnalités et améliorations

  • Dans cette version, l'option strictNodeScan est désormais ajoutée aux CR ComplianceScan, ComplianceSuite et ScanSetting. Cette option est définie par défaut sur true, ce qui correspond au comportement précédent, où une erreur se produisait si une analyse ne pouvait pas être programmée sur un nœud. En définissant l'option sur false, l'opérateur de conformité peut être plus permissif en ce qui concerne la programmation des analyses. Les environnements avec des nœuds éphémères peuvent définir la valeur strictNodeScan sur false, ce qui permet à une analyse de conformité de se dérouler, même si certains nœuds du cluster ne sont pas disponibles pour la planification.
  • Vous pouvez maintenant personnaliser le nœud utilisé pour planifier la charge de travail du serveur de résultats en configurant les attributs nodeSelector et tolerations de l'objet ScanSetting. Ces attributs sont utilisés pour placer le pod ResultServer, le pod utilisé pour monter un volume de stockage PV et stocker les résultats bruts ARF (Asset Reporting Format). Auparavant, les paramètres nodeSelector et tolerations sélectionnaient par défaut l'un des nœuds du plan de contrôle et toléraient node-role.kubernetes.io/master taint, ce qui ne fonctionnait pas dans les environnements où les nœuds du plan de contrôle ne sont pas autorisés à monter des PV. Cette fonctionnalité vous permet de sélectionner le nœud et de tolérer une altération différente dans ces environnements.
  • L'opérateur de conformité peut maintenant remédier aux objets KubeletConfig.
  • Un commentaire contenant un message d'erreur est désormais ajouté pour aider les développeurs de contenu à faire la différence entre les objets qui n'existent pas dans le cluster et les objets qui ne peuvent pas être récupérés.
  • Les objets de règle contiennent désormais deux nouveaux attributs, checkType et description. Ces attributs vous permettent de déterminer si la règle concerne un contrôle de nœud ou un contrôle de plate-forme, et vous permettent également d'examiner ce que fait la règle.
  • Cette amélioration supprime l'obligation d'étendre un profil existant pour créer un profil sur mesure. Cela signifie que le champ extends dans le CRD TailoredProfile n'est plus obligatoire. Vous pouvez désormais sélectionner une liste d'objets de règles pour créer un profil personnalisé. Notez que vous devez choisir si votre profil s'applique aux nœuds ou à la plate-forme en définissant l'annotation compliance.openshift.io/product-type: ou en définissant le suffixe -node pour le CR TailoredProfile.
  • Dans cette version, l'opérateur de conformité est désormais en mesure de programmer des analyses sur tous les nœuds, indépendamment de leurs taches. Auparavant, les pods d'analyse ne toléraient que node-role.kubernetes.io/master taint, ce qui signifie qu'ils s'exécutaient soit sur des nœuds sans taint, soit uniquement sur des nœuds avec le taint node-role.kubernetes.io/master. Dans les déploiements qui utilisent des taints personnalisés pour leurs nœuds, les analyses n'étaient pas planifiées sur ces nœuds. Désormais, les pods d'analyse tolèrent tous les taints de nœuds.

  • Dans cette version, l'opérateur de conformité prend en charge les profils de sécurité suivants de la North American Electric Reliability Corporation (NERC) :

    • ocp4-nerc-cip
    • ocp4-nerc-cip-node
    • rhcos4-nerc-cip
  • Dans cette version, l'opérateur de conformité prend en charge la ligne de base NIST 800-53 Moderate-Impact pour le profil de sécurité Red Hat OpenShift - Node level, ocp4-moderate-node.

5.1.10.2. Modélisation et utilisation de variables

  • Dans cette version, le modèle de remédiation autorise désormais les variables à valeurs multiples.
  • Avec cette mise à jour, l'opérateur de conformité peut modifier les mesures correctives en fonction des variables définies dans le profil de conformité. Ceci est utile pour les remédiations qui incluent des valeurs spécifiques au déploiement telles que les délais, les noms d'hôtes des serveurs NTP, ou similaires. En outre, les objets ComplianceCheckResult utilisent désormais l'étiquette compliance.openshift.io/check-has-value qui répertorie les variables utilisées par un contrôle.

5.1.10.3. Bug fixes

  • Auparavant, lors de l'exécution d'un balayage, une fin inattendue se produisait dans l'un des conteneurs de balayage des pods. Dans cette version, l'opérateur de conformité utilise la dernière version d'OpenSCAP 1.3.5 pour éviter un crash.
  • Auparavant, l'utilisation de autoReplyRemediations pour appliquer des mesures correctives déclenchait une mise à jour des nœuds du cluster. Cette opération était gênante si certaines mesures correctives n'incluaient pas toutes les variables d'entrée requises. Désormais, s'il manque à une remédiation une ou plusieurs variables d'entrée requises, elle se voit attribuer l'état NeedsReview. Si une ou plusieurs remédiations sont dans l'état NeedsReview, le pool de configuration de la machine reste en pause et les remédiations ne sont pas appliquées tant que toutes les variables requises n'ont pas été définies. Cela permet de minimiser les perturbations sur les nœuds.
  • Le rôle RBAC et le Role Binding utilisés pour les métriques Prometheus sont remplacés par 'ClusterRole' et 'ClusterRoleBinding' afin de garantir que la surveillance fonctionne sans personnalisation.
  • Auparavant, si une erreur survenait lors de l'analyse d'un profil, les objets règles ou variables étaient retirés et supprimés du profil. Désormais, si une erreur se produit pendant l'analyse, le site profileparser annote l'objet avec une annotation temporaire qui empêche la suppression de l'objet jusqu'à la fin de l'analyse. (BZ#1988259)
  • Auparavant, une erreur se produisait si les titres ou les descriptions étaient absents d'un profil personnalisé. La norme XCCDF exigeant des titres et des descriptions pour les profils personnalisés, les titres et les descriptions doivent désormais être définis dans les CR de TailoredProfile.
  • Auparavant, lors de l'utilisation de profils personnalisés, les valeurs des variables TailoredProfile ne pouvaient être définies qu'à l'aide d'un ensemble de sélection spécifique. Cette restriction est désormais supprimée et les variables TailoredProfile peuvent être réglées sur n'importe quelle valeur.

5.1.11. Notes de publication pour Compliance Operator 0.1.39

L'avis suivant est disponible pour l'OpenShift Compliance Operator 0.1.39 :

5.1.11.1. Nouvelles fonctionnalités et améliorations

  • Auparavant, l'opérateur de conformité n'était pas en mesure d'analyser les références à la norme de sécurité des données de l'industrie des cartes de paiement (PCI DSS). Désormais, l'opérateur peut analyser le contenu de conformité fourni avec les profils PCI DSS.
  • Auparavant, l'Opérateur de Conformité n'était pas en mesure d'exécuter les règles pour le contrôle de l'AU-5 dans le profil modéré. Désormais, l'opérateur dispose d'une autorisation lui permettant de lire les objets Prometheusrules.monitoring.coreos.com et d'exécuter les règles qui couvrent le contrôle de l'AU-5 dans le profil modéré.

5.1.12. Ressources supplémentaires

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.

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 leBlog 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.

© 2024 Red Hat, Inc.