Introduction à OpenShift dédié

Les clients ont la possibilité d’acheter des abonnements annuels d’OpenShift Dedicated (OSD) ou de consommer à la demande via des places de marché en nuage. Les clients peuvent décider d’apporter leur propre compte d’infrastructure cloud, appelé Customer Cloud Subscription (CCS), ou de déployer dans des comptes de fournisseurs de cloud appartenant à Red Hat. Le tableau ci-dessous fournit des informations supplémentaires sur la facturation, ainsi que les options de déploiement prises en charge correspondantes.

Des ressources supplémentaires peuvent être achetées pour un cluster OpenShift dédié, y compris:

Les clients peuvent créer, adapter et supprimer leurs clusters à partir d’OpenShift Cluster Manager, à condition qu’ils aient déjà acheté les abonnements nécessaires.

Les actions disponibles dans Red Hat OpenShift Cluster Manager ne doivent pas être exécutées directement à partir du cluster car cela pourrait causer des effets indésirables, y compris le retour automatique de toutes les actions.

L’OpenShift Dedicated propose des clusters OpenShift Container Platform en tant que service géré sur les fournisseurs de cloud suivants:

Les clusters de zone de disponibilité unique nécessitent un minimum de 2 nœuds de travail pour les clusters d’abonnement au cloud client (CCS) déployés dans une seule zone de disponibilité. Au moins 4 nœuds de travail sont requis pour les clusters non-CCS. Ces 4 nœuds ouvriers sont inclus dans l’abonnement de base.

Les clusters de zones de disponibilité multiples nécessitent un minimum de 3 nœuds de travail pour les clusters d’abonnement au cloud client (CCS), 1 déployé dans chacune des 3 zones de disponibilité. Au moins 9 nœuds de travailleurs sont requis pour les clusters non-CCS. Ces 9 nœuds de travail sont inclus dans l’abonnement de base, et des nœuds supplémentaires doivent être achetés en multiples de 3 pour maintenir une bonne distribution des nœuds.

Les nœuds d’avion de contrôle et d’infrastructure sont déployés et gérés par Red Hat. Il y a au moins 3 nœuds de plan de contrôle qui gèrent les charges de travail etcd et API. Il y a au moins 2 nœuds d’infrastructure qui gèrent les métriques, le routage, la console Web et d’autres charges de travail. Il ne faut pas exécuter de charge de travail sur le plan de contrôle et les nœuds d’infrastructure. Les charges de travail que vous avez l’intention d’exécuter doivent être déployées sur les nœuds des travailleurs.

Consultez la section support de Red Hat ci-dessous pour plus d’informations sur les charges de travail de Red Hat qui doivent être déployées sur les nœuds des travailleurs.

Le logiciel OpenShift Dedicated offre les types et tailles d’instances de nœuds de travail suivants sur AWS:

La société OpenShift Dedicated offre les types et tailles de nœuds de travail suivants sur AWS:

L’OpenShift Dedicated propose les types et tailles de nœuds de travail suivants sur Google Cloud qui sont choisis pour avoir un CPU et une capacité de mémoire communs qui sont les mêmes que les autres types d’instances cloud:

Les régions suivantes sont prises en charge par OpenShift Container Platform 4 et sont prises en charge pour OpenShift Dedicated.

Les SLA du service lui-même sont définies à l’annexe 4 de l’Annexe 4 de l’Accord d’entreprise Red Hat (Services d’abonnement en ligne).

Lorsqu’un cluster passe à un statut de support limité, Red Hat ne surveille plus de manière proactive le cluster, le SLA n’est plus applicable et les crédits demandés contre l’ALS sont refusés. Cela ne signifie pas que vous n’avez plus de support produit. Dans certains cas, le cluster peut revenir à un statut entièrement pris en charge si vous corrigez les facteurs de violation. Cependant, dans d’autres cas, vous devrez peut-être supprimer et recréer le cluster.

Il est possible qu’un cluster passe à un statut de support limité pour de nombreuses raisons, y compris les scénarios suivants:

Lorsque vous avez des questions sur une action spécifique qui pourrait faire passer un cluster à un statut de support limité ou avoir besoin d’une assistance supplémentaire, ouvrez un ticket de support.

Le service OpenShift Dedicated inclut le support Red Hat Premium, auquel vous pouvez accéder en utilisant le portail client Red Hat.

Consultez la page Portée de couverture pour plus de détails sur ce qui est couvert avec le support inclus pour OpenShift Dedicated.

Consultez les SLA dédiés OpenShift pour les temps de réponse de support.

Les journaux d’audit en cluster sont disponibles via Amazon CloudWatch (sur AWS) ou Google Cloud Logging (sur GCP), si l’intégration est activée. Lorsque l’intégration n’est pas activée, vous pouvez demander les journaux d’audit en ouvrant un dossier d’assistance. Les demandes de journaux d’audit doivent préciser une date et une période ne dépassant pas 21 jours. Lorsque vous demandez des journaux d’audit, les clients doivent savoir que les journaux d’audit sont de nombreux GB par jour en taille.

Les journaux d’application envoyés à STDOUT sont transmis à Amazon CloudWatch (sur AWS) ou Google Cloud Logging (sur GCP) via la pile de journalisation des clusters, s’il est installé.

Les clusters dédiés OpenShift sont livrés avec une pile Prometheus/Grafana intégrée pour la surveillance des clusters, y compris les métriques CPU, mémoire et réseau. Ceci est accessible via la console Web et peut également être utilisé pour afficher l’état et la capacité / utilisation au niveau du cluster via un tableau de bord Grafana. Ces métriques permettent également un autoscaling de pod horizontal basé sur des métriques CPU ou mémoire fournies par un utilisateur dédié OpenShift.

Les notifications de cluster sont des messages sur l’état, la santé ou les performances de votre cluster.

Les notifications de cluster sont la principale façon dont Red Hat Site Reliability Engineering (SRE) communique avec vous sur la santé de votre cluster géré. Le SRE peut également utiliser des notifications de cluster pour vous inviter à effectuer une action afin de résoudre ou d’empêcher un problème avec votre cluster.

Les propriétaires de clusters et les administrateurs doivent régulièrement examiner et agir les notifications de clusters pour s’assurer que les clusters restent en bonne santé et pris en charge.

Dans l’onglet Historique des clusters de votre cluster, vous pouvez afficher les notifications de cluster dans la console de cloud hybride Red Hat. Par défaut, seul le propriétaire du cluster reçoit des notifications de cluster sous forme d’e-mails. Lorsque d’autres utilisateurs doivent recevoir des e-mails de notification en cluster, ajoutez chaque utilisateur comme contact de notification pour votre cluster.

Afin d’utiliser un nom d’hôte personnalisé pour un itinéraire, vous devez mettre à jour votre fournisseur DNS en créant un enregistrement de nom canonique (CNAME). L’enregistrement CNAME doit cartographier le nom d’hôte du routeur canonique OpenShift à votre domaine personnalisé. Le nom d’hôte du routeur canonique OpenShift est affiché sur la page Détails de l’itinéraire après la création d’une Route. Alternativement, un enregistrement générique CNAME peut être créé une fois pour acheminer tous les sous-domaines d’un nom d’hôte donné vers le routeur du cluster.

Les domaines et sous-domaines personnalisés ne sont pas disponibles pour les routes de service de la plate-forme, par exemple, les routes API ou console Web, ou pour les routes d’application par défaut.

Le programme OpenShift Dedicated inclut les certificats de sécurité TLS nécessaires à la fois pour les services internes et externes sur le cluster. Dans le cas des routes externes, il y a deux certificats de wildcard TLS distincts qui sont fournis et installés sur chaque cluster, un pour la console Web et les noms d’hôte par défaut d’itinéraire et le second pour le point de terminaison API. Let's Encrypt est l’autorité de certification utilisée pour les certificats. Les itinéraires au sein du cluster, par exemple, le point de terminaison interne de l’API, utilisent les certificats TLS signés par l’autorité de certification intégrée du cluster et exigent le paquet CA disponible dans chaque pod pour faire confiance au certificat TLS.

Le logiciel OpenShift Dedicated prend en charge l’utilisation d’autorités de certification personnalisées à utiliser par les builds lors de l’extraction d’images à partir d’un registre d’images.

L’OpenShift Dedicated utilise jusqu’à 5 balanceurs de charge différents:

Dans le cas des clusters dédiés à OpenShift non-CCS, l’utilisation du réseau est mesurée en fonction du transfert de données entre le trafic entrant, VPC peering, VPN et AZ. Dans un cluster de base non-CCS OpenShift dédié, 12 To d’E/S réseau sont fournis. Des E/S supplémentaires de réseau peuvent être achetées par incréments de 12 To. Dans le cas des clusters dédiés à CCS OpenShift, l’utilisation du réseau n’est pas surveillée et est facturée directement par le fournisseur de cloud.

Les administrateurs de projet peuvent ajouter des annotations d’itinéraire à de nombreuses fins différentes, y compris le contrôle d’entrée grâce à la liste d’autorisations IP.

Les stratégies d’entrée peuvent également être modifiées en utilisant les objets NetworkPolicy, qui exploitent le plugin ovs-networkpolicy. Cela permet un contrôle total de la stratégie réseau d’entrée jusqu’au niveau pod, y compris entre les pods sur le même cluster et même dans le même espace de noms.

L’ensemble du trafic d’entrée de cluster passe par les équilibreurs de charge définis. L’accès direct à tous les nœuds est bloqué par la configuration du cloud.

Le contrôle du trafic par le biais d’objets EgressNetworkPolicy peut être utilisé pour prévenir ou limiter le trafic sortant dans OpenShift Dedicated.

Le trafic public sortant du plan de contrôle et des nœuds d’infrastructure est nécessaire pour maintenir la sécurité de l’image de cluster et la surveillance des clusters. Cela nécessite que l’itinéraire 0.0.0.0/0 appartienne uniquement à la passerelle Internet; il n’est pas possible d’acheminer cette gamme sur des connexions privées.

Les clusters dédiés à OpenShift utilisent les passerelles NAT pour présenter une IP publique statique pour tout trafic public sortant du cluster. Chaque sous-réseau dans lequel un cluster est déployé reçoit une passerelle NAT distincte. Dans le cas des clusters déployés sur AWS avec plusieurs zones de disponibilité, jusqu’à 3 adresses IP statiques uniques peuvent exister pour le trafic de sortie de cluster. Dans le cas des clusters déployés sur Google Cloud, quelle que soit la topologie de la zone de disponibilité, il y aura 1 adresse IP statique pour le trafic de nœuds de travail. Le trafic qui reste à l’intérieur du cluster ou qui ne sort pas vers l’Internet public ne passera pas par la passerelle NAT et aura une adresse IP source appartenant au nœud d’origine du trafic. Les adresses IP des nœuds sont dynamiques et, par conséquent, un client ne devrait pas compter sur l’autorisation d’une adresse IP individuelle lors de l’accès aux ressources privées.

Les clients peuvent déterminer leurs adresses IP statiques publiques en exécutant un pod sur le cluster, puis en interrogeant un service externe. À titre d’exemple:

oc run ip-lookup --image=busybox -i -t --restart=Never --rm -- /bin/sh -c "/bin/nslookup -type=a myip.opendns.com resolver1.opendns.com | grep -E 'Address: [0-9.]+'"

$ oc run ip-lookup --image=busybox -i -t --restart=Never --rm -- /bin/sh -c "/bin/nslookup -type=a myip.opendns.com resolver1.opendns.com | grep -E 'Address: [0-9.]+'"

L’OpenShift Dedicated permet la configuration d’une connexion réseau privée via plusieurs technologies gérées par des fournisseurs de cloud:

Dans le cas des clusters dédiés à OpenShift qui ont une configuration de réseau cloud privé, un client peut spécifier des serveurs DNS internes disponibles sur cette connexion privée qui devraient être interrogés pour les domaines explicitement fournis.

Les vérifications réseau s’exécutent automatiquement lorsque vous déployez un cluster dédié OpenShift dans un cloud privé virtuel (VPC) existant ou créez un pool de machines supplémentaire avec un sous-réseau qui est nouveau à votre cluster. Les vérifications valident votre configuration réseau et mettent en évidence les erreurs, vous permettant de résoudre les problèmes de configuration avant le déploiement.

Il est également possible d’exécuter manuellement les vérifications réseau pour valider la configuration d’un cluster existant.

Les nœuds de plan de contrôle utilisent le stockage crypté au repos-EBS.

Les volumes EBS utilisés pour les volumes persistants (PV) sont cryptés au repos par défaut.

Les volumes persistants (PV) sont soutenus par AWS EBS et Google Cloud, qui utilise le mode d’accès ReadWriteOnce (RWO). Dans un cluster de base non-CCS OpenShift dédié, 100 Go de stockage par bloc sont fournis pour les PV, qui sont fournis dynamiquement et recyclés en fonction des demandes d’application. Le stockage persistant supplémentaire peut être acheté par incréments de 500 Go.

Les PVS ne peuvent être attachés qu’à un seul nœud à la fois et sont spécifiques à la zone de disponibilité dans laquelle ils ont été fournis, mais ils peuvent être attachés à n’importe quel nœud dans la zone de disponibilité.

Chaque fournisseur de cloud a ses propres limites pour combien de PV peuvent être attachés à un seul nœud. Consultez les limites de type d’instance AWS ou les types de machines personnalisées de Google Cloud Platform pour plus de détails.

Le pilote AWS CSI peut être utilisé pour fournir la prise en charge RWX pour OpenShift Dedicated sur AWS. L’opérateur communautaire est fourni pour simplifier la configuration. Consultez AWS EFS Setup for OpenShift Dedicated et Red Hat OpenShift Service sur AWS.

Les sauvegardes de données d’application et d’application ne font pas partie du service dédié OpenShift. Dans chaque cluster dédié OpenShift, tous les objets Kubernetes sont sauvegardés pour faciliter une récupération rapide dans le cas peu probable qu’un cluster devienne irréparable.

Les sauvegardes sont stockées dans un seau de stockage d’objets sécurisé (Multi-AZ) dans le même compte que le cluster. Les volumes racine des nœuds ne sont pas sauvegardés parce que Red Hat Enterprise Linux CoreOS est entièrement géré par le cluster OpenShift Container Platform et qu’aucune donnée étatique ne doit être stockée sur le volume racine d’un nœud.

Le tableau suivant montre la fréquence des sauvegardes:

La mise à l’échelle automatique des nœuds est disponible sur OpenShift Dedicated. Consultez À propos des nœuds autoscaling sur un cluster pour plus d’informations sur les nœuds autoscaling sur un cluster.

Les clients peuvent créer et exécuter DaemonSets sur OpenShift Dedicated. Afin de limiter DaemonSets à fonctionner uniquement sur les nœuds de travail, utilisez le nodeSelector suivant:

...
spec:
  nodeSelector:
    role: worker
...

...
spec:
  nodeSelector:
    role: worker
...

Dans un cluster de zones de disponibilité multiple, les nœuds de contrôle sont répartis entre les zones de disponibilité et au moins trois nœuds de travail sont requis dans chaque zone de disponibilité.

Les étiquettes de nœuds personnalisés sont créées par Red Hat lors de la création de nœuds et ne peuvent pas être modifiées sur les clusters dédiés OpenShift pour le moment.

Le service OpenShift Dedicated est mis à jour avec la dernière version OpenShift Container Platform.

Consultez le cycle de vie dédié OpenShift pour plus d’informations sur la politique et les procédures de mise à niveau.

Les conteneurs Windows ne sont pas disponibles sur OpenShift Dedicated pour le moment.

L’OpenShift Dedicated fonctionne sur OpenShift 4 et utilise CRI-O comme seul moteur de conteneur disponible.

Le système OpenShift Dedicated fonctionne sur OpenShift 4 et utilise Red Hat Enterprise Linux CoreOS comme système d’exploitation pour tous les nœuds de plan de contrôle et de travail.

Les charges de travail Red Hat se réfèrent généralement aux opérateurs fournis par Red Hat mis à disposition par l’intermédiaire de l’opérateur Hub. Les charges de travail Red Hat ne sont pas gérées par l’équipe Red Hat SRE et doivent être déployées sur les nœuds des travailleurs. Ces opérateurs peuvent nécessiter des abonnements supplémentaires à Red Hat et peuvent entraîner des coûts d’infrastructure cloud supplémentaires. Des exemples de ces opérateurs fournis par Red Hat sont:

Les opérateurs inscrits sur le marché OperatorHub devraient être disponibles pour l’installation. Les opérateurs installés à partir de OperatorHub, y compris Red Hat Operators, ne sont pas gérés SRE dans le cadre du service dédié OpenShift. Consultez le portail client Red Hat pour plus d’informations sur la compatibilité d’un opérateur donné.

L’authentification pour le cluster est configurée dans le cadre du processus de création de clusters Red Hat OpenShift Cluster Manager. « OpenShift n’est pas un fournisseur d’identité, et tout accès au cluster doit être géré par le client dans le cadre de sa solution intégrée. Le provisionnement de plusieurs fournisseurs d’identité fournis en même temps est pris en charge. Les fournisseurs d’identité suivants sont pris en charge:

Les conteneurs privilégiés ne sont pas disponibles par défaut sur OpenShift Dedicated. Les contraintes de contexte de sécurité anyuid et non racine sont disponibles pour les membres du groupe admins dédiés, et devraient traiter de nombreux cas d’utilisation. Les conteneurs privilégiés ne sont disponibles que pour les utilisateurs de cluster-admin.

En plus des utilisateurs normaux, OpenShift Dedicated fournit l’accès à un groupe dédié OpenShift spécifique appelé dédié-admin. Les utilisateurs du cluster qui sont membres du groupe admin dédié:

En tant qu’administrateur d’OpenShift Dedicated with Customer Cloud Subscriptions (CCS), vous avez accès au rôle cluster-admin. Alors qu’ils sont connectés à un compte avec le rôle de cluster-admin, les utilisateurs ont pour la plupart un accès illimité au contrôle et à la configuration du cluster. Il y a certaines configurations qui sont bloquées avec des webhooks pour empêcher le désétablissement du cluster, ou parce qu’elles sont gérées dans OpenShift Cluster Manager et tout changement dans l’inclusion serait écrasé.

L’ensemble des utilisateurs, par défaut, ont la possibilité de créer, mettre à jour et supprimer leurs projets. Cela peut être restreint si un membre du groupe admin dédié supprime le rôle d’auto-fournisseur des utilisateurs authentifiés:

oc adm policy remove-cluster-role-from-group self-provisioner system:authenticated:oauth

$ oc adm policy remove-cluster-role-from-group self-provisioner system:authenticated:oauth

Les restrictions peuvent être annulées en appliquant:

oc adm policy add-cluster-role-to-group self-provisioner system:authenticated:oauth

$ oc adm policy add-cluster-role-to-group self-provisioner system:authenticated:oauth

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.

Chaque cluster dédié OpenShift est protégé par une configuration réseau sécurisée au niveau de l’infrastructure cloud en utilisant les règles de pare-feu (AWS Security Groups ou Google Cloud Compute Engine). Les clients dédiés sur AWS sont également protégés contre les attaques DDoS avec AWS Shield Standard. De même, tous les équilibreurs de charge GCP et les adresses IP publiques utilisées par OpenShift Dedicated on GCP sont protégés contre les attaques DDoS avec Google Cloud Armor Standard.

Dans OpenShift Dedicated, le stockage du plan de contrôle est crypté au repos par défaut et cela inclut le cryptage des volumes etcd. Ce chiffrement de niveau de stockage est fourni via la couche de stockage du fournisseur de cloud.

Il est également possible d’activer le chiffrement etcd, qui chiffre les valeurs clés dans etcd, mais pas les clés. Lorsque vous activez le cryptage etcd, les ressources suivantes du serveur API Kubernetes et OpenShift API sont cryptées:

La fonction de chiffrement etcd n’est pas activée par défaut et ne peut être activée qu’au moment de l’installation du cluster. Bien que le chiffrement etcd soit activé, les valeurs clés etcd sont accessibles à toute personne ayant accès aux nœuds de plan de contrôle ou aux privilèges cluster-admin.

Le client est responsable de la gestion des incidents et des opérations des données d’application client et de tout réseau personnalisé que le client a configuré pour le réseau cluster ou le réseau virtuel.

Il incombe à Red Hat de modifier l’infrastructure et les services de cluster que le client contrôlera, ainsi que de maintenir les versions des nœuds d’avion de contrôle, des nœuds et des services d’infrastructure et des nœuds de travail. Le client est responsable d’initier des demandes de changement d’infrastructure et d’installer et de maintenir des services et des configurations de réseau optionnels sur le cluster, ainsi que toutes les modifications apportées aux données client et aux applications client.

La matrice d’autorisation d’accès et d’identité comprend les responsabilités de gestion de l’accès autorisé aux grappes, aux applications et aux ressources d’infrastructure. Cela inclut des tâches telles que la fourniture de mécanismes de contrôle d’accès, l’authentification, l’autorisation et la gestion de l’accès aux ressources.

Les responsabilités et les contrôles liés à la conformité sont les suivants:

La reprise après sinistre comprend la sauvegarde des données et de la configuration, la reproduction des données et la configuration dans l’environnement de reprise après sinistre, et le basculement sur les événements de catastrophe.

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.

Dans la liste des sous-traitants disponibles, consultez la liste des sous-processeurs Red Hat sur le portail client Red Hat.

Accès SRES aux clusters dédiés à OpenShift via un proxy. Le proxy crée un compte de service dans un cluster OpenShift dédié pour les SREs lorsqu’ils se connectent. Comme aucun fournisseur d’identité n’est configuré pour les clusters dédiés OpenShift, les SRE accèdent au proxy en exécutant un conteneur de console Web local. Le SRES n’accède pas directement à la console web cluster. Le SRES doit s’authentifier en tant qu’utilisateurs individuels afin d’assurer l’auditabilité. Les tentatives d’authentification sont enregistrées sur un système de gestion des informations de sécurité et des événements (SIEM).

Le Red Hat SRE adhère au principe du moindre privilège lors de l’accès aux composants OpenShift Dedicated et des fournisseurs de cloud public. Il existe quatre catégories de base d’accès SRE manuels:

Chacun de ces types d’accès a différents niveaux d’accès aux composants:

Le personnel de Red Hat n’a pas accès aux comptes d’infrastructure cloud dans le cadre des opérations courantes d’OpenShift Dedicated. À des fins de dépannage d’urgence, Red Hat SRE dispose de procédures bien définies et vérifiables pour accéder aux comptes d’infrastructure cloud.

Dans AWS, les SRE génèrent un jeton AWS de courte durée pour l’utilisateur BYOCAdminAccess à l’aide du service de jetons de sécurité AWS (STS). L’accès au jeton STS est enregistré et traçable pour les utilisateurs individuels. Le BYOCAdminAccess a la politique AdministratorAccess IAM jointe.

Dans Google Cloud, les SRE accèdent aux ressources après avoir été authentifiées contre un fournisseur d’identité Red Hat SAML (IDP). Le PDI autorise les jetons qui ont des expirations de temps à vie. L’émission du jeton est vérifiable par Red Hat IT d’entreprise et liée à un utilisateur individuel.

Les membres de l’équipe de Red Hat CEE ont généralement accès en lecture seule à certaines parties du cluster. En particulier, CEE a un accès limité aux espaces de noms de cœur et de produits et n’a pas accès aux espaces de noms des clients.

Le compte Infrastructure Cloud fait référence au compte AWS ou Google Cloud sous-jacent

L’accès du client est limité aux espaces de noms créés par le client et aux autorisations accordées par RBAC par le rôle d’administrateur client. L’accès à l’infrastructure sous-jacente ou aux espaces de noms de produits n’est généralement pas autorisé sans accès cluster-admin. De plus amples informations sur l’accès et l’authentification des clients se trouvent dans la section Compréhension de l’authentification de la documentation.

L’accès aux nouveaux utilisateurs SRE nécessite l’approbation de la direction. Les comptes SRE séparés ou transférés sont supprimés en tant qu’utilisateurs autorisés par le biais d’un processus automatisé. En outre, SRE effectue un examen périodique des accès, y compris la signature par la direction des listes d’utilisateurs autorisées.

D’après la conception, les gousses sont censées exister pendant une courte période. La mise à l’échelle appropriée des services de sorte que plusieurs instances de vos pods d’application sont en cours d’exécution protège contre les problèmes avec n’importe quel pod ou conteneur individuel. Le programmeur de nœuds peut également s’assurer que ces charges de travail sont réparties entre différents nœuds de travail afin d’améliorer encore la résilience.

Lors de la prise en compte des éventuelles défaillances de pod, il est également important de comprendre comment le stockage est attaché à vos applications. Les volumes persistants uniques attachés à des pods uniques ne peuvent pas tirer parti de tous les avantages de la mise à l’échelle des pod, tandis que les bases de données reproduites, les services de base de données ou le stockage partagé peuvent.

Afin d’éviter les perturbations de vos applications lors de la maintenance planifiée, comme les mises à niveau, il est important de définir un budget de perturbation de pod. Ceux-ci font partie de l’API Kubernetes et peuvent être gérés avec l’OpenShift CLI (oc) comme d’autres types d’objets. Ils permettent la spécification des contraintes de sécurité sur les gousses pendant les opérations, telles que l’évacuation d’un nœud pour l’entretien.

Les nœuds ouvriers sont les machines virtuelles qui contiennent vos pods d’application. Par défaut, un cluster dédié OpenShift dispose d’un minimum de quatre nœuds de travail pour un cluster de zone de disponibilité unique. En cas de défaillance d’un nœud ouvrier, les gousses sont transférées vers des nœuds de travail fonctionnels, tant qu’il y a suffisamment de capacité, jusqu’à ce que tout problème avec un nœud existant soit résolu ou que le nœud soit remplacé. Le plus grand nombre de nœuds de travail signifie plus de protection contre les pannes de nœuds uniques et assure une capacité de cluster appropriée pour les gousses reprogrammées en cas de défaillance du nœud.

Les clusters dédiés OpenShift ont au moins trois nœuds de plan de contrôle et trois nœuds d’infrastructure préconfigurés pour une haute disponibilité, soit dans une seule zone, soit sur plusieurs zones en fonction du type de cluster que vous avez sélectionné. Cela signifie que l’avion de contrôle et les nœuds d’infrastructure ont la même résilience des nœuds ouvriers, avec l’avantage supplémentaire d’être entièrement géré par Red Hat.

Dans le cas d’une panne complète des nœuds de plan de contrôle, les API OpenShift ne fonctionneront pas, et les pods de nœuds de travail existants ne seront pas affectés. Cependant, s’il y a aussi une panne de gousse ou de nœud en même temps, les nœuds de plan de contrôle devront récupérer avant que de nouveaux gousses ou nœuds puissent être ajoutés ou programmés.

L’ensemble des services fonctionnant sur les nœuds d’infrastructure sont configurés par Red Hat pour être hautement disponibles et distribués à travers les nœuds d’infrastructure. En cas de panne complète de l’infrastructure, ces services ne seront pas disponibles jusqu’à ce que ces nœuds aient été récupérés.

La défaillance d’une zone d’un fournisseur de cloud public affecte tous les composants virtuels, tels que les nœuds de travail, le blocage ou le stockage partagé, et les équilibreurs de charge spécifiques à une seule zone de disponibilité. Afin de se protéger contre une défaillance de zone, OpenShift Dedicated offre l’option pour les clusters qui sont répartis sur trois zones de disponibilité, appelées clusters de zone multidisponibilité. Les charges de travail apatrides existantes sont redistribuées dans des zones non affectées en cas de panne, tant qu’il y a suffisamment de capacité.

Lorsque vous avez déployé une application étatique, le stockage est un composant essentiel et doit être pris en compte lors de la réflexion sur la haute disponibilité. Le PV de stockage d’un seul bloc est incapable de résister aux pannes même au niveau de la pod. Les meilleurs moyens de maintenir la disponibilité du stockage sont d’utiliser des solutions de stockage répliquées, un stockage partagé qui n’est pas affecté par des pannes, ou un service de base de données indépendant du cluster.