Red Hat Summit2.4. Accès au compte SRE et service
2.4.1. Gestion de l’identité et des accès
La plupart des accès par les équipes d’ingénierie de fiabilité du site de Red Hat (SRE) se font en utilisant des opérateurs de clusters par le biais d’une gestion automatisée de la configuration.
Les clusters OpenShift dédiés aux clusters Google Cloud Platform (GCP) créés avec le type d’authentification WIF (Workload Identify Federation) n’utilisent pas les opérateurs pour l’accès SRE. Au lieu de cela, les rôles nécessaires à l’accès au compte SRE sont attribués au groupe d’accès sd-sre-platform-gcp-access dans le cadre de la création de la configuration WIF et sont validés avant le déploiement du cluster par le gestionnaire de cluster OpenShift. Consultez les ressources supplémentaires pour plus d’informations sur les configurations WIF.
2.4.1.1. Les sous-traitants
Dans la liste des sous-traitants disponibles, consultez la liste des sous-processeurs Red Hat sur le portail client Red Hat.
2.4.1.2. Accès SRE à tous les clusters dédiés OpenShift
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).
2.4.1.3. Contrôles d’accès privilégiés dans OpenShift Dedicated
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:
- Accès administrateur SRE via le portail client Red Hat avec une authentification normale à deux facteurs et aucune élévation privilégiée.
- L’administrateur SRE accède par l’intermédiaire du SSO d’entreprise Red Hat avec une authentification normale à deux facteurs et aucune élévation privilégiée.
- Élévation OpenShift, qui est une élévation manuelle utilisant Red Hat SSO. Il fait l’objet d’une vérification complète et l’approbation de la direction est requise pour chaque opération SRE.
- Accès ou élévation des fournisseurs de cloud, qui est une élévation manuelle pour la console fournisseur de cloud ou l’accès CLI. L’accès est limité à 60 minutes et est entièrement audité.
Chacun de ces types d’accès a différents niveaux d’accès aux composants:
| Composante | Accès administrateur SRE typique (Portail client Red Hat) | Accès administrateur SRE typique (Red Hat SSO) | Élévation de OpenShift | Accès aux fournisseurs de cloud |
|---|---|---|---|---|
| Gestionnaire de cluster OpenShift | DE R/W | Aucun accès | Aucun accès | Aucun accès |
| Console Web OpenShift | Aucun accès | DE R/W | DE R/W | Aucun accès |
| Le système d’exploitation des nœuds | Aucun accès | Liste spécifique des autorisations élevées du système d’exploitation et du réseau. | Liste spécifique des autorisations élevées du système d’exploitation et du réseau. | Aucun accès |
| Console AWS | Aucun accès | Aucun accès, mais il s’agit du compte utilisé pour demander l’accès aux fournisseurs de cloud. | Aucun accès | L’ensemble des autorisations des fournisseurs de cloud utilisant l’identité SRE. |
2.4.1.4. Accès SRE aux comptes d’infrastructure cloud
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.
2.4.1.5. Accès au support Red Hat
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 rôle | Espace de noms de base | Espace de noms de produit en couches | Espace de noms du client | Compte infrastructure cloud* |
|---|---|---|---|---|
| À propos de OpenShift SRE | Lire: Tout Écrire: Très Limité [1] | Lire: Tout Écrire: Aucun | Lire: Aucune[2] Écrire: Aucun | Lire: Tout [3] Ecrire : Tout [3] |
| CEE | Lire: Tout Écrire: Aucun | Lire: Tout Écrire: Aucun | Lire: Aucune[2] Écrire: Aucun | Lire: Aucun Écrire: Aucun |
| Administrateur client | Lire: Aucun Écrire: Aucun | Lire: Aucun Écrire: Aucun | Lire: Tout Ecrire: Tous | Lire: Limitée[4] Ecrire: Limited[4] |
| Client utilisateur | Lire: Aucun Écrire: Aucun | Lire: Aucun Écrire: Aucun | Lire: Limitée[5] Ecrire: Limited[5] | Lire: Aucun Écrire: Aucun |
| Les autres | Lire: Aucun Écrire: Aucun | Lire: Aucun Écrire: Aucun | Lire: Aucun Écrire: Aucun | Lire: Aucun Écrire: Aucun |
Le compte Infrastructure Cloud fait référence au compte AWS ou Google Cloud sous-jacent
- Limité à traiter les cas d’utilisation courante tels que les déploiements défaillants, la mise à niveau d’un cluster et le remplacement des nœuds de mauvais travailleurs.
- Les associés Red Hat n’ont pas accès aux données client par défaut.
- L’accès SRE au compte d’infrastructure cloud est une procédure de dépannage exceptionnelle lors d’un incident documenté.
- L’administrateur client a un accès limité à la console de compte d’infrastructure cloud via Cloud Infrastructure Access.
- Limité à ce qui est accordé par RBAC par l’administrateur client, ainsi que les espaces de noms créés par l’utilisateur.
2.4.1.6. Accès client
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.
2.4.1.7. Approbation et examen de l’accès
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.
2.4.2. Accès au cluster SRE
L’accès SRE aux clusters dédiés OpenShift est contrôlé par plusieurs couches d’authentification requise, qui sont toutes gérées par une politique stricte de l’entreprise. Les tentatives d’authentification pour accéder à un cluster et les modifications apportées au sein d’un cluster sont enregistrées dans les journaux d’audit, ainsi que l’identité spécifique du compte du SRE responsable de ces actions. Ces journaux d’audit permettent de s’assurer que toutes les modifications apportées par les SRE au cluster d’un client respectent les politiques et procédures strictes qui composent les lignes directrices sur les services gérés de Red Hat.
L’information présentée ci-dessous est un aperçu du processus qu’une SRE doit effectuer pour accéder au cluster d’un client.
- Le SRE demande un jeton d’identification actualisé de la Red Hat SSO (Cloud Services). Cette demande est authentifiée. Le jeton est valable quinze minutes. Après l’expiration du jeton, vous pouvez rafraîchir le jeton à nouveau et recevoir un nouveau jeton. La capacité de se rafraîchir à un nouveau jeton est indéfinie; cependant, la capacité de se rafraîchir à un nouveau jeton est révoquée après 30 jours d’inactivité.
- Le SRE se connecte au VPN Red Hat. L’authentification au VPN est complétée par le système Red Hat Corporate Identity and Access Management (RH IAM). Avec RH IAM, les SRE sont multifactorielles et peuvent être gérées en interne par les groupes et les processus existants d’intégration et de hors-bord. Après qu’un SRE soit authentifié et connecté, le SRE peut accéder à l’avion de gestion de flotte de services cloud. Les modifications apportées au plan de gestion de la flotte de services cloud nécessitent de nombreuses couches d’approbation et sont maintenues par une politique stricte de l’entreprise.
- Après la fin de l’autorisation, le SRE se connecte à l’avion de gestion de flotte et reçoit un compte de service que l’avion de gestion de flotte a créé. Le jeton est valable pendant 15 minutes. Après que le jeton n’est plus valide, il est supprimé.
Avec l’accès accordé au plan de gestion de flotte, SRE utilise diverses méthodes pour accéder aux clusters, en fonction de la configuration du réseau.
- Accès à un cluster privé ou public : Demande est envoyée via un balanceur de charge réseau spécifique (NLB) à l’aide d’une connexion HTTP chiffrée sur le port 6443.
- Accès à un cluster PrivateLink : Demande est envoyée à la passerelle Red Hat Transit, qui se connecte ensuite à un PCV Red Hat par région. Le VPC qui reçoit la demande dépendra de la région du cluster privé cible. Dans le VPC, il y a un sous-réseau privé qui contient le point de terminaison PrivateLink au cluster PrivateLink du client.
- Accès à un cluster Private Service Connect (PSC) : Demande est envoyée à l’infrastructure de backend interne de Red Hat, qui dirige le trafic via un réseau sécurisé et fiable vers le projet de gestion de Red Hat dans GCP. Le projet Red Hat Management comprend VPC, qui est configuré avec des sous-réseaux dans plusieurs régions, chacune contenant un point de terminaison PSC qui fournit un accès privé au cluster du client dans la région respective. Le trafic est acheminé par le sous-réseau régional approprié, assurant un accès sécurisé et privé au cluster sans traverser l’Internet public.
2.4.3. Comment les comptes de services assument les rôles AWS IAM dans les projets appartenant à SRE
Lorsque vous installez un cluster dédié OpenShift qui utilise le service de jetons de sécurité AWS (STS), des rôles AWS Identity and Access Management (IAM) spécifiques au cluster sont créés. Ces rôles IAM permettent aux opérateurs de clusters dédiés d’OpenShift d’exécuter la fonctionnalité principale d’OpenShift.
Les opérateurs de cluster utilisent les comptes de service pour assumer des rôles IAM. Lorsqu’un compte de service assume un rôle IAM, des informations d’identification STS temporaires sont fournies pour que le compte de service puisse être utilisé dans la pod de l’opérateur du cluster. Lorsque le rôle assumé dispose des privilèges AWS nécessaires, le compte de service peut exécuter les opérations SDK AWS dans la pod.
Flux de travail pour assumer les rôles AWS IAM dans les projets appartenant à SRE
Le diagramme suivant illustre le flux de travail pour assumer les rôles AWS IAM dans les projets appartenant à SRE:
Figure 2.1. Flux de travail pour assumer les rôles AWS IAM dans les projets appartenant à SRE
Le flux de travail comporte les étapes suivantes:
Dans chaque projet qu’un opérateur de cluster exécute, la spécification de déploiement de l’opérateur dispose d’une monture de volume pour le jeton de compte de service projeté, et d’un secret contenant une configuration d’identification AWS pour le pod. Le jeton est lié à l’audience et au temps. Chaque heure, OpenShift Dedicated génère un nouveau jeton, et le SDK AWS lit le secret monté contenant la configuration d’identification AWS. Cette configuration a un chemin vers le jeton monté et le rôle AWS IAM ARN. La configuration d’identification du secret comprend les éléments suivants:
- La variable $AWS_ARN_ROLE possède l’ARN pour le rôle IAM qui possède les autorisations requises pour exécuter les opérations SDK AWS.
- * une variable $AWS_WEB_IDENTITY_TOKEN_FILE qui a le chemin complet dans le pod vers le jeton OpenID Connect (OIDC) pour le compte de service. Le chemin complet est /var/run/secrets/openshift/serviceaccount/token.
- Lorsqu’un opérateur de cluster doit assumer un rôle AWS IAM pour accéder à un service AWS (tel qu’EC2), le code client AWS SDK s’exécutant sur l’opérateur invoque l’appel de l’API AssumeRoleWithWebIdentity.
Le jeton OIDC est transmis du pod au fournisseur OIDC. Le fournisseur authentifie l’identité du compte de service si les exigences suivantes sont remplies:
- La signature d’identité est valide et signée par la clé privée.
L’audience sts.amazonaws.com est listée dans le jeton OIDC et correspond à l’audience configurée dans le fournisseur OIDC.
NoteDans OpenShift Dedicated with STS clusters, le fournisseur OIDC est créé lors de l’installation et défini comme émetteur de compte de service par défaut. L’audience sts.amazonaws.com est définie par défaut dans le fournisseur OIDC.
- Le jeton OIDC n’a pas expiré.
- La valeur de l’émetteur dans le jeton a l’URL pour le fournisseur OIDC.
- Lorsque le compte de projet et de service est dans le champ d’application de la politique de confiance pour le rôle de l’IAM qui est assumé, l’autorisation réussit.
- Après une authentification et une autorisation réussies, les informations d’identification AWS STS temporaires sous la forme d’un jeton d’accès AWS, d’une clé secrète et d’un jeton de session sont transmises à la pod pour utilisation par le compte de service. En utilisant les informations d’identification, le compte de service reçoit temporairement les autorisations AWS activées dans le rôle IAM.
- Lorsque l’opérateur de cluster s’exécute, l’opérateur qui utilise le SDK AWS dans la pod consomme le secret qui a le chemin vers le compte de service projeté et le rôle AWS IAM ARN pour s’authentifier contre le fournisseur OIDC. Le fournisseur OIDC retourne des informations d’identification STS temporaires pour l’authentification par rapport à l’API AWS.
2.4.4. Ressources supplémentaires
En savoir plus sur la configuration WIF et les rôles d’accès SRE, voir Création d’une configuration WIF.
'%20d='M201.5%20305.5c-13.8%200-24.9-11.1-24.9-24.6%200-13.8%2011.1-24.9%2024.9-24.9%2013.6%200%2024.6%2011.1%2024.6%2024.9%200%2013.6-11.1%2024.6-24.6%2024.6zM504%20256c0%20137-111%20248-248%20248S8%20393%208%20256%20119%208%20256%208s248%20111%20248%20248zm-132.3-41.2c-9.4%200-17.7%203.9-23.8%2010-22.4-15.5-52.6-25.5-86.1-26.6l17.4-78.3%2055.4%2012.5c0%2013.6%2011.1%2024.6%2024.6%2024.6%2013.8%200%2024.9-11.3%2024.9-24.9s-11.1-24.9-24.9-24.9c-9.7%200-18%205.8-22.1%2013.8l-61.2-13.6c-3-.8-6.1%201.4-6.9%204.4l-19.1%2086.4c-33.2%201.4-63.1%2011.3-85.5%2026.8-6.1-6.4-14.7-10.2-24.1-10.2-34.9%200-46.3%2046.9-14.4%2062.8-1.1%205-1.7%2010.2-1.7%2015.5%200%2052.6%2059.2%2095.2%20132%2095.2%2073.1%200%20132.3-42.6%20132.3-95.2%200-5.3-.6-10.8-1.9-15.8%2031.3-16%2019.8-62.5-14.9-62.5zM302.8%20331c-18.2%2018.2-76.1%2017.9-93.6%200-2.2-2.2-6.1-2.2-8.3%200-2.5%202.5-2.5%206.4%200%208.6%2022.8%2022.8%2087.3%2022.8%20110.2%200%202.5-2.2%202.5-6.1%200-8.6-2.2-2.2-6.1-2.2-8.3%200zm7.7-75c-13.6%200-24.6%2011.1-24.6%2024.9%200%2013.6%2011.1%2024.6%2024.6%2024.6%2013.8%200%2024.9-11.1%2024.9-24.6%200-13.8-11-24.9-24.9-24.9z'/%3e%3c/svg%3e){kind=small}