2.3. Comprendre le processus et la sécurité pour OpenShift Dédié

Les notifications de cluster sont conçues pour vous tenir informé de la santé de votre cluster et des événements à fort impact qui l’affectent.

La plupart des notifications de cluster sont générées et envoyées automatiquement pour vous assurer que vous êtes immédiatement informé des problèmes ou des changements importants à l’état de votre cluster.

Dans certaines situations, Red Hat Site Reliability Engineering (SRE) crée et envoie des notifications de cluster pour fournir un contexte supplémentaire et des conseils pour un problème complexe.

Les notifications de cluster ne sont pas envoyées pour les événements à faible impact, les mises à jour de sécurité à faible risque, les opérations et la maintenance de routine, ou les problèmes transitoires mineurs qui sont rapidement résolus par SRE.

Les services Red Hat envoient automatiquement des notifications lorsque:

La SRE crée et envoie des notifications lorsque:

Le Red Hat Site Reliability Engineer (SRE) maintient un système de surveillance et d’alerte centralisé pour tous les composants de cluster dédiés OpenShift, les services SRE et les comptes de fournisseurs cloud sous-jacents. Les journaux d’audit de plate-forme sont transmis en toute sécurité à un système centralisé SIEM (Security Information and Event Monitoring), où ils peuvent déclencher des alertes configurées à l’équipe SRE et sont également soumis à un examen manuel. Les journaux d’audit sont conservés dans le SIEM pendant un an. Les journaux d’audit d’un cluster donné ne sont pas supprimés au moment où le cluster est supprimé.

L’incident est un événement qui entraîne une dégradation ou une panne d’un ou de plusieurs services Red Hat. L’incident peut être soulevé par un client ou un membre de l’Expérience client et de l’engagement (CEE) par le biais d’un dossier d’assistance, directement par le système centralisé de surveillance et d’alerte, ou directement par un membre de l’équipe SRE.

En fonction de l’impact sur le service et le client, l’incident est classé en termes de gravité.

Le flux de travail général de la façon dont un nouvel incident est géré par Red Hat:

Les clusters dédiés OpenShift sont sauvegardés à l’aide de snapshots des fournisseurs de cloud. En particulier, cela n’inclut pas les données clients stockées sur des volumes persistants (PV). Les snapshots sont pris à l’aide des API instantanées appropriées du fournisseur de cloud et sont téléchargés sur un seau de stockage d’objets sécurisé (S3 dans AWS et GCS dans Google Cloud) dans le même compte que le cluster.

L’évaluation et la gestion de la capacité des clusters est une responsabilité partagée entre Red Hat et le client. Le Red Hat SRE est responsable de la capacité de tous les nœuds d’avion de contrôle et d’infrastructure sur le cluster.

Le Red Hat SRE évalue également la capacité des clusters lors des mises à niveau et en réponse aux alertes de clusters. L’impact d’une mise à niveau du cluster sur la capacité est évalué dans le cadre du processus d’essai de mise à niveau afin de s’assurer que la capacité n’est pas affectée négativement par de nouveaux ajouts au cluster. Lors d’une mise à niveau de cluster, des nœuds de travail supplémentaires sont ajoutés pour s’assurer que la capacité totale du cluster est maintenue pendant le processus de mise à niveau.

Les évaluations des capacités du personnel de SRE ont également lieu en réponse aux alertes du groupe, une fois que les seuils d’utilisation sont dépassés pendant une certaine période. De telles alertes peuvent également entraîner une notification au client.

Il est possible d’initier des modifications en utilisant des fonctionnalités en libre-service telles que le déploiement de clusters, la mise à l’échelle des nœuds de travail ou la suppression de clusters.

L’historique des changements est capturé dans la section Historique des clusters dans l’onglet Aperçu OpenShift Cluster Manager, et est disponible pour vous. L’historique des changements comprend, sans s’y limiter, les journaux des changements suivants:

Il est possible d’implémenter une exclusion de maintenance en évitant les changements dans OpenShift Cluster Manager pour les composants suivants:

L’ingénierie de fiabilité du site Red Hat (SRE) gère l’infrastructure, le code et la configuration d’OpenShift Dedicated à l’aide d’un flux de travail GitOps et de pipelines CI/CD entièrement automatisés. Ce processus permet à Red Hat d’introduire en toute sécurité des améliorations de service sur une base continue sans impact négatif sur les clients.

Chaque changement proposé fait l’objet d’une série de vérifications automatisées dès l’enregistrement. Les changements sont ensuite déployés dans un environnement de mise en scène où ils subissent des tests d’intégration automatisés. Enfin, des changements sont déployés dans l’environnement de production. Chaque étape est entièrement automatisée.

L’examinateur autorisé doit approuver l’avancement à chaque étape. L’examinateur ne peut pas être la même personne qui a proposé le changement. Les modifications et approbations sont entièrement vérifiables dans le cadre du flux de travail GitOps.

Certaines modifications sont publiées à la production progressivement, en utilisant des drapeaux de fonctionnalités pour contrôler la disponibilité de nouvelles fonctionnalités pour des clusters ou des clients spécifiés.

Le logiciel OpenShift Container Platform et l’image immuable du système d’exploitation Red Hat Enterprise Linux CoreOS (RHCOS) sont corrigées pour les bogues et les vulnérabilités dans les mises à niveau régulières du flux z. En savoir plus sur l’architecture RHCOS dans la documentation OpenShift Container Platform.

Le Red Hat ne met pas automatiquement à niveau vos clusters. Il est possible de programmer la mise à niveau des clusters à intervalles réguliers (mise à niveau récurrente) ou une seule fois (mise à niveau individuelle) à l’aide de la console Web OpenShift Cluster Manager. Le Red Hat pourrait mettre à niveau avec force un cluster vers une nouvelle version z-stream seulement si le cluster est affecté par un CVE d’impact critique. Consultez l’historique de tous les événements de mise à niveau de cluster dans la console Web OpenShift Cluster Manager. Consultez la politique sur le cycle de vie pour plus d’informations sur les communiqués.

Red Hat définit et suit une norme de classification des données pour déterminer la sensibilité des données et mettre en évidence le risque inhérent à la confidentialité et à l’intégrité de ces données lors de leur collecte, de leur utilisation, de leur transmission et de leur traitement. Les données appartenant au client sont classées au plus haut niveau de sensibilité et d’exigences de manipulation.

Le service OpenShift Dedicated utilise des services de fournisseurs de cloud tels qu’AWS Key Management Service (KMS) et Google Cloud KMS pour aider à gérer en toute sécurité les clés de chiffrement pour les données persistantes. Ces clés sont utilisées pour chiffrer tous les volumes racine des plans de contrôle, de l’infrastructure et des nœuds de travail. Les clients peuvent spécifier leur propre clé KMS pour chiffrer les volumes racine au moment de l’installation. Les volumes persistants (PV) utilisent également KMS pour la gestion des clés. Les clients peuvent spécifier leur propre clé KMS pour chiffrer les PV en créant une nouvelle StorageClass faisant référence à la clé KMS Amazon Resource Name (ARN) ou ID.

Lorsqu’un client supprime son cluster dédié OpenShift, toutes les données de cluster sont définitivement supprimées, y compris les volumes de données de plan de contrôle et les volumes de données d’application client, un tel volume persistant (PV).

Le Red Hat effectue une analyse périodique de vulnérabilité d’OpenShift Dedicated à l’aide d’outils standard de l’industrie. Les vulnérabilités identifiées sont suivies de leur assainissement en fonction des échéanciers en fonction de la gravité. Les activités d’analyse et d’assainissement des vulnérabilités sont documentées aux fins de vérification par des tiers évaluateurs dans le cadre d’audits de certification de conformité.

Le Red Hat effectue des tests de pénétration périodiques contre OpenShift Dedicated. Les tests sont effectués par une équipe interne indépendante à l’aide d’outils standard de l’industrie et de meilleures pratiques.

Les problèmes qui sont découverts sont prioritaires en fonction de la gravité. Les problèmes constatés dans le cadre de projets open source sont partagés avec la communauté aux fins de résolution.

La société OpenShift Dedicated suit les meilleures pratiques courantes de l’industrie en matière de sécurité et de contrôle. Les certifications sont décrites dans le tableau suivant.