Red Hat Summit2.10. Accès au compte SRE et service
L’accès à Red Hat OpenShift Service sur les clusters AWS (ROSA) est décrit par la gestion de l’identité et de l’accès.
2.10.1. Gestion de l’identité et des accès
La plupart des accès par les équipes de Red Hat SRE se font en utilisant des opérateurs de clusters grâce à une gestion automatisée de la configuration.
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.10.2. Accès au cluster SRE
L’accès SRE à Red Hat OpenShift Service sur les clusters AWS (ROSA) est contrôlé par plusieurs couches d’authentification requise, qui sont toutes gérées par une politique d’entreprise stricte. 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édez aux clusters ROSA via la console Web ou les outils d’interface de ligne de commande (CLI). L’authentification nécessite une authentification multi-facteurs (MFA) avec des exigences standard de l’industrie pour la complexité des mots de passe et les verrouillages de compte. Le SRES doit s’authentifier en tant qu’individu 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).
Les SRES accèdent à des clusters privés à l’aide d’une connexion HTTP cryptée. Les connexions ne sont autorisées qu’à partir d’un réseau Red Hat sécurisé à l’aide d’une liste d’autorisations IP ou d’un lien fournisseur de cloud privé.
Figure 2.1. Accès SRE aux clusters ROSA
2.10.2.1. Contrôles d’accès privilégiés dans ROSA
La SRE adhère au principe du moindre privilège lors de l’accès aux composants ROSA et AWS. Il existe quatre catégories de base d’accès SRE manuels:
- Accès administrateur SRE via le portail 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. L’accès est limité à 2 heures, est entièrement audité et nécessite l’approbation de la direction.
- Accès AWS ou élévation, qui est une élévation manuelle pour l’accès à la console AWS ou 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 rouge) | Accès administrateur SRE typique (Red Hat SSO) | Élévation de OpenShift | Accès ou élévation des fournisseurs de cloud |
|---|---|---|---|---|
| Gestionnaire de cluster OpenShift | DE R/W | Aucun accès | Aucun accès | Aucun accès |
| Console 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.10.2.2. Accès SRE aux comptes AWS
Le personnel de Red Hat n’a pas accès aux comptes AWS dans le cadre de la routine Red Hat OpenShift Service sur les opérations AWS. À des fins de dépannage d’urgence, les SRE disposent de procédures bien définies et vérifiables pour accéder aux comptes d’infrastructure cloud.
Dans le flux de backplan isolé, les SRE demandent l’accès au rôle de support d’un client. Cette demande est juste à temps (JIT) traitée par l’API de backplane qui met à jour dynamiquement les autorisations du rôle de l’organisation vers un compte du personnel SRE spécifique. Le compte de ce SRE bénéficie d’un accès à l’environnement spécifique du client Red Hat. L’accès SRE à l’environnement d’un client Red Hat est un accès temporaire et de courte durée qui n’est établi qu’au moment de la demande d’accès.
L’accès au jeton STS est bloqué par l’audit et traçable pour les utilisateurs individuels. Les clusters STS et non STS utilisent le service AWS STS pour l’accès SRE. Le contrôle d’accès utilise le flux de backplan unifié lorsque la stratégie ManagedOpenShift-Technical-Support-Role a la stratégie ManagedOpenShift-Support-Access, et ce rôle est utilisé pour l’administration. Le contrôle d’accès utilise le flux de backplan isolé lorsque la stratégie ManagedOpenShift-Support-Role est jointe à la stratégie ManagedOpenShift-Technical-<org_id>. Consultez l’article de KCS Mise à jour des politiques de confiance pour les clusters ROSA pour plus d’informations.
2.10.2.3. La vue SRE STS des comptes AWS
Lorsque les SRE sont sur un VPN via une authentification à deux facteurs, ils et Red Hat Support peuvent assumer le rôle ManagedOpenShift-Support-Support dans votre compte AWS. Le ManagedOpenShift-Support-Role dispose de toutes les autorisations nécessaires aux SRE pour résoudre et gérer directement les ressources AWS. En supposant le rôle ManagedOpenShift-Support-Role, les SRE utilisent un AWS Security Token Service (STS) pour générer une URL unique et expirant le temps vers l’interface Web AWS du client pour leur compte. Le SRES peut ensuite effectuer plusieurs actions de dépannage, qui comprennent:
- Affichage des journaux CloudTrail
- Arrêt d’une instance EC2 défectueuse
L’ensemble des activités effectuées par les SRE arrivent des adresses IP Red Hat et sont connectés à CloudTrail pour vous permettre d’auditer et de passer en revue toutes les activités. Ce rôle n’est utilisé que dans les cas où l’accès aux services AWS est nécessaire pour vous aider. La majorité des autorisations sont en lecture seule. Cependant, quelques autorisations sélectionnées ont plus d’accès, y compris la possibilité de redémarrer une instance ou de faire tourner une nouvelle instance. L’accès SRE est limité aux autorisations de stratégie attachées à ManagedOpenShift-Support-Role.
Consultez la liste complète des autorisations, voir sts_support_permission_policy.json dans le guide de l’utilisateur des ressources A propos de l’IAM.
2.10.2.4. Accès SRE via le service de point de terminaison PrivateLink VPC
Le service PrivateLink VPC endpoint est créé dans le cadre de la création de cluster ROSA.
Lorsque vous disposez d’un cluster ROSA PrivateLink, son serveur API Kubernetes est exposé à l’aide d’un équilibreur de charge auquel on ne peut accéder qu’à partir du VPC par défaut. L’ingénierie de fiabilité du site Red Hat (SRE) peut se connecter à cet équilibreur de charge via un service de point d’extrémité VPC qui dispose d’un point de terminaison VPC associé dans un compte AWS appartenant à Red Hat. Ce service de point de terminaison contient le nom du cluster, qui est également dans l’ARN.
Dans l’onglet Autoriser les principaux, un compte AWS appartenant à Red Hat est listé. Cet utilisateur spécifique s’assure que d’autres entités ne peuvent pas créer de connexions VPC Endpoint au serveur API Kubernetes du cluster PrivateLink.
Lorsque les Red Hat SRE accèdent à l’API, ce plan de gestion de flotte peut se connecter à l’API interne via le service de point de terminaison VPC.
2.10.3. Accès au support Red Hat
Les membres de l’équipe de Red Hat Customer Experience and Engagement (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 AWS* |
|---|---|---|---|---|
| Fonctionnement normal de OpenShift SRE [1] | Lire: Tout Écrire: Très limité | Lire: Tout Écrire: Aucun | Lire: Aucun Écrire: Aucun | Lire: Aucun Écrire: Aucun |
| Accès amélioré à OpenShift SRE [2] (Gated by Approved Access) | Lire: Tout Ecrire: Tous | Lire: Tout Ecrire: Tous | Lire: Tout Ecrire: Tous | Lire: Tout Ecrire: Tous |
| CEE | Lire: Tout Écrire: Aucun | Lire: Tout Écrire: Aucun | Lire: Aucun Écrire: Aucun | Lire: Aucun Écrire: Aucun |
| Administrateur client | Lire: Aucun Écrire: Aucun | Lire: Aucun Écrire: Aucun | Lire: Tout Ecrire: Tous | Lire: Tout Ecrire: Tous |
| Client utilisateur | Lire: Aucun Écrire: Aucun | Lire: Aucun Écrire: Aucun | Lire: Limitée [3] Ecrire: Limited [3] | Lire: Aucun Écrire: Aucun |
| Les autres | Lire: Aucun Écrire: Aucun | Lire: Aucun Écrire: Aucun | Lire: Aucun Écrire: Aucun | Lire: Aucun Écrire: Aucun |
- 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.
- L’accès élevé donne à SRE les niveaux d’accès d’un rôle d’administration de cluster et est fermé par l’Accès Approuvé. En savoir plus, voir « Rôles de clusters par défaut » et « Accès approuvé ».
- Limité à ce qui est accordé par RBAC par l’administrateur client et les espaces de noms créés par l’utilisateur.
2.10.4. 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. En savoir plus sur l’accès et l’authentification des clients, consultez la section « Comprendre l’authentification » de la documentation.
2.10.5. 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, le SRE effectue un examen périodique de l’accès, y compris la signature de la gestion des listes d’utilisateurs autorisés.
Le tableau 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.
| A) Ressources | Les responsabilités en matière de service | Les responsabilités du client |
|---|---|---|
| L’exploitation forestière | Chapeau rouge
|
|
| La mise en réseau des applications | Chapeau rouge
|
|
| La mise en réseau de clusters | Chapeau rouge
|
|
| Gestion des réseaux virtuels | Chapeau rouge
|
|
| Gestion du stockage virtuel | Chapeau rouge
|
|
| Gestion de calcul virtuel | Chapeau rouge
|
|
| Logiciel AWS (services AWS publics) | AWS Calcul : Fournir le service Amazon EC2, utilisé pour l’avion de contrôle ROSA, l’infrastructure et les nœuds de travail. Le stockage : Fournir Amazon EBS, utilisé pour permettre à ROSA de fournir un stockage de nœud local et un stockage en volume persistant pour le cluster. Stockage: Fournissez Amazon S3, utilisé pour le registre d’images intégré du service. Le réseau : Fournir AWS Identity and Access Management (IAM), utilisé par les clients pour contrôler l’accès aux ressources ROSA fonctionnant sur les comptes clients. |
|
| Hardware et infrastructure globale AWS | AWS
|
|
2.10.6. Comment les comptes de services assument les rôles AWS IAM dans les projets appartenant à SRE
Lorsque vous installez un service Red Hat OpenShift sur le cluster AWS 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 au service Red Hat OpenShift sur AWS cluster Operators 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.2. 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, Red Hat OpenShift Service sur AWS 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 Red Hat OpenShift Service sur AWS avec des clusters STS, 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.
'%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}