Les conteneurs regroupent une application et toutes ses dépendances dans une image unique qui peut passer du développement au test, puis à la production, sans changement. Un conteneur peut faire partie d'une application plus vaste qui travaille en étroite collaboration avec d'autres conteneurs.

Les conteneurs assurent la cohérence entre les environnements et les cibles de déploiement multiples : serveurs physiques, machines virtuelles (VM) et nuages privés ou publics.

Voici quelques-uns des avantages de l'utilisation de conteneurs :

Pour en savoir plus sur les conteneurs Linux, consultez la section Comprendre les conteneurs Linux du portail client Red Hat. Pour en savoir plus sur les outils de conteneur RHEL, voir Construire, exécuter et gérer des conteneurs dans la documentation produit RHEL.

L'automatisation du déploiement, de l'exécution et de la gestion des applications conteneurisées est le travail d'une plateforme telle qu'OpenShift Container Platform. À la base, OpenShift Container Platform s'appuie sur le projet Kubernetes pour fournir le moteur d'orchestration des conteneurs sur de nombreux nœuds dans des centres de données évolutifs.

Kubernetes est un projet qui peut fonctionner avec différents systèmes d'exploitation et des composants complémentaires qui n'offrent aucune garantie de prise en charge par le projet. Par conséquent, la sécurité des différentes plateformes Kubernetes peut varier.

OpenShift Container Platform est conçu pour verrouiller la sécurité de Kubernetes et intégrer la plateforme avec une variété de composants étendus. Pour ce faire, OpenShift Container Platform s'appuie sur le vaste écosystème Red Hat de technologies open source qui comprend les systèmes d'exploitation, l'authentification, le stockage, la mise en réseau, les outils de développement, les images de conteneurs de base et de nombreux autres composants.

OpenShift Container Platform peut tirer parti de l'expérience de Red Hat dans la découverte et le déploiement rapide de correctifs pour les vulnérabilités dans la plateforme elle-même ainsi que dans les applications conteneurisées fonctionnant sur la plateforme. L'expérience de Red Hat s'étend également à l'intégration efficace de nouveaux composants à OpenShift Container Platform au fur et à mesure de leur disponibilité et à l'adaptation des technologies aux besoins individuels des clients.

Les conteneurs simplifient le déploiement de nombreuses applications sur le même hôte, en utilisant le même noyau et le même moteur d'exécution pour chaque conteneur. Les applications peuvent appartenir à de nombreux utilisateurs et, parce qu'elles sont séparées, elles peuvent fonctionner simultanément avec des versions différentes, voire incompatibles, de ces applications sans aucun problème.

Dans Linux, les conteneurs ne sont qu'un type spécial de processus, de sorte que la sécurisation des conteneurs est similaire à bien des égards à la sécurisation de n'importe quel autre processus en cours d'exécution. Un environnement pour l'exécution de conteneurs commence par un système d'exploitation capable de sécuriser le noyau de l'hôte vis-à-vis des conteneurs et des autres processus s'exécutant sur l'hôte, ainsi que de sécuriser les conteneurs les uns vis-à-vis des autres.

Étant donné qu'OpenShift Container Platform 4.12 fonctionne sur des hôtes RHCOS, avec la possibilité d'utiliser Red Hat Enterprise Linux (RHEL) comme nœuds de travail, les concepts suivants s'appliquent par défaut à tout cluster OpenShift Container Platform déployé. Ces fonctionnalités de sécurité RHEL sont au cœur de ce qui rend l'exécution de conteneurs dans OpenShift Container Platform plus sûre :

RHCOS est une version de Red Hat Enterprise Linux (RHEL) spécialement configurée pour fonctionner en tant que plan de contrôle (maître) et nœuds de travail sur les clusters OpenShift Container Platform. RHCOS est donc réglé pour exécuter efficacement les charges de travail de conteneurs, ainsi que les services Kubernetes et OpenShift Container Platform.

Pour mieux protéger les systèmes RHCOS dans les clusters OpenShift Container Platform, la plupart des conteneurs, à l'exception de ceux qui gèrent ou surveillent le système hôte lui-même, doivent s'exécuter en tant qu'utilisateur non root. L'abaissement du niveau de privilège ou la création de conteneurs avec le moins de privilèges possible est la meilleure pratique recommandée pour protéger vos propres clusters OpenShift Container Platform.

La virtualisation traditionnelle offre un autre moyen de séparer les environnements d'application sur le même hôte physique. Cependant, les machines virtuelles fonctionnent différemment des conteneurs. La virtualisation repose sur un hyperviseur qui fait tourner des machines virtuelles invitées (VM), chacune d'entre elles ayant son propre système d'exploitation (OS), représenté par un noyau en cours d'exécution, ainsi que l'application en cours d'exécution et ses dépendances.

Avec les VM, l'hyperviseur isole les invités les uns des autres et du noyau hôte. Moins de personnes et de processus ont accès à l'hyperviseur, ce qui réduit la surface d'attaque sur le serveur physique. Cela dit, la sécurité doit toujours être surveillée : une VM invitée pourrait être en mesure d'utiliser les bogues de l'hyperviseur pour accéder à une autre VM ou au noyau hôte. Et lorsque le système d'exploitation doit être corrigé, il doit l'être sur toutes les machines virtuelles invitées qui l'utilisent.

Les conteneurs peuvent être exécutés à l'intérieur de machines virtuelles invitées, et il peut y avoir des cas d'utilisation où cela est souhaitable. Par exemple, vous pouvez déployer une application traditionnelle dans un conteneur, peut-être pour transférer une application dans le nuage.

La séparation des conteneurs sur un seul hôte offre toutefois une solution de déploiement plus légère, plus flexible et plus facile à mettre à l'échelle. Ce modèle de déploiement est particulièrement adapté aux applications "cloud-native". Les conteneurs sont généralement beaucoup plus petits que les VM et consomment moins de mémoire et de CPU.

Voir Linux Containers Compared to KVM Virtualization dans la documentation sur les conteneurs de RHEL 7 pour en savoir plus sur les différences entre les conteneurs et les machines virtuelles.

Lorsque vous déployez OpenShift Container Platform, vous avez le choix entre une infrastructure fournie par l'installateur (il existe plusieurs plateformes disponibles) et votre propre infrastructure fournie par l'utilisateur. Certaines configurations de bas niveau liées à la sécurité, telles que l'activation de la conformité FIPS ou l'ajout de modules de noyau requis au premier démarrage, peuvent bénéficier d'une infrastructure fournie par l'utilisateur. De même, l'infrastructure fournie par l'utilisateur est appropriée pour les déploiements déconnectés d'OpenShift Container Platform.

Gardez à l'esprit que, lorsqu'il s'agit d'apporter des améliorations de sécurité et d'autres changements de configuration à OpenShift Container Platform, les objectifs doivent inclure :

Pour atteindre ces objectifs, la plupart des modifications de nœuds doivent être effectuées lors de l'installation par Ignition ou ultérieurement à l'aide de MachineConfigs qui sont appliquées à des ensembles de nœuds par l'opérateur de configuration de la machine. Voici quelques exemples de modifications de configuration liées à la sécurité que vous pouvez effectuer de cette manière :

En plus de l'opérateur de configuration des machines, il existe plusieurs autres opérateurs disponibles pour configurer l'infrastructure d'OpenShift Container Platform qui sont gérés par l'opérateur de version de cluster (CVO). Le CVO est capable d'automatiser de nombreux aspects des mises à jour des clusters d'OpenShift Container Platform.

Le guide de renforcement de la sécurité de RHEL 8 décrit la manière dont vous devez aborder la sécurité pour tout système RHEL.

Ce guide vous explique comment aborder la cryptographie, évaluer les vulnérabilités et les menaces qui pèsent sur différents services. De même, vous apprendrez à analyser les normes de conformité, à vérifier l'intégrité des fichiers, à effectuer des audits et à chiffrer les périphériques de stockage.

Si vous savez quelles caractéristiques vous souhaitez renforcer, vous pouvez alors décider de la manière de les renforcer dans le RHCOS.

La modification directe des systèmes RHCOS dans OpenShift Container Platform est déconseillée. Il faut plutôt penser à modifier les systèmes dans des pools de nœuds, tels que les nœuds de travail et les nœuds de plan de contrôle. Lorsqu'un nouveau nœud est nécessaire, dans les installations non bare metal, vous pouvez demander un nouveau nœud du type que vous souhaitez et il sera créé à partir d'une image RHCOS plus les modifications que vous avez créées précédemment.

Il est possible de modifier RHCOS avant l'installation, pendant l'installation et une fois que le cluster est opérationnel.

L'activation de la validation des signatures de conteneurs pour les registres de conteneurs Red Hat nécessite l'écriture d'un fichier de politique de vérification des signatures spécifiant les clés pour vérifier les images à partir de ces registres. Pour les nœuds RHEL8, les registres sont déjà définis par défaut dans /etc/containers/registries.d.

Après avoir appliqué les configurations de machine au cluster, le Machine Config Controller détecte le nouvel objet MachineConfig et génère une nouvelle version de rendered-worker-<hash>.

La conformité FIPS est l'un des éléments les plus critiques requis dans les environnements hautement sécurisés, afin de garantir que seules les technologies cryptographiques prises en charge sont autorisées sur les nœuds.

Pour comprendre le point de vue de Red Hat sur les cadres de conformité d'OpenShift Container Platform, reportez-vous au chapitre Gestion des risques et préparation aux réglementations du livre-guide sur la sécurité d'OpenShift.

Les applications et les infrastructures sont composées d'éléments facilement disponibles, dont beaucoup sont des logiciels libres tels que le système d'exploitation Linux, JBoss Web Server, PostgreSQL et Node.js.

Des versions conteneurisées de ces paquets sont également disponibles. Cependant, vous devez savoir d'où proviennent les paquets, quelles sont les versions utilisées, qui les a construits et s'ils contiennent du code malveillant.

Voici quelques questions auxquelles il faut répondre :

En construisant vos conteneurs à partir des images de base universelles de Red Hat (UBI), vous êtes assuré d'avoir une base pour vos images de conteneurs qui consiste en les mêmes logiciels emballés par RPM que ceux inclus dans Red Hat Enterprise Linux. Aucun abonnement n'est nécessaire pour utiliser ou redistribuer les images UBI.

Pour assurer la sécurité continue des conteneurs eux-mêmes, les fonctions d'analyse de sécurité, utilisées directement à partir de RHEL ou ajoutées à OpenShift Container Platform, peuvent vous alerter lorsqu'une image que vous utilisez présente des vulnérabilités. L'analyse d'image OpenSCAP est disponible dans RHEL et Red Hat Quay Container Security Operator peut être ajouté pour vérifier les images de conteneurs utilisées dans OpenShift Container Platform.

Pour créer des applications conteneurisées, vous commencez généralement par une image de base fiable qui offre les composants habituellement fournis par le système d'exploitation. Il s'agit notamment des bibliothèques, des utilitaires et des autres fonctionnalités que l'application s'attend à trouver dans le système de fichiers du système d'exploitation.

Les images de base universelles de Red Hat (UBI) ont été créées pour encourager toute personne construisant ses propres conteneurs à commencer par une image entièrement constituée de paquets rpm Red Hat Enterprise Linux et d'autres contenus. Ces images UBI sont régulièrement mises à jour pour tenir compte des correctifs de sécurité et sont libres d'utilisation et de redistribution avec des images de conteneurs construites pour inclure vos propres logiciels.

Effectuez une recherche dans le catalogue de l'écosystème Red Hat pour trouver et vérifier l'état de différentes images UBI. En tant que créateur d'images de conteneurs sécurisés, vous pourriez être intéressé par ces deux types généraux d'images UBI :

Gardez à l'esprit que si les images UBI sont librement disponibles et redistribuables, la prise en charge de ces images par Red Hat n'est disponible que par le biais d'abonnements aux produits Red Hat.

Voir Utilisation des images de base universelles de Red Hat dans la documentation de Red Hat Enterprise Linux pour obtenir des informations sur la manière d'utiliser et de construire sur des images UBI standard, minimales et init.

Pour les systèmes Red Hat Enterprise Linux (RHEL), l'analyse OpenSCAP est disponible à partir du paquetage openscap-utils. Dans RHEL, vous pouvez utiliser la commande openscap-podman pour rechercher les vulnérabilités dans les images. Voir Recherche de vulnérabilités dans les conteneurs et les images de conteneurs dans la documentation de Red Hat Enterprise Linux.

OpenShift Container Platform vous permet d'exploiter les scanners RHEL dans le cadre de votre processus CI/CD. Par exemple, vous pouvez intégrer des outils d'analyse statique du code qui testent les failles de sécurité dans votre code source et des outils d'analyse de la composition des logiciels qui identifient les bibliothèques open source afin de fournir des métadonnées sur ces bibliothèques, telles que les vulnérabilités connues.

OpenShift Container Platform utilise les annotations d'objets pour étendre les fonctionnalités. Les outils externes, tels que les scanners de vulnérabilité, peuvent annoter les objets image avec des métadonnées pour résumer les résultats et contrôler l'exécution du pod. Cette section décrit le format reconnu de cette annotation afin qu'elle puisse être utilisée de manière fiable dans les consoles pour afficher des données utiles aux utilisateurs.

quality.images.openshift.io/<qualityType>.<providerId> : {}

quality.images.openshift.io/vulnerability.blackduck: {}
quality.images.openshift.io/vulnerability.jfrog: {}
quality.images.openshift.io/license.blackduck: {}
quality.images.openshift.io/vulnerability.openscap: {}

{
  "name": "OpenSCAP",
  "description": "OpenSCAP vulnerability score",
  "timestamp": "2016-09-08T05:04:46Z",
  "reference": "https://www.open-scap.org/930492",
  "compliant": true,
  "scannerVersion": "1.2",
  "summary": [
    { "label": "critical", "data": "4", "severityIndex": 3, "reference": null },
    { "label": "important", "data": "12", "severityIndex": 2, "reference": null },
    { "label": "moderate", "data": "8", "severityIndex": 1, "reference": null },
    { "label": "low", "data": "26", "severityIndex": 0, "reference": null }
  ]
}

{
  "name": "Red Hat Ecosystem Catalog",
  "description": "Container health index",
  "timestamp": "2016-09-08T05:04:46Z",
  "reference": "https://access.redhat.com/errata/RHBA-2016:1566",
  "compliant": null,
  "scannerVersion": "1.2",
  "summary": [
    { "label": "Health index", "data": "B", "severityIndex": 1, "reference": null }
  ]
}

$ oc annotate image <image> \
    quality.images.openshift.io/vulnerability.redhatcatalog='{ \
    "name": "Red Hat Ecosystem Catalog", \
    "description": "Container health index", \
    "timestamp": "2020-06-01T05:04:46Z", \
    "compliant": null, \
    "scannerVersion": "1.2", \
    "reference": "https://access.redhat.com/errata/RHBA-2020:2347", \
    "summary": "[ \
      { "label": "Health index", "data": "B", "severityIndex": 1, "reference": null } ]" }'

annotations:
  images.openshift.io/deny-execution: true

$ curl -X PATCH \
  -H "Authorization: Bearer <token>" \
  -H "Content-Type: application/merge-patch+json" \
  https://<openshift_server>:6443/apis/image.openshift.io/v1/images/<image_id> \
  --data '{ <image_annotation> }'

{
"metadata": {
  "annotations": {
    "quality.images.openshift.io/vulnerability.redhatcatalog":
       "{ 'name': 'Red Hat Ecosystem Catalog', 'description': 'Container health index', 'timestamp': '2020-06-01T05:04:46Z', 'compliant': null, 'reference': 'https://access.redhat.com/errata/RHBA-2020:2347', 'summary': [{'label': 'Health index', 'data': '4', 'severityIndex': 1, 'reference': null}] }"
    }
  }
}

Il existe des outils que vous pouvez utiliser pour analyser et suivre le contenu de vos images de conteneurs téléchargées et déployées. Cependant, il existe de nombreuses sources publiques d'images de conteneurs. Lorsque vous utilisez des registres de conteneurs publics, vous pouvez ajouter une couche de protection en utilisant des sources fiables.

La consommation des mises à jour de sécurité est particulièrement importante lors de la gestion de immutable containers. Les conteneurs immuables sont des conteneurs qui ne seront jamais modifiés en cours d'exécution. Lorsque vous déployez des conteneurs immuables, vous n'intervenez pas dans le conteneur en cours d'exécution pour remplacer un ou plusieurs binaires. D'un point de vue opérationnel, vous reconstruisez et redéployez une image de conteneur mise à jour pour remplacer un conteneur au lieu de le modifier.

Les images certifiées par Red Hat sont les suivantes :

La liste des vulnérabilités connues est en constante évolution, vous devez donc suivre le contenu de vos images de conteneurs déployées, ainsi que les images nouvellement téléchargées, au fil du temps. Vous pouvez utiliser les Red Hat Security Advisories (RHSA ) pour vous avertir de tout problème récemment découvert dans les images de conteneurs certifiées par Red Hat, et vous diriger vers l'image mise à jour. Vous pouvez également consulter le catalogue de l'écosystème Red Hat pour rechercher ces problèmes et d'autres problèmes liés à la sécurité pour chaque image Red Hat.

Red Hat répertorie les images de conteneurs certifiées pour les produits Red Hat et les offres des partenaires dans la section Images de conteneurs du catalogue de l'écosystème Red Hat. À partir de ce catalogue, vous pouvez voir les détails de chaque image, y compris le CVE, les listes de paquets logiciels et les scores de santé.

Les images Red Hat sont en fait stockées dans ce que l'on appelle le Red Hat Registry, qui est représenté par un registre de conteneurs public (registry.access.redhat.com) et un registre authentifié (registry.redhat.io). Les deux comprennent fondamentalement le même ensemble d'images de conteneurs, registry.redhat.io comprenant quelques images supplémentaires qui nécessitent une authentification avec les informations d'identification de l'abonnement Red Hat.

Le contenu des conteneurs est surveillé par Red Hat pour détecter les vulnérabilités et est mis à jour régulièrement. Lorsque Red Hat publie des mises à jour de sécurité, telles que des correctifs pour glibc, DROWN, ou Dirty Cow, toutes les images de conteneurs affectées sont également reconstruites et poussées vers le Red Hat Registry.

Red Hat utilise une adresse health index pour refléter le risque de sécurité de chaque conteneur fourni par le catalogue de l'écosystème Red Hat. Étant donné que les conteneurs consomment des logiciels fournis par Red Hat et le processus d'errata, les conteneurs anciens et périmés ne sont pas sûrs, tandis que les nouveaux conteneurs sont plus sûrs.

Pour illustrer l'âge des conteneurs, le Red Hat Ecosystem Catalog utilise un système de classement. Une note de fraîcheur est une mesure des errata de sécurité les plus anciens et les plus graves disponibles pour une image. \L'image "A" est plus à jour que l'image "F". Voir les notes de l'Indice de santé des conteneurs utilisées dans le Catalogue de l'écosystème Red Hat pour plus de détails sur ce système de notation.

Consultez le Centre de sécurité des produits Red Hat pour obtenir des détails sur les mises à jour de sécurité et les vulnérabilités liées aux logiciels Red Hat. Consultez les avis de sécurité de Red Hat pour rechercher des avis spécifiques et des CVE.

OpenShift Container Platform inclut OpenShift Container Registry, un registre privé fonctionnant comme un composant intégré de la plateforme que vous pouvez utiliser pour gérer vos images de conteneurs. L'OpenShift Container Registry fournit des contrôles d'accès basés sur les rôles qui vous permettent de gérer qui peut tirer et pousser quelles images de conteneurs.

OpenShift Container Platform prend également en charge l'intégration avec d'autres registres privés que vous utilisez peut-être déjà, tels que Red Hat Quay.

Red Hat Quay est un produit de registre de conteneurs de qualité professionnelle de Red Hat. Le développement de Red Hat Quay se fait par le biais du projet Quay en amont. Red Hat Quay peut être déployé sur site ou via la version hébergée de Red Hat Quay sur Quay.io.

Les fonctionnalités de Red Hat Quay relatives à la sécurité sont les suivantes :

L'intégration de Red Hat Quay avec OpenShift Container Platform se poursuit, avec plusieurs opérateurs OpenShift Container Platform particulièrement intéressants. L'opérateur Quay Bridge vous permet de remplacer le registre d'images interne d'OpenShift par Red Hat Quay. L'opérateur Red Hat Quay Container Security Operator vous permet de vérifier les vulnérabilités des images exécutées dans OpenShift Container Platform qui ont été extraites des registres Red Hat Quay.

L'utilisation d'OpenShift Container Platform comme plateforme standard pour les constructions de conteneurs vous permet de garantir la sécurité de l'environnement de construction. L'adhésion à la philosophie "construire une fois, déployer partout" permet de s'assurer que le produit du processus de construction est exactement ce qui est déployé en production.

Il est également important de maintenir l'immuabilité de vos conteneurs. Vous ne devez pas patcher les conteneurs en cours d'exécution, mais les reconstruire et les redéployer.

Au fur et à mesure que votre logiciel passe par les étapes de construction, de test et de production, il est important que les outils qui composent votre chaîne d'approvisionnement en logiciels soient fiables. La figure suivante illustre le processus et les outils qui pourraient être incorporés dans une chaîne d'approvisionnement de logiciels de confiance pour les logiciels conteneurisés :

OpenShift Container Platform peut être intégrée à des référentiels de code fiables (tels que GitHub) et à des plateformes de développement (telles que Che) pour créer et gérer du code sécurisé. Les tests unitaires peuvent s'appuyer sur Cucumber et JUnit. Vous pouvez inspecter vos conteneurs pour détecter les vulnérabilités et les problèmes de conformité avec Anchore ou Twistlock, et utiliser des outils d'analyse d'images tels qu'AtomicScan ou Clair. Des outils tels que Sysdig peuvent assurer une surveillance continue de vos applications conteneurisées.

Vous pouvez utiliser Source-to-Image (S2I) pour combiner le code source et les images de base. Builder images utilise S2I pour permettre à vos équipes de développement et d'exploitation de collaborer sur un environnement de construction reproductible. Avec les images S2I de Red Hat disponibles en tant qu'images de base universelles (UBI), vous pouvez désormais redistribuer librement vos logiciels avec des images de base construites à partir de véritables paquets RHEL RPM. Red Hat a supprimé les restrictions d'abonnement pour permettre cela.

Lorsque les développeurs livrent du code avec Git pour une application utilisant des images de construction, OpenShift Container Platform peut exécuter les fonctions suivantes :

Vous pouvez utiliser le registre intégré OpenShift Container Registry pour gérer l'accès aux images finales. Les images S2I et les images natives sont automatiquement poussées vers votre OpenShift Container Registry.

En plus de Jenkins for CI, vous pouvez également intégrer votre propre environnement de construction et de CI à OpenShift Container Platform à l'aide d'API RESTful, ainsi qu'utiliser n'importe quel registre d'images compatible avec l'API.

Dans certains cas, les opérations de compilation nécessitent des informations d'identification pour accéder à des ressources dépendantes, mais il n'est pas souhaitable que ces informations d'identification soient disponibles dans l'image finale de l'application produite par la compilation. Vous pouvez définir des secrets d'entrée à cette fin.

Par exemple, lorsque vous créez une application Node.js, vous pouvez configurer votre miroir privé pour les modules Node.js. Pour télécharger des modules à partir de ce miroir privé, vous devez fournir un fichier .npmrc personnalisé pour la construction qui contient une URL, un nom d'utilisateur et un mot de passe. Pour des raisons de sécurité, vous ne devez pas exposer vos informations d'identification dans l'image de l'application.

Dans cet exemple, vous pouvez ajouter un secret de saisie à un nouvel objet BuildConfig:

Vous pouvez concevoir votre gestion d'image de conteneur et votre processus de construction pour utiliser des couches de conteneur afin de pouvoir séparer le contrôle.

Par exemple, une équipe d'exploitation gère les images de base, tandis que les architectes gèrent les logiciels intermédiaires, les moteurs d'exécution, les bases de données et d'autres solutions. Les développeurs peuvent alors se concentrer sur les couches applicatives et sur l'écriture du code.

Comme de nouvelles vulnérabilités sont identifiées chaque jour, vous devez vérifier de manière proactive le contenu des conteneurs au fil du temps. Pour ce faire, vous devez intégrer des tests de sécurité automatisés dans votre processus de construction ou d'intégration. Par exemple :

Votre processus d'intégration des données doit inclure des politiques qui signalent les constructions présentant des problèmes découverts par les analyses de sécurité, afin que votre équipe puisse prendre les mesures appropriées pour résoudre ces problèmes. Vous devez signer vos conteneurs personnalisés pour vous assurer que rien n'est altéré entre la construction et le déploiement.

En utilisant la méthodologie GitOps, vous pouvez utiliser les mêmes mécanismes CI/CD pour gérer non seulement les configurations de vos applications, mais aussi votre infrastructure OpenShift Container Platform.

En s'appuyant sur Kubernetes et Kourier, vous pouvez construire, déployer et gérer des applications sans serveur en utilisant OpenShift Serverless dans OpenShift Container Platform.

Comme pour les autres builds, vous pouvez utiliser les images S2I pour construire vos conteneurs, puis les servir à l'aide des services Knative. Visualisez les builds d'applications Knative via la vue Topology de la console web OpenShift Container Platform.

Si quelque chose se produit au cours du processus de construction, ou si une vulnérabilité est découverte après le déploiement d'une image, vous pouvez utiliser des outils pour un déploiement automatisé, basé sur des règles, afin de remédier à la situation. Vous pouvez utiliser des déclencheurs pour reconstruire et remplacer les images, en garantissant le processus de conteneurs immuables, au lieu de patcher les conteneurs en cours d'exécution, ce qui n'est pas recommandé.

Par exemple, vous construisez une application en utilisant trois couches d'images de conteneurs : le noyau, l'intergiciel et les applications. Un problème est découvert dans l'image core et cette image est reconstruite. Une fois la construction terminée, l'image est poussée vers votre OpenShift Container Registry. OpenShift Container Platform détecte que l'image a changé et reconstruit et déploie automatiquement l'image de l'application, en fonction des déclencheurs définis. Ce changement incorpore les bibliothèques corrigées et garantit que le code de production est identique à l'image la plus récente.

Vous pouvez utiliser la commande oc set triggers pour définir un déclencheur de déploiement. Par exemple, pour définir un déclencheur de déploiement appelé déploiement-exemple :

$ oc set triggers deploy/deployment-example \
    --from-image=example:latest \
    --containers=web

Il est important que les images prévues soient effectivement déployées, que les images et leur contenu proviennent de sources fiables et qu'elles n'aient pas été modifiées. La signature cryptographique fournit cette assurance. OpenShift Container Platform permet aux administrateurs de clusters d'appliquer une politique de sécurité plus ou moins large, en fonction de l'environnement de déploiement et des exigences de sécurité. Deux paramètres définissent cette politique :

Vous pouvez utiliser ces paramètres de stratégie pour autoriser, refuser ou exiger une relation de confiance pour des registres entiers, des parties de registres ou des images individuelles. En utilisant des clés publiques de confiance, vous pouvez vous assurer que la source est vérifiée cryptographiquement. Les règles de stratégie s'appliquent aux nœuds. La stratégie peut être appliquée uniformément à tous les nœuds ou ciblée en fonction des charges de travail des différents nœuds (par exemple, construction, zone ou environnement).

{
    "default": [{"type": "reject"}],
    "transports": {
        "docker": {
            "access.redhat.com": [
                {
                    "type": "signedBy",
                    "keyType": "GPGKeys",
                    "keyPath": "/etc/pki/rpm-gpg/RPM-GPG-KEY-redhat-release"
                }
            ]
        },
        "atomic": {
            "172.30.1.1:5000/openshift": [
                {
                    "type": "signedBy",
                    "keyType": "GPGKeys",
                    "keyPath": "/etc/pki/rpm-gpg/RPM-GPG-KEY-redhat-release"
                }
            ],
            "172.30.1.1:5000/production": [
                {
                    "type": "signedBy",
                    "keyType": "GPGKeys",
                    "keyPath": "/etc/pki/example.com/pubkey"
                }
            ],
            "172.30.1.1:5000": [{"type": "reject"}]
        }
    }
}

La politique peut être enregistrée sur un nœud sous le nom de /etc/containers/policy.json. La meilleure façon d'enregistrer ce fichier sur un nœud est d'utiliser un nouvel objet MachineConfig. Cet exemple applique les règles suivantes :

Un transport de signature est un moyen de stocker et de récupérer le blob de signature binaire. Il existe deux types de transport de signature.

L'API OpenShift Container Platform gère les signatures qui utilisent le type de transport atomic. Vous devez stocker les images qui utilisent ce type de signature dans votre OpenShift Container Registry. Comme l'API docker/distribution extensions découvre automatiquement le point de terminaison de la signature de l'image, aucune configuration supplémentaire n'est nécessaire.

Les signatures qui utilisent le type de transport docker sont servies par un serveur de fichiers ou un serveur web local. Ces signatures sont plus souples ; vous pouvez servir des images à partir de n'importe quel registre d'images de conteneurs et utiliser un serveur indépendant pour fournir des signatures binaires.

Cependant, le type de transport docker nécessite une configuration supplémentaire. Vous devez configurer les nœuds avec l'URI du serveur de signatures en plaçant des fichiers YAML aux noms arbitraires dans un répertoire du système hôte, /etc/containers/registries.d par défaut. Les fichiers de configuration YAML contiennent un URI de registre et un URI de serveur de signatures, ou sigstore:

docker:
    access.redhat.com:
        sigstore: https://access.redhat.com/webassets/docker/content/sigstore

Dans cet exemple, le Red Hat Registry, access.redhat.com, est le serveur de signatures qui fournit des signatures pour le type de transport docker. Son URI est défini dans le paramètre sigstore. Vous pouvez nommer ce fichier /etc/containers/registries.d/redhat.com.yaml et utiliser l'opérateur Machine Config pour placer automatiquement le fichier sur chaque nœud de votre cluster. Aucun redémarrage de service n'est nécessaire puisque les fichiers Policy et registries.d sont chargés dynamiquement par le runtime du conteneur.

Le type d'objet Secret fournit un mécanisme pour contenir des informations sensibles telles que les mots de passe, les fichiers de configuration du client OpenShift Container Platform, les fichiers dockercfg et les informations d'identification du référentiel source privé. Les secrets découplent le contenu sensible des pods. Vous pouvez monter des secrets dans des conteneurs à l'aide d'un plugin de volume ou le système peut utiliser des secrets pour effectuer des actions au nom d'un pod.

Par exemple, pour ajouter un secret à votre configuration de déploiement afin qu'il puisse accéder à un référentiel d'images privé, procédez comme suit :

Les cartes de configuration sont similaires aux secrets, mais elles sont conçues pour permettre de travailler avec des chaînes qui ne contiennent pas d'informations sensibles. L'objet ConfigMap contient des paires clé-valeur de données de configuration qui peuvent être consommées dans des pods ou utilisées pour stocker des données de configuration pour des composants du système tels que les contrôleurs.

Vous pouvez intégrer votre propre outil de déploiement continu (CD) à OpenShift Container Platform.

En tirant parti de CI/CD et d'OpenShift Container Platform, vous pouvez automatiser le processus de reconstruction de l'application afin d'intégrer les dernières corrections, de tester et de veiller à ce qu'elle soit déployée partout dans l'environnement.

La multitenance permet aux applications d'un cluster OpenShift Container Platform appartenant à plusieurs utilisateurs et s'exécutant sur plusieurs hôtes et espaces de noms de rester isolées les unes des autres et des attaques extérieures. Vous obtenez la multitenance en appliquant le contrôle d'accès basé sur les rôles (RBAC) aux espaces de noms Kubernetes.

Dans Kubernetes, namespaces sont des zones où les applications peuvent s'exécuter de manière distincte des autres applications. OpenShift Container Platform utilise et étend les espaces de noms en ajoutant des annotations supplémentaires, y compris l'étiquetage MCS dans SELinux, et en identifiant ces espaces de noms étendus comme projects. Dans le cadre d'un projet, les utilisateurs peuvent gérer leurs propres ressources de cluster, y compris les comptes de service, les politiques, les contraintes et divers autres objets.

Les objets RBAC sont assignés aux projets afin d'autoriser les utilisateurs sélectionnés à accéder à ces projets. Cette autorisation prend la forme de règles, de rôles et de liaisons :

Les rôles et fixations RBAC locaux rattachent un utilisateur ou un groupe à un projet particulier. Le système RBAC de grappe permet d'attribuer des rôles et des liaisons à l'échelle de la grappe à tous les projets de la grappe. Il existe des rôles de cluster par défaut qui peuvent être attribués pour fournir un accès à admin, basic-user, cluster-admin et cluster-status.

Alors que RBAC contrôle les règles d'accès entre les utilisateurs, les groupes et les projets disponibles, admission plugins définit l'accès à l'API principale d'OpenShift Container Platform. Les plugins d'admission forment une chaîne de règles qui se compose de :

Les demandes d'API passent par les modules d'admission en chaîne, tout échec en cours de route entraînant le rejet de la demande. Chaque plugin d'admission est associé à des ressources particulières et ne répond qu'aux demandes concernant ces ressources.

OpenShift Container Platform a plusieurs composants dans son cadre qui utilisent la communication HTTPS basée sur REST en tirant parti du cryptage via des certificats TLS. Le programme d'installation d'OpenShift Container Platform configure ces certificats lors de l'installation. Certains composants principaux génèrent ce trafic :

OpenShift Container Platform utilise un réseau défini par logiciel (SDN) pour fournir un réseau de cluster unifié qui permet la communication entre les conteneurs à travers le cluster.

Le mode stratégie réseau, par défaut, rend tous les pods d'un projet accessibles aux autres pods et aux points d'extrémité du réseau. Pour isoler un ou plusieurs pods dans un projet, vous pouvez créer des objets NetworkPolicy dans ce projet pour indiquer les connexions entrantes autorisées. En utilisant le mode multitenant, vous pouvez fournir une isolation au niveau du projet pour les pods et les services.

En utilisant network policies, vous pouvez isoler les pods les uns des autres dans le même projet. Les stratégies de réseau peuvent refuser tout accès réseau à un module, n'autoriser que les connexions pour le contrôleur d'entrée, rejeter les connexions des modules dans d'autres projets, ou définir des règles similaires pour le comportement des réseaux.

Chaque conteneur en cours d'exécution n'a qu'une seule interface réseau par défaut. Le plugin CNI de Multus vous permet de créer plusieurs réseaux CNI, puis d'attacher n'importe lequel de ces réseaux à vos pods. De cette façon, vous pouvez faire des choses comme séparer les données privées sur un réseau plus restreint et avoir plusieurs interfaces réseau sur chaque nœud.

OpenShift Container Platform vous permet de segmenter le trafic réseau sur un seul cluster pour créer des clusters multitenant qui isolent les utilisateurs, les équipes, les applications et les environnements des ressources non globales.

La configuration de l'accès à vos services Kubernetes depuis l'extérieur de votre cluster OpenShift Container Platform a de nombreuses implications en termes de sécurité. Outre l'exposition des routes HTTP et HTTPS, le routage d'entrée vous permet de configurer les types d'entrée NodePort ou LoadBalancer. NodePort expose l'objet API de service d'une application à partir de chaque travailleur du cluster. LoadBalancer vous permet d'affecter un équilibreur de charge externe à un objet API de service associé dans votre cluster OpenShift Container Platform.

OpenShift Container Platform permet de contrôler le trafic de sortie à l'aide d'un routeur ou d'un pare-feu. Par exemple, vous pouvez utiliser la liste blanche d'IP pour contrôler l'accès à la base de données. Un administrateur de cluster peut attribuer une ou plusieurs adresses IP de sortie à un projet dans un fournisseur de réseau SDN OpenShift Container Platform. De même, un administrateur de cluster peut empêcher le trafic egress de sortir d'un cluster OpenShift Container Platform à l'aide d'un pare-feu egress.

En attribuant une adresse IP de sortie fixe, vous pouvez affecter tout le trafic sortant à cette adresse IP pour un projet particulier. Avec le pare-feu de sortie, vous pouvez empêcher un pod de se connecter à un réseau externe, empêcher un pod de se connecter à un réseau interne ou limiter l'accès d'un pod à des sous-réseaux internes spécifiques.

Les conteneurs sont utiles pour les applications avec ou sans état. La protection du stockage attaché est un élément clé de la sécurisation des services avec état. En utilisant l'interface de stockage des conteneurs (CSI), OpenShift Container Platform peut incorporer le stockage à partir de n'importe quel back-end de stockage qui prend en charge l'interface CSI.

OpenShift Container Platform propose des plugins pour plusieurs types de stockage, notamment :

Les plugins pour les types de stockage avec provisionnement dynamique sont marqués d'un astérisque (*). Les données en transit sont chiffrées via HTTPS pour tous les composants d'OpenShift Container Platform qui communiquent entre eux.

Vous pouvez monter un volume persistant (PV) sur un hôte de n'importe quelle manière prise en charge par votre type de stockage. Les différents types de stockage ont des capacités différentes et les modes d'accès de chaque PV sont définis en fonction des modes spécifiques pris en charge par ce volume particulier.

Par exemple, NFS peut prendre en charge plusieurs clients en lecture/écriture, mais un PV NFS spécifique peut être exporté sur le serveur en lecture seule. Chaque PV possède son propre ensemble de modes d'accès décrivant ses capacités spécifiques, tels que ReadWriteOnce, ReadOnlyMany, et ReadWriteMany.

Pour les fournisseurs de stockage partagé tels que NFS, le PV enregistre son ID de groupe (GID) en tant qu'annotation sur la ressource PV. Ensuite, lorsque le PV est réclamé par le pod, le GID annoté est ajouté aux groupes supplémentaires du pod, ce qui lui donne accès au contenu du stockage partagé.

Pour les fournisseurs de stockage par blocs comme AWS Elastic Block Store (EBS), GCE Persistent Disks et iSCSI, OpenShift Container Platform utilise les fonctionnalités SELinux pour sécuriser la racine du volume monté pour les pods non privilégiés, ce qui fait que le volume monté appartient au conteneur auquel il est associé et n'est visible que par ce dernier.

Les administrateurs de clusters sont invités à se familiariser avec le type de ressource Event et à consulter la liste des événements système pour déterminer ceux qui les intéressent. Les événements sont associés à un espace de noms, soit l'espace de noms de la ressource à laquelle ils sont liés, soit, pour les événements de grappe, l'espace de noms default. L'espace de noms par défaut contient les événements pertinents pour le contrôle ou l'audit d'une grappe, tels que les événements de nœuds et les événements de ressources liés aux composants de l'infrastructure.

L'API principale et la commande oc ne fournissent pas de paramètres permettant de limiter la liste des événements aux seuls événements liés aux nœuds. Une approche simple consisterait à utiliser la commande grep:

$ oc get event -n default | grep Node

1h         20h         3         origin-node-1.example.local   Node      Normal    NodeHasDiskPressure   ...

Une approche plus souple consiste à produire les événements sous une forme que d'autres outils peuvent traiter. Par exemple, l'exemple suivant utilise l'outil jq contre une sortie JSON pour extraire uniquement les événements NodeHasDiskPressure:

$ oc get events -n default -o json \
  | jq '.items[] | select(.involvedObject.kind == "Node" and .reason == "NodeHasDiskPressure")'

{
  "apiVersion": "v1",
  "count": 3,
  "involvedObject": {
    "kind": "Node",
    "name": "origin-node-1.example.local",
    "uid": "origin-node-1.example.local"
  },
  "kind": "Event",
  "reason": "NodeHasDiskPressure",
  ...
}

Les événements liés à la création, à la modification ou à la suppression de ressources peuvent également être de bons candidats pour détecter une mauvaise utilisation du cluster. La requête suivante, par exemple, peut être utilisée pour rechercher des tirages excessifs d'images :

$ oc get events --all-namespaces -o json \
  | jq '[.items[] | select(.involvedObject.kind == "Pod" and .reason == "Pulling")] | length'

4

À l'aide de la commande oc log, vous pouvez consulter les journaux des conteneurs, les configurations de construction et les déploiements en temps réel. Différents utilisateurs peuvent avoir un accès différent aux journaux :

Pour sauvegarder vos logs en vue d'un audit et d'une analyse ultérieurs, vous pouvez activer la fonctionnalité complémentaire cluster-logging pour collecter, gérer et afficher les logs du système, du conteneur et de l'audit. Vous pouvez déployer, gérer et mettre à jour OpenShift Logging via OpenShift Elasticsearch Operator et Red Hat OpenShift Logging Operator.

Avec audit logs, vous pouvez suivre une séquence d'activités associées au comportement d'un utilisateur, d'un administrateur ou d'un autre composant d'OpenShift Container Platform. La journalisation de l'audit de l'API est effectuée sur chaque serveur.

Par défaut, OpenShift Container Platform utilise l'opérateur d'ingestion pour créer une autorité de certification interne et émettre un certificat générique valable pour les applications du sous-domaine .apps. La console web et le CLI utilisent également ce certificat.

Les certificats de l'autorité de certification de l'infrastructure interne sont auto-signés. Bien que ce processus puisse être perçu comme une mauvaise pratique par certaines équipes de sécurité ou d'ICP, le risque est minime. Les seuls clients qui font implicitement confiance à ces certificats sont les autres composants du cluster. Le remplacement du certificat joker par défaut par un certificat délivré par une autorité de certification publique déjà incluse dans le paquet d'autorités de certification fourni par l'espace utilisateur du conteneur permet aux clients externes de se connecter en toute sécurité aux applications fonctionnant sous le sous-domaine .apps.

Vous pouvez remplacer le certificat d'entrée par défaut pour toutes les applications sous le sous-domaine .apps. Après avoir remplacé le certificat, toutes les applications, y compris la console web et le CLI, bénéficieront du cryptage fourni par le certificat spécifié.

Ressources supplémentaires

Le certificat du serveur API par défaut est émis par une autorité de certification interne du cluster OpenShift Container Platform. Vous pouvez ajouter un ou plusieurs certificats alternatifs que le serveur API renverra en fonction du nom de domaine entièrement qualifié (FQDN) demandé par le client, par exemple lorsqu'un proxy inverse ou un équilibreur de charge est utilisé.

Les certificats de service sont destinés à prendre en charge des applications intermédiaires complexes nécessitant un chiffrement. Ces certificats sont émis en tant que certificats de serveur web TLS.

Le contrôleur service-ca utilise l'algorithme de signature x509.SHA256WithRSA pour générer des certificats de service.

Le certificat et la clé générés sont au format PEM, stockés respectivement dans tls.crt et tls.key, au sein d'un secret créé. Le certificat et la clé sont automatiquement remplacés lorsqu'ils sont proches de l'expiration.

Le certificat de l'autorité de certification de service, qui émet les certificats de service, est valable 26 mois et fait l'objet d'une rotation automatique lorsqu'il reste moins de 13 mois de validité. Après la rotation, la configuration précédente de l'AC de service reste fiable jusqu'à son expiration. Cela permet à tous les services concernés de bénéficier d'une période de grâce pour actualiser leur matériel de clés avant l'expiration. Si vous ne mettez pas à niveau votre cluster pendant cette période de grâce, qui redémarre les services et actualise leurs clés, vous devrez peut-être redémarrer manuellement les services pour éviter les défaillances après l'expiration de l'ancienne autorité de certification.

$ for I in $(oc get ns -o jsonpath='{range .items[*]} {.metadata.name}{"\n"} {end}'); \
      do oc delete pods --all -n $I; \
      sleep 1; \
      done

Pour sécuriser la communication avec votre service, générez un certificat de service signé et une paire de clés dans un secret dans le même espace de noms que le service.

Le certificat généré n'est valable que pour le nom DNS du service interne <service.name>.<service.namespace>.svc, et n'est valable que pour les communications internes. Si votre service est un service headless (pas de valeur clusterIP définie), le certificat généré contient également un sujet joker au format *.<service.name>.<service.namespace>.svc.

Un pod peut accéder au certificat de l'autorité de certification de service en montant un objet ConfigMap qui est annoté avec service.beta.openshift.io/inject-cabundle=true. Une fois annoté, le cluster injecte automatiquement le certificat de l'autorité de certification de service dans la clé service-ca.crt de la carte de configuration. L'accès à ce certificat CA permet aux clients TLS de vérifier les connexions aux services utilisant des certificats de service.

Vous pouvez annoter un objet APIService avec service.beta.openshift.io/inject-cabundle=true pour que son champ spec.caBundle soit rempli avec le service CA bundle. Cela permet au serveur API Kubernetes de valider le certificat de l'autorité de certification du service utilisé pour sécuriser le point de terminaison ciblé.

Vous pouvez annoter un objet CustomResourceDefinition (CRD) avec service.beta.openshift.io/inject-cabundle=true pour que son champ spec.conversion.webhook.clientConfig.caBundle soit rempli avec le bundle de l'autorité de certification de service. Cela permet au serveur API Kubernetes de valider le certificat de l'autorité de certification du service utilisé pour sécuriser le point de terminaison ciblé.

Vous pouvez annoter un objet MutatingWebhookConfiguration avec service.beta.openshift.io/inject-cabundle=true pour que le champ clientConfig.caBundle de chaque webhook soit rempli avec le service CA bundle. Cela permet au serveur API Kubernetes de valider le certificat de l'autorité de certification du service utilisé pour sécuriser le point de terminaison ciblé.

Vous pouvez annoter un objet ValidatingWebhookConfiguration avec service.beta.openshift.io/inject-cabundle=true pour que le champ clientConfig.caBundle de chaque webhook soit rempli avec le service CA bundle. Cela permet au serveur API Kubernetes de valider le certificat de l'autorité de certification du service utilisé pour sécuriser le point de terminaison ciblé.

Vous pouvez faire pivoter le certificat de service en supprimant le secret associé. La suppression du secret entraîne la création automatique d'un nouveau secret, ce qui donne lieu à un nouveau certificat.

L'AC de service est valable 26 mois et est automatiquement actualisé lorsqu'il reste moins de 13 mois de validité.

Si nécessaire, vous pouvez actualiser manuellement l'AC de service à l'aide de la procédure suivante.

Les certificats proxy permettent aux utilisateurs de spécifier une ou plusieurs autorités de certification (CA) personnalisées utilisées par les composants de la plate-forme lors de l'établissement de connexions de sortie.

Le champ trustedCA de l'objet Proxy est une référence à une carte de configuration qui contient un ensemble d'autorités de certification (CA) de confiance fourni par l'utilisateur. Cet ensemble est fusionné avec l'ensemble de confiance de Red Hat Enterprise Linux CoreOS (RHCOS) et injecté dans le magasin de confiance des composants de la plate-forme qui effectuent des appels HTTPS de sortie. Par exemple, image-registry-operator appelle un registre d'images externe pour télécharger des images. Si trustedCA n'est pas spécifié, seul l'ensemble de confiance RHCOS est utilisé pour les connexions HTTPS proxy. Fournissez des certificats CA personnalisés à l'ensemble de confiance RHCOS si vous souhaitez utiliser votre propre infrastructure de certificats.

Le champ trustedCA ne doit être consommé que par un validateur de proxy. Le validateur est chargé de lire le paquet de certificats de la clé requise ca-bundle.crt et de le copier dans une carte de configuration nommée trusted-ca-bundle dans l'espace de noms openshift-config-managed. L'espace de noms de la carte de configuration référencée par trustedCA est openshift-config:

apiVersion: v1
kind: ConfigMap
metadata:
  name: user-ca-bundle
  namespace: openshift-config
data:
  ca-bundle.crt: |
    -----BEGIN CERTIFICATE-----
    Custom CA certificate bundle.
    -----END CERTIFICATE-----

Ressources supplémentaires

Les clients externes au cluster peuvent accéder au serveur API à l'adresse api.<cluster_name>.<base_domain>. Il se peut que vous souhaitiez que les clients accèdent au serveur API sous un autre nom d'hôte ou sans avoir à distribuer aux clients les certificats de l'autorité de certification (CA) gérés par le cluster. L'administrateur doit définir un certificat par défaut personnalisé qui sera utilisé par le serveur API lors de la diffusion de contenu.

Les certificats fournis par l'utilisateur doivent être fournis dans un type kubernetes.io/tls Secret dans l'espace de noms openshift-config. Mettez à jour la configuration du cluster du serveur API, la ressource apiserver/cluster, pour permettre l'utilisation du certificat fourni par l'utilisateur.

Les certificats fournis par l'utilisateur sont gérés par ce dernier.

L'expiration du certificat du client du serveur API est inférieure à cinq minutes.

Les certificats fournis par l'utilisateur sont gérés par ce dernier.

Mettez à jour le secret contenant le certificat géré par l'utilisateur si nécessaire.

Ressources supplémentaires

Les certificats proxy permettent aux utilisateurs de spécifier un ou plusieurs certificats d'autorité de certification (CA) personnalisés utilisés par les composants de la plate-forme lors de l'établissement de connexions de sortie.

Le champ trustedCA de l'objet Proxy est une référence à une carte de configuration qui contient un ensemble d'autorités de certification (CA) de confiance fourni par l'utilisateur. Cet ensemble est fusionné avec l'ensemble de confiance de Red Hat Enterprise Linux CoreOS (RHCOS) et injecté dans le magasin de confiance des composants de la plate-forme qui effectuent des appels HTTPS de sortie. Par exemple, image-registry-operator appelle un registre d'images externe pour télécharger des images. Si trustedCA n'est pas spécifié, seul l'ensemble de confiance RHCOS est utilisé pour les connexions HTTPS proxy. Fournissez des certificats CA personnalisés à l'ensemble de confiance RHCOS si vous souhaitez utiliser votre propre infrastructure de certificats.

Le champ trustedCA ne doit être consommé que par un validateur de proxy. Le validateur est chargé de lire le paquet de certificats de la clé requise ca-bundle.crt et de le copier dans une carte de configuration nommée trusted-ca-bundle dans l'espace de noms openshift-config-managed. L'espace de noms de la carte de configuration référencée par trustedCA est openshift-config:

apiVersion: v1
kind: ConfigMap
metadata:
  name: user-ca-bundle
  namespace: openshift-config
data:
  ca-bundle.crt: |
    -----BEGIN CERTIFICATE-----
    Custom CA certificate bundle.
    -----END CERTIFICATE-----

Ressources supplémentaires

La valeur additionalTrustBundle de la configuration de l'installateur est utilisée pour spécifier tout certificat d'autorité de certification approuvé par le proxy lors de l'installation. Par exemple :

$ cat install-config.yaml

...
proxy:
  httpProxy: http://<https://username:password@proxy.example.com:123/>
  httpsProxy: https://<https://username:password@proxy.example.com:123/>
	noProxy: <123.example.com,10.88.0.0/16>
additionalTrustBundle: |
    -----BEGIN CERTIFICATE-----
   <MY_HTTPS_PROXY_TRUSTED_CA_CERT>
    -----END CERTIFICATE-----
...

L'ensemble de confiance fourni par l'utilisateur est représenté sous la forme d'une carte de configuration. La carte de configuration est montée dans le système de fichiers des composants de la plate-forme qui effectuent des appels HTTPS de sortie. En règle générale, les opérateurs montent la carte de configuration sur /etc/pki/ca-trust/extracted/pem/tls-ca-bundle.pem, mais cela n'est pas exigé par le proxy. Un proxy peut modifier ou inspecter la connexion HTTPS. Dans les deux cas, il doit générer et signer un nouveau certificat pour la connexion.

La prise en charge complète du proxy signifie que l'on se connecte au proxy spécifié et que l'on fait confiance à toutes les signatures qu'il a générées. Il est donc nécessaire de permettre à l'utilisateur de spécifier une racine de confiance, de sorte que toute chaîne de certificats connectée à cette racine de confiance soit également fiable.

Si vous utilisez l'ensemble de confiance RHCOS, placez les certificats d'autorité de certification à l'adresse /etc/pki/ca-trust/source/anchors.

Pour plus d'informations, reportez-vous à la section Utilisation de certificats de système partagés dans la documentation de Red Hat Enterprise Linux.

L'utilisateur définit la durée d'expiration de l'ensemble de confiance fourni par l'utilisateur.

Le délai d'expiration par défaut est défini par le certificat de l'autorité de certification lui-même. Il appartient à l'administrateur de l'autorité de certification de la configurer pour le certificat avant qu'il ne puisse être utilisé par OpenShift Container Platform ou RHCOS.

Par défaut, tous les composants de la plate-forme qui effectuent des appels HTTPS sortants utiliseront l'ensemble de confiance RHCOS. Si trustedCA est défini, il sera également utilisé.

Tout service fonctionnant sur le nœud RHCOS peut utiliser l'ensemble de confiance du nœud.

Ces certificats sont gérés par le système et non par l'utilisateur.

La mise à jour de l'ensemble de confiance fourni par l'utilisateur consiste soit à

Le mécanisme d'écriture des certificats CA dans le trust bundle du RHCOS est exactement le même que l'écriture de n'importe quel autre fichier dans le RHCOS, qui se fait par l'utilisation de configs de machine. Lorsque l'opérateur de configuration de machine (MCO) applique la nouvelle configuration de machine qui contient les nouveaux certificats d'autorité de certification, le nœud est redémarré. Lors du prochain redémarrage, le service coreos-update-ca-trust.service s'exécute sur les nœuds du RHCOS, qui mettent automatiquement à jour le trust bundle avec les nouveaux certificats d'autorité de certification. Par exemple :

apiVersion: machineconfiguration.openshift.io/v1
kind: MachineConfig
metadata:
  labels:
    machineconfiguration.openshift.io/role: worker
  name: 50-examplecorp-ca-cert
spec:
  config:
    ignition:
      version: 3.1.0
    storage:
      files:
      - contents:
          source: data:text/plain;charset=utf-8;base64,LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0tCk1JSUVORENDQXh5Z0F3SUJBZ0lKQU51bkkwRDY2MmNuTUEwR0NTcUdTSWIzRFFFQkN3VUFNSUdsTVFzd0NRWUQKV1FRR0V3SlZVekVYTUJVR0ExVUVDQXdPVG05eWRHZ2dRMkZ5YjJ4cGJtRXhFREFPQmdOVkJBY01CMUpoYkdWcApBMmd4RmpBVUJnTlZCQW9NRFZKbFpDQklZWFFzSUVsdVl5NHhFekFSQmdOVkJBc01DbEpsWkNCSVlYUWdTVlF4Ckh6QVpCZ05WQkFNTUVsSmxaQ0JJWVhRZ1NWUWdVbTl2ZENCRFFURWhNQjhHQ1NxR1NJYjNEUUVKQVJZU2FXNW0KWGpDQnBURUxNQWtHQTFVRUJoTUNWVk14RnpBVkJnTlZCQWdNRGs1dmNuUm9JRU5oY205c2FXNWhNUkF3RGdZRApXUVFIREFkU1lXeGxhV2RvTVJZd0ZBWURWUVFLREExU1pXUWdTR0YwTENCSmJtTXVNUk13RVFZRFZRUUxEQXBTCkFXUWdTR0YwSUVsVU1Sc3dHUVlEVlFRRERCSlNaV1FnU0dGMElFbFVJRkp2YjNRZ1EwRXhJVEFmQmdrcWhraUcKMHcwQkNRRVdFbWx1Wm05elpXTkFjbVZrYUdGMExtTnZiVENDQVNJd0RRWUpLb1pJaHZjTkFRRUJCUUFEZ2dFUApCRENDQVFvQ2dnRUJBTFF0OU9KUWg2R0M1TFQxZzgwcU5oMHU1MEJRNHNaL3laOGFFVHh0KzVsblBWWDZNSEt6CmQvaTdsRHFUZlRjZkxMMm55VUJkMmZRRGsxQjBmeHJza2hHSUlaM2lmUDFQczRsdFRrdjhoUlNvYjNWdE5xU28KSHhrS2Z2RDJQS2pUUHhEUFdZeXJ1eTlpckxaaW9NZmZpM2kvZ0N1dDBaV3RBeU8zTVZINXFXRi9lbkt3Z1BFUwpZOXBvK1RkQ3ZSQi9SVU9iQmFNNzYxRWNyTFNNMUdxSE51ZVNmcW5obzNBakxRNmRCblBXbG82MzhabTFWZWJLCkNFTHloa0xXTVNGa0t3RG1uZTBqUTAyWTRnMDc1dkNLdkNzQ0F3RUFBYU5qTUdFd0hRWURWUjBPQkJZRUZIN1IKNXlDK1VlaElJUGV1TDhacXczUHpiZ2NaTUI4R0ExVWRJd1FZTUJhQUZIN1I0eUMrVWVoSUlQZXVMOFpxdzNQegpjZ2NaTUE4R0ExVWRFd0VCL3dRRk1BTUJBZjh3RGdZRFZSMFBBUUgvQkFRREFnR0dNQTBHQ1NxR1NJYjNEUUVCCkR3VUFBNElCQVFCRE52RDJWbTlzQTVBOUFsT0pSOCtlbjVYejloWGN4SkI1cGh4Y1pROGpGb0cwNFZzaHZkMGUKTUVuVXJNY2ZGZ0laNG5qTUtUUUNNNFpGVVBBaWV5THg0ZjUySHVEb3BwM2U1SnlJTWZXK0tGY05JcEt3Q3NhawpwU29LdElVT3NVSks3cUJWWnhjckl5ZVFWMnFjWU9lWmh0UzV3QnFJd09BaEZ3bENFVDdaZTU4UUhtUzQ4c2xqCjVlVGtSaml2QWxFeHJGektjbGpDNGF4S1Fsbk92VkF6eitHbTMyVTB4UEJGNEJ5ZVBWeENKVUh3MVRzeVRtZWwKU3hORXA3eUhvWGN3bitmWG5hK3Q1SldoMWd4VVp0eTMKLS0tLS1FTkQgQ0VSVElGSUNBVEUtLS0tLQo=
        mode: 0644
        overwrite: true
        path: /etc/pki/ca-trust/source/anchors/examplecorp-ca.crt

Le registre de confiance des machines doit également permettre de mettre à jour le registre de confiance des nœuds.

Aucun opérateur ne peut renouveler automatiquement les certificats sur les nœuds RHCOS.

service-ca est un opérateur qui crée une autorité de certification auto-signée lors du déploiement d'un cluster OpenShift Container Platform.

Un délai d'expiration personnalisé n'est pas pris en charge. L'autorité de certification auto-signée est stockée dans un secret portant le nom qualifié service-ca/signing-key dans les champs tls.crt (certificat(s)), tls.key (clé privée) et ca-bundle.crt (regroupement d'autorités de certification).

D'autres services peuvent demander un certificat de service en annotant une ressource de service avec service.beta.openshift.io/serving-cert-secret-name: <secret name>. En réponse, l'opérateur génère un nouveau certificat ( tls.crt) et une clé privée ( tls.key ) pour le secret indiqué. Le certificat est valable deux ans.

D'autres services peuvent demander que l'ensemble d'AC pour l'AC de service soit injecté dans les ressources du service API ou de la carte de configuration en annotant avec service.beta.openshift.io/inject-cabundle: true pour prendre en charge la validation des certificats générés par l'AC de service. En réponse, l'opérateur écrit son ensemble d'AC actuel dans le champ CABundle d'un service API ou en tant que service-ca.crt dans une carte de configuration.

Depuis OpenShift Container Platform 4.3.5, la rotation automatisée est supportée et est rétroportée dans certaines versions 4.2.z et 4.3.z. Pour toute version prenant en charge la rotation automatisée, l'AC de service est valide pendant 26 mois et est automatiquement actualisée lorsqu'il reste moins de 13 mois de validité. Si nécessaire, vous pouvez actualiser manuellement l'autorité de certification de service.

L'expiration de l'autorité de certification de service de 26 mois est plus longue que l'intervalle de mise à niveau prévu pour un cluster OpenShift Container Platform pris en charge, de sorte que les consommateurs de certificats d'autorité de certification de service hors plan de contrôle seront actualisés après la rotation de l'autorité de certification et avant l'expiration de l'autorité de certification de pré-rotation.

Ces certificats sont gérés par le système et non par l'utilisateur.

Les services qui utilisent des certificats d'AC de service sont les suivants

Cette liste n'est pas exhaustive.

Ressources supplémentaires

Les certificats de nœuds sont signés par la grappe ; ils proviennent d'une autorité de certification (CA) générée par le processus d'amorçage. Après l'installation de la grappe, les certificats de nœuds font l'objet d'une rotation automatique.

Ces certificats sont gérés par le système et non par l'utilisateur.

Ressources supplémentaires

Le kubelet, dans OpenShift Container Platform 4 et les versions ultérieures, utilise le certificat bootstrap situé dans /etc/kubernetes/kubeconfig pour démarrer initialement. Cette étape est suivie du processus d'initialisation du bootstrap et de l'autorisation du kubelet à créer une CSR.

Dans ce processus, le kubelet génère une CSR tout en communiquant sur le canal d'amorçage. Le gestionnaire du contrôleur signe la CSR, ce qui donne un certificat que le kubelet gère.

Ces certificats sont gérés par le système et non par l'utilisateur.

Cette AC d'amorçage est valable pendant 10 ans.

Le certificat géré par les kubelets est valable un an et fait l'objet d'une rotation automatique à environ 80 % de sa durée.

Vous ne pouvez pas personnaliser les certificats d'amorçage.

les certificats etcd sont signés par le signataire etcd ; ils proviennent d'une autorité de certification (CA) générée par le processus d'amorçage.

Les certificats de l'autorité de certification sont valables 10 ans. Les certificats de l'homologue, du client et du serveur ont une durée de validité de trois ans.

Ces certificats ne sont gérés que par le système et font l'objet d'une rotation automatique.

les certificats etcd sont utilisés pour la communication cryptée entre les membres etcd, ainsi que pour le trafic client crypté. Les certificats suivants sont générés et utilisés par etcd et d'autres processus qui communiquent avec etcd :

Ressources supplémentaires

Tous les certificats des composants OpenShift Lifecycle Manager (OLM) (olm-operator, catalog-operator, packageserver, et marketplace-operator) sont gérés par le système.

Lors de l'installation d'opérateurs qui incluent des webhooks ou des services API dans leur objet ClusterServiceVersion (CSV), OLM crée et fait tourner les certificats pour ces ressources. Les certificats pour les ressources dans l'espace de noms openshift-operator-lifecycle-manager sont gérés par OLM.

OLM ne met pas à jour les certificats des opérateurs qu'il gère dans des environnements proxy. Ces certificats doivent être gérés par l'utilisateur à l'aide de la configuration de l'abonnement.

Les certificats des clients de l'API agrégée sont utilisés pour authentifier le KubeAPIServer lors de la connexion aux serveurs de l'API agrégée.

Ces certificats sont gérés par le système et non par l'utilisateur.

Cette AC est valable pour une durée de 30 jours.

Les certificats clients gérés sont valables pendant 30 jours.

Les certificats de l'autorité de certification et des clients font l'objet d'une rotation automatique grâce à l'utilisation de contrôleurs.

Vous ne pouvez pas personnaliser les certificats de serveur API agrégés.

Les certificats de l'opérateur Machine Config sont utilisés pour sécuriser les connexions entre les nœuds Red Hat Enterprise Linux CoreOS (RHCOS) et le serveur Machine Config.

Ces certificats sont gérés par le système et non par l'utilisateur.

Cet AC est valable pour une durée de 10 ans.

Les certificats de service délivrés sont valables 10 ans.

Vous ne pouvez pas personnaliser les certificats de l'opérateur de configuration de la machine.

Les applications sont généralement exposées à l'adresse <route_name>.apps.<cluster_name>.<base_domain>. Les adresses <cluster_name> et <base_domain> proviennent du fichier de configuration de l'installation. <route_name> est le champ hôte de la route, s'il est spécifié, ou le nom de la route. Par exemple, hello-openshift-default.apps.username.devcluster.openshift.com. hello-openshift est le nom de l'itinéraire et l'itinéraire se trouve dans l'espace de noms par défaut. Il se peut que vous souhaitiez que les clients accèdent aux applications sans qu'il soit nécessaire de leur distribuer les certificats d'autorité de certification gérés par le cluster. L'administrateur doit définir un certificat par défaut personnalisé lorsqu'il sert le contenu de l'application.

Les certificats fournis par l'utilisateur doivent l'être dans une ressource de type tls Secret dans l'espace de noms openshift-ingress. Mettez à jour le CR IngressController dans l'espace de noms openshift-ingress-operator pour permettre l'utilisation du certificat fourni par l'utilisateur. Pour plus d'informations sur ce processus, voir Définition d'un certificat par défaut personnalisé.

Les certificats fournis par l'utilisateur sont gérés par ce dernier.

Les certificats fournis par l'utilisateur sont gérés par ce dernier.

Les applications déployées sur le cluster utilisent des certificats fournis par l'utilisateur pour l'entrée par défaut.

Mettez à jour le secret contenant le certificat géré par l'utilisateur si nécessaire.

Ressources supplémentaires

L'opérateur d'entrée utilise des certificats pour

Pour sécuriser l'accès aux mesures de l'opérateur d'entrée et du contrôleur d'entrée, l'opérateur d'entrée utilise des certificats de service. L'opérateur demande un certificat au contrôleur service-ca pour ses propres mesures, et le contrôleur service-ca place le certificat dans un secret nommé metrics-tls dans l'espace de noms openshift-ingress-operator. En outre, l'opérateur d'entrée demande un certificat pour chaque contrôleur d'entrée et le contrôleur service-ca place le certificat dans un secret nommé router-metrics-certs-<name>, où <name> est le nom du contrôleur d'entrée, dans l'espace de noms openshift-ingress.

Chaque contrôleur d'entrée dispose d'un certificat par défaut qu'il utilise pour les itinéraires sécurisés qui ne spécifient pas leurs propres certificats. À moins que vous n'indiquiez un certificat personnalisé, l'opérateur utilise par défaut un certificat auto-signé. L'opérateur utilise son propre certificat de signature auto-signé pour signer tout certificat par défaut qu'il génère. L'opérateur génère ce certificat de signature et le place dans un secret nommé router-ca dans l'espace de noms openshift-ingress-operator. Lorsque l'opérateur génère un certificat par défaut, il le place dans un secret nommé router-certs-<name> (où <name> est le nom du contrôleur d'entrée) dans l'espace de noms openshift-ingress.

Si le champ defaultCertificate est vide, l'opérateur d'entrée utilise son autorité de certification auto-signée pour générer un certificat de service pour le domaine spécifié.

Certificat et clé de l'autorité de certification par défaut générés par l'opérateur d'entrée. Utilisé pour signer les certificats de service par défaut générés par l'opérateur.

Dans le flux de travail par défaut, il s'agit du certificat de service par défaut avec caractère générique, créé par l'opérateur d'entrée et signé à l'aide du certificat de l'autorité de certification par défaut généré. Dans le flux de travail personnalisé, il s'agit du certificat fourni par l'utilisateur.

Le déploiement du routeur. Utilise le certificat dans secrets/router-certs-default comme certificat de serveur frontal par défaut.

Dans le flux de travail par défaut, le contenu du certificat de service par défaut (parties publique et privée) est copié ici pour permettre l'intégration OAuth. Dans le flux de travail personnalisé, il s'agit du certificat fourni par l'utilisateur.

La partie publique (certificat) du certificat de service par défaut. Remplace la ressource configmaps/router-ca.

L'utilisateur met à jour la configuration du proxy de cluster avec le certificat CA qui a signé le certificat de service ingresscontroller. Cela permet à des composants tels que auth, console et le registre de faire confiance au certificat de service.

Le groupe d'AC de confiance à l'échelle du cluster contenant les groupes d'AC combinés de Red Hat Enterprise Linux CoreOS (RHCOS) et fournis par l'utilisateur ou un groupe RHCOS uniquement si un groupe d'utilisateurs n'est pas fourni.

Le paquet de certificats CA personnalisés, qui indique à d'autres composants (par exemple, auth et console) de faire confiance à un ingresscontroller configuré avec un certificat personnalisé.

Le champ trustedCA est utilisé pour référencer l'ensemble de CA fourni par l'utilisateur.

L'opérateur du réseau de clusters injecte le paquet d'AC de confiance dans la carte de configuration proxy-ca.

OpenShift Container Platform 4.12 et les versions plus récentes utilisent default-ingress-cert.

Les délais d'expiration des certificats de l'opérateur d'entrée sont les suivants :

Vous ne pouvez pas spécifier de conditions d'expiration personnalisées pour les certificats créés par l'opérateur d'entrée ou le contrôleur service-ca.

Lors de l'installation d'OpenShift Container Platform, vous ne pouvez pas spécifier de délai d'expiration pour les certificats créés par l'opérateur d'ingestion ou le contrôleur service-ca.

Prometheus utilise les certificats qui sécurisent les métriques.

L'opérateur d'entrée utilise son certificat de signature pour signer les certificats par défaut qu'il génère pour les contrôleurs d'entrée pour lesquels vous ne définissez pas de certificats par défaut personnalisés.

Les composants du cluster qui utilisent des routes sécurisées peuvent utiliser le certificat par défaut du contrôleur d'entrée.

L'entrée dans le cluster via une route sécurisée utilise le certificat par défaut du contrôleur d'entrée par lequel la route est accessible, à moins que la route ne spécifie son propre certificat.

Les certificats d'entrée sont gérés par l'utilisateur. Pour plus d'informations, voir Remplacement du certificat d'entrée par défaut.

Le contrôleur service-ca effectue une rotation automatique des certificats qu'il émet. Cependant, il est possible d'utiliser oc delete secret <secret> pour effectuer une rotation manuelle des certificats de service.

L'opérateur d'ingestion n'effectue pas de rotation de son propre certificat de signature ou des certificats par défaut qu'il génère. Les certificats par défaut générés par l'opérateur sont destinés à remplacer les certificats par défaut personnalisés que vous configurez.

Les composants de surveillance sécurisent leur trafic à l'aide de certificats d'AC de service. Ces certificats sont valables pendant deux ans et sont remplacés automatiquement lors de la rotation de l'autorité de certification de service, c'est-à-dire tous les 13 mois.

Si le certificat se trouve dans l'espace de noms openshift-monitoring ou openshift-logging, il est géré par le système et fait l'objet d'une rotation automatique.

Ces certificats sont gérés par le système et non par l'utilisateur.

Les certificats du plan de contrôle sont inclus dans ces espaces de noms :

Les certificats du plan de contrôle sont gérés par le système et font l'objet d'une rotation automatique.

Dans le cas rare où vos certificats de plan de contrôle ont expiré, voir Récupération des certificats de plan de contrôle expirés.

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

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

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

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

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

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

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

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

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

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

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

L'opérateur de conformité fournit les profils de conformité suivants :

Si l'opérateur n'est pas installé correctement :

L'abonnement d'un opérateur installé spécifie un canal de mise à jour qui suit et reçoit les mises à jour de l'opérateur. Vous pouvez modifier le canal de mise à jour pour commencer à suivre et à recevoir des mises à jour à partir d'un canal plus récent.

Les noms des canaux de mise à jour dans un abonnement peuvent varier d'un opérateur à l'autre, mais le système de dénomination suit généralement une convention commune au sein d'un opérateur donné. Par exemple, les noms des canaux peuvent correspondre à un flux de mises à jour de versions mineures pour l'application fournie par l'opérateur (1.2, 1.3) ou à une fréquence de publication (stable, fast).

Red Hat Customer Portal Labs comprend l'application suivante qui aide les administrateurs à préparer la mise à jour de leurs opérateurs :

Vous pouvez utiliser l'application pour rechercher des opérateurs basés sur Operator Lifecycle Manager et vérifier la version disponible de l'opérateur par canal de mise à jour à travers différentes versions d'OpenShift Container Platform. Les opérateurs basés sur la version du cluster ne sont pas inclus.

Vous pouvez changer le canal de mise à jour d'un opérateur en utilisant la console web d'OpenShift Container Platform.

Si la stratégie d'approbation de l'abonnement d'un opérateur installé est définie sur Manual, lorsque de nouvelles mises à jour sont publiées dans son canal de mise à jour actuel, la mise à jour doit être approuvée manuellement avant que l'installation ne puisse commencer.

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.

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.

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.

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

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.

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"

Plusieurs profils sont disponibles dans le cadre de l'installation de l'Opérateur de Conformité. Vous pouvez utiliser la commande oc get pour afficher les profils disponibles, les détails des profils et les règles spécifiques.

L'objet ProfileBundle nécessite deux informations : l'URL d'une image de conteneur qui contient contentImage et le fichier qui contient le contenu de conformité. Le paramètre contentFile est relatif à la racine du système de fichiers. Vous pouvez définir l'objet intégré rhcos4 ProfileBundle comme indiqué dans l'exemple suivant :

apiVersion: compliance.openshift.io/v1alpha1
kind: ProfileBundle
metadata:
  creationTimestamp: "2022-10-19T12:06:30Z"
  finalizers:
  - profilebundle.finalizers.compliance.openshift.io
  generation: 1
  name: rhcos4
  namespace: openshift-compliance
  resourceVersion: "46741"
  uid: 22350850-af4a-4f5c-9a42-5e7b68b82d7d
spec:
  contentFile: ssg-rhcos4-ds.xml 1
  contentImage: registry.redhat.io/compliance/openshift-compliance-content-rhel8@sha256:900e... 2
status:
  conditions:
  - lastTransitionTime: "2022-10-19T12:07:51Z"
    message: Profile bundle successfully parsed
    reason: Valid
    status: "True"
    type: Ready
  dataStreamStatus: VALID

Le contenu de sécurité est inclus en tant qu'images de conteneur auxquelles les objets ProfileBundle font référence. Pour suivre avec précision les mises à jour de ProfileBundles et les ressources personnalisées analysées à partir des paquets, telles que les règles ou les profils, identifiez l'image du conteneur avec le contenu de conformité en utilisant un condensé au lieu d'une balise :

$ oc -n openshift-compliance get profilebundles rhcos4 -oyaml

apiVersion: compliance.openshift.io/v1alpha1
kind: ProfileBundle
metadata:
  creationTimestamp: "2022-10-19T12:06:30Z"
  finalizers:
  - profilebundle.finalizers.compliance.openshift.io
  generation: 1
  name: rhcos4
  namespace: openshift-compliance
  resourceVersion: "46741"
  uid: 22350850-af4a-4f5c-9a42-5e7b68b82d7d
spec:
  contentFile: ssg-rhcos4-ds.xml
  contentImage: registry.redhat.io/compliance/openshift-compliance-content-rhel8@sha256:900e... 1
status:
  conditions:
  - lastTransitionTime: "2022-10-19T12:07:51Z"
    message: Profile bundle successfully parsed
    reason: Valid
    status: "True"
    type: Ready
  dataStreamStatus: VALID

Chaque site ProfileBundle est soutenu par un déploiement. Lorsque l'opérateur de conformité détecte que le résumé de l'image du conteneur a changé, le déploiement est mis à jour pour refléter le changement et analyser à nouveau le contenu. L'utilisation d'un condensé au lieu d'une balise garantit l'utilisation d'un ensemble de profils stables et prévisibles.

Vous pouvez créer un profil personnalisé à partir de zéro en utilisant l'objet TailoredProfile. Définissez un title et un description appropriés et laissez le champ extends vide. Indiquez à l'opérateur de conformité le type d'analyse que ce profil personnalisé va générer :

exemple new-profile.yaml

apiVersion: compliance.openshift.io/v1alpha1
kind: TailoredProfile
metadata:
  name: new-profile
  annotations:
    compliance.openshift.io/product-type: Node 1
spec:
  extends:
  description: My custom profile 2
  title: Custom profile 3

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.

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

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

$ oc get -n openshift-compliance compliancecheckresults \
-l compliance.openshift.io/scan=workers-scan

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'

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'

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

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'

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

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

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.

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())))"

net.ipv4.conf.all.accept_redirects=0

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.

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.

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.

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.

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

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

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.

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

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 :

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.

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

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.

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.

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=

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.

Les sections suivantes décrivent les composantes et les étapes de l'analyse de l'opérateur de conformité.

$ oc get -n openshift-compliance profilebundle.compliance

$ oc get -n openshift-compliance profile.compliance

$ 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

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

Events:
  Type     Reason        Age    From                    Message
  ----     ------        ----   ----                    -------
  Normal   SuiteCreated  9m52s  scansettingbindingctrl  ComplianceSuite openshift-compliance/my-companys-compliance-requirements created

$ oc get cronjobs

NAME                                           SCHEDULE    SUSPEND   ACTIVE   LAST SCHEDULE   AGE
<cron_name>                                    0 1 * * *   False     0        <none>          151m

$ oc -n openshift-compliance get cm \
-l compliance.openshift.io/scan-name=rhcos4-e8-worker,complianceoperator.openshift.io/scan-script=

$ oc get pvc -n openshift-compliance -lcompliance.openshift.io/scan-name=rhcos4-e8-worker

$ oc get pods -lcompliance.openshift.io/scan-name=rhcos4-e8-worker,workload=scanner --show-labels

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

$ oc get compliancecheckresults -lcompliance.openshift.io/scan-name=rhcos4-e8-worker

NAME                                                       STATUS   SEVERITY
rhcos4-e8-worker-accounts-no-uid-except-zero               PASS     high
rhcos4-e8-worker-audit-rules-dac-modification-chmod        FAIL     medium

$ oc get complianceremediations -lcompliance.openshift.io/scan-name=rhcos4-e8-worker

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

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

$ oc patch complianceremediations/rhcos4-e8-worker-audit-rules-dac-modification-chmod --patch '{"spec":{"apply":true}}' --type=merge

$ oc get mc | grep 75-

75-rhcos4-e8-worker-my-companys-compliance-requirements                                                3.2.0             2m46s

$ oc describe mc/75-rhcos4-e8-worker-my-companys-compliance-requirements

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:

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

$ oc -n openshift-compliance \
get compliancecheckresults/rhcos4-e8-worker-audit-rules-dac-modification-chmod

NAME                                                  STATUS   SEVERITY
rhcos4-e8-worker-audit-rules-dac-modification-chmod   PASS     medium

oc logs -l workload=<workload_name> -c <container_name>

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.

Le champ resources définit les contraintes de ressources pour tous les conteneurs du pod créé par l'Operator Lifecycle Manager (OLM).

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.

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 :

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.

Pour supprimer l'Opérateur de conformité, vous devez d'abord supprimer les objets de l'espace de noms. Une fois les objets supprimés, vous pouvez supprimer l'opérateur et son espace de noms en supprimant le projet openshift-compliance.

Pour supprimer l'Opérateur de conformité, vous devez d'abord supprimer les objets de l'espace de noms. Une fois les objets supprimés, vous pouvez supprimer l'opérateur et son espace de noms en supprimant le projet openshift-compliance.

Lorsqu'un contrôle de conformité est terminé, les résultats des contrôles individuels sont répertoriés dans la ressource personnalisée (CR) ComplianceCheckResult qui en résulte. Cependant, un administrateur ou un auditeur peut avoir besoin des détails complets de l'analyse. L'outil OpenSCAP crée un fichier au format ARF (Advanced Recording Format) contenant les résultats détaillés. Ce fichier ARF est trop volumineux pour être stocké dans une carte de configuration ou une autre ressource Kubernetes standard, un volume persistant (PV) est donc créé pour le contenir.

Affiche la liste des fichiers du répertoire :

$ ls /tmp/ocp4-cis-node-master/

ocp4-cis-node-master-ip-10-0-128-89.ec2.internal-pod.xml.bzip2  ocp4-cis-node-master-ip-10-0-150-5.ec2.internal-pod.xml.bzip2  ocp4-cis-node-master-ip-10-0-163-32.ec2.internal-pod.xml.bzip2

Extraire les résultats :

$ bunzip2 -c resultsdir/worker-scan/worker-scan-stage-459-tqkg7-compute-0-pod.xml.bzip2 > resultsdir/worker-scan/worker-scan-ip-10-0-170-231.us-east-2.compute.internal-pod.xml

Voir les résultats :

$ ls resultsdir/worker-scan/

worker-scan-ip-10-0-170-231.us-east-2.compute.internal-pod.xml
worker-scan-stage-459-tqkg7-compute-0-pod.xml.bzip2
worker-scan-stage-459-tqkg7-compute-1-pod.xml.bzip2

Bien qu'il soit possible d'exécuter des analyses en tant que tâches planifiées, vous devez souvent réexécuter une analyse à la demande, en particulier après l'application de remédiations ou lorsque d'autres changements sont apportés au cluster.

En utilisant les ressources personnalisées (CR) ScanSetting et ScanSettingBinding fournies par l'Opérateur de Conformité, il est possible d'exécuter des analyses pour plusieurs profils tout en utilisant un ensemble commun d'options d'analyse, telles que schedule, machine roles, tolerations, et ainsi de suite. Bien que cela soit plus facile que de travailler avec plusieurs objets ComplianceSuite ou ComplianceScan, cela peut perturber les nouveaux utilisateurs.

La sous-commande oc compliance bind vous aide à créer un CR ScanSettingBinding.

Les normes de conformité sont généralement organisées selon la hiérarchie suivante :

L'opérateur de conformité fournit des objets de remédiation qui sont utilisés pour automatiser les changements nécessaires pour rendre le cluster conforme. La sous-commande fetch-fixes peut vous aider à comprendre exactement quelles remédiations de configuration sont utilisées. Utilisez la sous-commande fetch-fixes pour extraire les objets de remédiation d'un profil, d'une règle ou d'un objet ComplianceRemediation dans un répertoire à inspecter.

Lorsque les analyses sont terminées, les objets ComplianceCheckResult sont créés pour les règles d'analyse individuelles. La sous-commande view-result fournit une sortie lisible par l'homme des détails de l'objet ComplianceCheckResult.

Le document de référence vous fournit le flux de travail suivant pour effectuer les contrôles de conformité :

Par défaut, les CRD de l'opérateur de conformité comprennent les objets ProfileBundle et Profile, dans lesquels vous pouvez définir et fixer les règles pour vos exigences d'analyse de conformité. Vous pouvez également personnaliser les profils par défaut en utilisant un objet TailoredProfile.

apiVersion: compliance.openshift.io/v1alpha1
kind: ProfileBundle
  name: <profile bundle name>
  namespace: openshift-compliance
status:
  dataStreamStatus: VALID 1

apiVersion: compliance.openshift.io/v1alpha1
description: <description of the profile>
id: xccdf_org.ssgproject.content_profile_moderate 1
kind: Profile
metadata:
  annotations:
    compliance.openshift.io/product: <product name>
    compliance.openshift.io/product-type: Node 2
  creationTimestamp: "YYYY-MM-DDTMM:HH:SSZ"
  generation: 1
  labels:
    compliance.openshift.io/profile-bundle: <profile bundle name>
  name: rhcos4-moderate
  namespace: openshift-compliance
  ownerReferences:
  - apiVersion: compliance.openshift.io/v1alpha1
    blockOwnerDeletion: true
    controller: true
    kind: ProfileBundle
    name: <profile bundle name>
    uid: <uid string>
  resourceVersion: "<version number>"
  selfLink: /apis/compliance.openshift.io/v1alpha1/namespaces/openshift-compliance/profiles/rhcos4-moderate
  uid: <uid string>
rules: 3
- rhcos4-account-disable-post-pw-expiration
- rhcos4-accounts-no-uid-except-zero
- rhcos4-audit-rules-dac-modification-chmod
- rhcos4-audit-rules-dac-modification-chown
title: <title of the profile>

    apiVersion: compliance.openshift.io/v1alpha1
    checkType: Platform 1
    description: <description of the rule>
    id: xccdf_org.ssgproject.content_rule_configure_network_policies_namespaces 2
    instructions: <manual instructions for the scan>
    kind: Rule
    metadata:
      annotations:
        compliance.openshift.io/rule: configure-network-policies-namespaces
        control.compliance.openshift.io/CIS-OCP: 5.3.2
        control.compliance.openshift.io/NERC-CIP: CIP-003-3 R4;CIP-003-3 R4.2;CIP-003-3
          R5;CIP-003-3 R6;CIP-004-3 R2.2.4;CIP-004-3 R3;CIP-007-3 R2;CIP-007-3 R2.1;CIP-007-3
          R2.2;CIP-007-3 R2.3;CIP-007-3 R5.1;CIP-007-3 R6.1
        control.compliance.openshift.io/NIST-800-53: AC-4;AC-4(21);CA-3(5);CM-6;CM-6(1);CM-7;CM-7(1);SC-7;SC-7(3);SC-7(5);SC-7(8);SC-7(12);SC-7(13);SC-7(18)
      labels:
        compliance.openshift.io/profile-bundle: ocp4
      name: ocp4-configure-network-policies-namespaces
      namespace: openshift-compliance
    rationale: <description of why this rule is checked>
    severity: high 3
    title: <summary of the rule>

apiVersion: compliance.openshift.io/v1alpha1
kind: TailoredProfile
metadata:
  name: rhcos4-with-usb
spec:
  extends: rhcos4-moderate 1
  title: <title of the tailored profile>
  disableRules:
    - name: <name of a rule object to be disabled>
      rationale: <description of why this rule is checked>
status:
  id: xccdf_compliance.openshift.io_profile_rhcos4-with-usb 2
  outputRef:
    name: rhcos4-with-usb-tp 3
    namespace: openshift-compliance
  state: READY 4

Après avoir défini les exigences du contrôle de conformité, vous pouvez le configurer en spécifiant le type de contrôle, l'occurrence du contrôle et l'emplacement du contrôle. Pour ce faire, l'Opérateur de Conformité vous fournit un objet ScanSetting.

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 3
  Size:      1Gi 4
  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: 5
  master
  worker
Scan Tolerations:
  Operator:           Exists
Schedule:             "0 1 * * *" 6
Show Not Applicable:  false
Strict Node Scan:     true
Events:               <none>

Lorsque vous avez défini les exigences de l'analyse de conformité et configuré les paramètres pour exécuter les analyses, l'opérateur de conformité les traite à l'aide de l'objet ScanSettingBinding.

apiVersion: compliance.openshift.io/v1alpha1
kind: ScanSettingBinding
metadata:
  name: <name of the scan>
profiles: 1
  # Node checks
  - name: rhcos4-with-usb
    kind: TailoredProfile
    apiGroup: compliance.openshift.io/v1alpha1
  # Cluster checks
  - name: ocp4-moderate
    kind: Profile
    apiGroup: compliance.openshift.io/v1alpha1
settingsRef: 2
  name: my-companys-constraints
  kind: ScanSetting
  apiGroup: compliance.openshift.io/v1alpha1

$ oc get compliancesuites

Après la création de la suite de conformité, vous pouvez contrôler l'état des analyses déployées à l'aide de l'objet ComplianceSuite.

apiVersion: compliance.openshift.io/v1alpha1
kind: ComplianceSuite
metadata:
  name: <name of the scan>
spec:
  autoApplyRemediations: false 1
  schedule: "0 1 * * *" 2
  scans: 3
    - name: workers-scan
      scanType: Node
      profile: xccdf_org.ssgproject.content_profile_moderate
      content: ssg-rhcos4-ds.xml
      contentImage: quay.io/complianceascode/ocp4:latest
      rule: "xccdf_org.ssgproject.content_rule_no_netrc_files"
      nodeSelector:
        node-role.kubernetes.io/worker: ""
status:
  Phase: DONE 4
  Result: NON-COMPLIANT 5
  scanStatuses:
  - name: workers-scan
    phase: DONE
    result: NON-COMPLIANT

oc get events --field-selector involvedObject.kind=ComplianceSuite,involvedObject.name=<nom de la suite>

apiVersion: compliance.openshift.io/v1alpha1
kind: ComplianceScan
metadata:
  name: <name of the scan>
spec:
  scanType: Node 1
  profile: xccdf_org.ssgproject.content_profile_moderate 2
  content: ssg-ocp4-ds.xml
  contentImage: quay.io/complianceascode/ocp4:latest 3
  rule: "xccdf_org.ssgproject.content_rule_no_netrc_files" 4
  nodeSelector: 5
    node-role.kubernetes.io/worker: ""
status:
  phase: DONE 6
  result: NON-COMPLIANT 7

oc get events --field-selector involvedObject.kind=ComplianceScan,involvedObject.name=<nom de la suite>

Lorsque la suite de conformité atteint la phase DONE, vous pouvez consulter les résultats de l'analyse et les mesures correctives possibles.

apiVersion: compliance.openshift.io/v1alpha1
kind: ComplianceCheckResult
metadata:
  labels:
    compliance.openshift.io/check-severity: medium
    compliance.openshift.io/check-status: FAIL
    compliance.openshift.io/suite: example-compliancesuite
    compliance.openshift.io/scan-name: workers-scan
  name: workers-scan-no-direct-root-logins
  namespace: openshift-compliance
  ownerReferences:
  - apiVersion: compliance.openshift.io/v1alpha1
    blockOwnerDeletion: true
    controller: true
    kind: ComplianceScan
    name: workers-scan
description: <description of scan check>
instructions: <manual instructions for the scan>
id: xccdf_org.ssgproject.content_rule_no_direct_root_logins
severity: medium 1
status: FAIL 2

oc get compliancecheckresults \
-l compliance.openshift.io/suite=workers-compliancesuite

apiVersion: compliance.openshift.io/v1alpha1
kind: ComplianceRemediation
metadata:
  labels:
    compliance.openshift.io/suite: example-compliancesuite
    compliance.openshift.io/scan-name: workers-scan
    machineconfiguration.openshift.io/role: worker
  name: workers-scan-disable-users-coredumps
  namespace: openshift-compliance
  ownerReferences:
  - apiVersion: compliance.openshift.io/v1alpha1
    blockOwnerDeletion: true
    controller: true
    kind: ComplianceCheckResult
    name: workers-scan-disable-users-coredumps
    uid: <UID>
spec:
  apply: false 1
  object:
    current: 2
       apiVersion: machineconfiguration.openshift.io/v1
       kind: MachineConfig
       spec:
         config:
           ignition:
             version: 2.2.0
           storage:
             files:
             - contents:
                 source: data:,%2A%20%20%20%20%20hard%20%20%20core%20%20%20%200
               filesystem: root
               mode: 420
               path: /etc/security/limits.d/75-disable_users_coredumps.conf
    outdated: {} 3

oc get complianceremediations \
-l compliance.openshift.io/suite=workers-compliancesuite

oc get compliancecheckresults \
-l 'compliance.openshift.io/check-status in (FAIL),compliance.openshift.io/automated-remediation'

oc get compliancecheckresults \
-l 'compliance.openshift.io/check-status in (FAIL),!compliance.openshift.io/automated-remediation'

L'avis suivant est disponible pour OpenShift File Integrity Operator 1.2.1 :

L'avis suivant est disponible pour OpenShift File Integrity Operator 1.2.0 :

L'avis suivant est disponible pour OpenShift File Integrity Operator 1.0.0 :

L'avis suivant est disponible pour OpenShift File Integrity Operator 0.1.32 :

L'avis suivant est disponible pour OpenShift File Integrity Operator 0.1.30 :

L'avis suivant est disponible pour OpenShift File Integrity Operator 0.1.24 :

L'avis suivant est disponible pour OpenShift File Integrity Operator 0.1.22 :

L'avis suivant est disponible pour OpenShift File Integrity Operator 0.1.21 :

Si l'opérateur n'est pas installé correctement :

L'abonnement d'un opérateur installé spécifie un canal de mise à jour qui suit et reçoit les mises à jour de l'opérateur. Vous pouvez modifier le canal de mise à jour pour commencer à suivre et à recevoir des mises à jour à partir d'un canal plus récent.

Les noms des canaux de mise à jour dans un abonnement peuvent varier d'un opérateur à l'autre, mais le système de dénomination suit généralement une convention commune au sein d'un opérateur donné. Par exemple, les noms des canaux peuvent correspondre à un flux de mises à jour de versions mineures pour l'application fournie par l'opérateur (1.2, 1.3) ou à une fréquence de publication (stable, fast).

Red Hat Customer Portal Labs comprend l'application suivante qui aide les administrateurs à préparer la mise à jour de leurs opérateurs :

Vous pouvez utiliser l'application pour rechercher des opérateurs basés sur Operator Lifecycle Manager et vérifier la version disponible de l'opérateur par canal de mise à jour à travers différentes versions d'OpenShift Container Platform. Les opérateurs basés sur la version du cluster ne sont pas inclus.

Vous pouvez changer le canal de mise à jour d'un opérateur en utilisant la console web d'OpenShift Container Platform.

Si la stratégie d'approbation de l'abonnement d'un opérateur installé est définie sur Manual, lorsque de nouvelles mises à jour sont publiées dans son canal de mise à jour actuel, la mise à jour doit être approuvée manuellement avant que l'installation ne puisse commencer.