Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.
# Sécurité dans ROSA
La sécurité du cloud AWS est la priorité absolue. En tant que AWS client, vous bénéficiez d'un centre de données et d'une architecture réseau conçus pour répondre aux exigences des entreprises les plus sensibles en matière de sécurité.
La sécurité est une responsabilité partagée entre vous AWS et vous. Le [modèle de responsabilité partagée](https://aws.amazon.com/compliance/shared-responsibility-model/) décrit ceci en tant que sécurité du cloud et sécurité dans le cloud :
+ **Sécurité du cloud** : AWS est chargée de protéger l'infrastructure qui exécute les AWS services dans le AWS Cloud. AWS vous fournit également des services que vous pouvez utiliser en toute sécurité. Des auditeurs tiers testent et vérifient régulièrement l’efficacité de notre sécurité dans le cadre des [programmes de conformitéAWS](https://aws.amazon.com/compliance/programs/). Pour en savoir plus sur les programmes de conformité qui s'appliquent à ROSA, consultez [Services AWS la section Portée par programme de conformité](https://aws.amazon.com/compliance/services-in-scope/).
+ **Sécurité dans le cloud** — Votre responsabilité est déterminée par Service AWS ce que vous utilisez. Vous êtes également responsable d’autres facteurs, y compris de la sensibilité de vos données, des exigences de votre entreprise, ainsi que de la législation et de la réglementation applicables.
Cette documentation vous aide à comprendre comment appliquer le modèle de responsabilité partagée lors de son utilisation ROSA. Il vous explique comment procéder à la configuration ROSA pour atteindre vos objectifs de sécurité et de conformité. Vous apprenez également à utiliser d'autres outils Services AWS qui vous aident à surveiller et à sécuriser vos ROSA ressources.
**Topics**
+ [Protection des données](data-protection.md)
+ [Gestion des identités et des accès](security-iam.md)
+ [Résilience](disaster-recovery-resiliency.md)
+ [Sécurité de l’infrastructure](infrastructure-security.md)
# Protection des données dans ROSA
La [Vue d'ensemble des responsabilités pour ROSA](rosa-responsibilities.md) documentation et le [modèle de responsabilitéAWS partagée](https://aws.amazon.com/compliance/shared-responsibility-model/) définissent la protection des données dans ROSA. AWS est chargé de protéger l'infrastructure mondiale qui gère tous les AWS Cloud. Red Hat est chargé de protéger l'infrastructure du cluster et la plate-forme de services sous-jacente. Le client est responsable du contrôle du contenu hébergé sur cette infrastructure. Ce contenu inclut la configuration de la sécurité et les tâches de gestion pour le Services AWS produit que vous utilisez. Pour plus d’informations sur la confidentialité des données, consultez [Questions fréquentes (FAQ) relatives à la confidentialité des données](https://aws.amazon.com/compliance/data-privacy-faq). Pour plus d'informations sur la protection des données en Europe, veuillez consulter le billet de blog [Modèle de responsabilité partagée AWS et RGPD](https://aws.amazon.com/blogs/security/the-aws-shared-responsibility-model-and-gdpr) sur la page *Blog Security AWS .*
À des fins de protection des données, nous vous recommandons de protéger les Compte AWS informations d'identification et de configurer les utilisateurs individuels avec Gestion des identités et des accès AWS (IAM). Ainsi, chaque utilisateur se voit attribuer uniquement les autorisations nécessaires pour exécuter ses tâches. Nous vous recommandons également de sécuriser vos données comme indiqué ci-dessous :
+ Utilisez l’authentification multifactorielle (MFA) avec chaque compte.
+ SSL/TLS À utiliser pour communiquer avec AWS les ressources. Nous exigeons TLS 1.2 et recommandons TLS 1.3.
+ Configurez l'API et la journalisation de l'activité des utilisateurs avec AWS CloudTrail.
+ Utilisez des solutions de AWS chiffrement, ainsi que tous les contrôles de sécurité par défaut qu'ils contiennent Services AWS.
+ Utilisez des services de sécurité gérés avancés tels que Amazon Macie, qui aident à découvrir et à sécuriser les données sensibles stockées dans Amazon S3.
+ Si vous avez besoin de modules cryptographiques validés par la norme FIPS 140-2 pour accéder AWS via une interface de ligne de commande ou une API, utilisez un point de terminaison FIPS. Pour plus d’informations sur les points de terminaison FIPS (Federal Information Processing Standard) disponibles, consultez [Federal Information Processing Standard (FIPS) 140-2](https://aws.amazon.com/compliance/fips/) (Normes de traitement de l’information fédérale).
Nous vous recommandons vivement de ne jamais placer d'informations identifiables sensibles, telles que les numéros de compte de vos clients, dans des champs de formulaire comme **Name (Nom)**. Cela inclut lorsque vous travaillez avec ROSA ou d'autres Services AWS utilisateurs de la console, de l'API ou AWS SDKs. AWS CLI Toutes les données que vous entrez ROSA ou d'autres services peuvent être récupérées pour être incluses dans les journaux de diagnostic. Lorsque vous fournissez une URL à un serveur externe, n'incluez pas les informations d'identification non chiffrées dans l'URL pour valider votre demande adressée au serveur.
**Topics**
+ [Chiffrement des données](data-protection-encryption.md)
# Protection des données à l’aide du chiffrement
La protection des données fait référence à la protection des données en transit (lors de leur trajet aller-retour ROSA) et au repos (lorsqu'elles sont stockées sur des disques dans AWS des centres de données).
Red Hat OpenShift Service on AWS fournit un accès sécurisé aux volumes de stockage Amazon Elastic Block Store (Amazon EBS) attachés aux Amazon EC2 instances pour le plan de ROSA contrôle, l'infrastructure et les nœuds de travail, ainsi qu'aux volumes persistants Kubernetes pour le stockage persistant. ROSA chiffre les données en volume au repos et en transit, et utilise AWS Key Management Service (AWS KMS) pour protéger vos données chiffrées. Le service utilise Amazon S3 le stockage du registre des images de conteneurs, qui est chiffré au repos par défaut.
**Important**
Parce que ROSA c'est un service géré, AWS et Red Hat gère l'infrastructure qui l' ROSA utilise. Les clients ne doivent pas essayer d'arrêter manuellement les Amazon EC2 instances ROSA utilisées depuis la AWS console ou la CLI. Cette action peut entraîner une perte de données client.
## Chiffrement des données pour les Amazon EBS volumes de stockage sauvegardés
Red Hat OpenShift Service on AWS utilise le framework de volumes persistants (PV) Kubernetes pour permettre aux administrateurs de clusters de fournir un stockage persistant à un cluster. Les volumes persistants, ainsi que le plan de contrôle, l'infrastructure et les nœuds de travail, sont soutenus par Amazon Elastic Block Store (Amazon EBS) des volumes de stockage attachés aux Amazon EC2 instances.
Pour les volumes ROSA persistants et les nœuds soutenus par Amazon EBS, les opérations de chiffrement sont effectuées sur les serveurs hébergeant les instances EC2, garantissant ainsi la sécurité des données au repos et des données en transit entre une instance et son stockage attaché. Pour plus d'informations, consultez la section sur le [Amazon EBS chiffrement](https://docs.aws.amazon.com/ebs/latest/userguide/ebs-encryption.html) dans le *guide de Amazon EC2 l'utilisateur*.
### Chiffrement des données pour le pilote Amazon EBS CSI et le pilote Amazon EFS CSI
ROSA par défaut, le pilote Amazon EBS CSI est utilisé pour Amazon EBS provisionner le stockage. Le pilote Amazon EBS CSI et l'opérateur de pilote Amazon EBS CSI sont installés sur le cluster par défaut dans l'`openshift-cluster-csi-drivers`espace de noms. Le pilote et l'opérateur Amazon EBS CSI vous permettent de provisionner dynamiquement des volumes persistants et de créer des instantanés de volumes.
ROSA est également capable de provisionner des volumes persistants à l'aide du pilote Amazon EFS CSI et de l'opérateur de pilote Amazon EFS CSI. Le Amazon EFS pilote et l'opérateur vous permettent également de partager les données du système de fichiers entre des pods ou avec d'autres applications au sein ou en dehors de Kubernetes.
Les données de volume sont sécurisées en transit pour le pilote Amazon EBS CSI et le pilote Amazon EFS CSI. Pour plus d'informations, consultez la section [Utilisation de l'interface de stockage de conteneurs (CSI)](https://access.redhat.com/documentation/en-us/red_hat_openshift_service_on_aws/4/html/storage/using-container-storage-interface-csi) dans la documentation Red Hat.
**Important**
Lors du provisionnement dynamique de volumes ROSA persistants à l'aide du pilote Amazon EFS CSI, tenez Amazon EFS compte de l'ID utilisateur, de l'ID de groupe (GID) et IDs du groupe secondaire du point d'accès lors de l'évaluation des autorisations du système de fichiers. Amazon EFS remplace l'utilisateur et le groupe IDs sur les fichiers par l'utilisateur et le groupe IDs sur le point d'accès et ignore le client NFS. IDs Par conséquent, ignore Amazon EFS silencieusement les paramètres`fsGroup`. ROSA n'est pas en mesure GIDs de remplacer les fichiers en utilisant`fsGroup`. Tout pod pouvant accéder à un point d' Amazon EFS accès monté peut accéder à n'importe quel fichier du volume. Pour plus d'informations, consultez la section [Utilisation des points Amazon EFS d'accès](https://docs.aws.amazon.com/efs/latest/ug/efs-access-points.html) dans le *guide de Amazon EFS l'utilisateur*.
### cryptage etcd
ROSA offre la possibilité d'activer le chiffrement des valeurs `etcd` clés dans le `etcd` volume lors de la création du cluster, en ajoutant une couche de chiffrement supplémentaire. Une fois `etcd` le chiffrement effectué, vous devrez supporter une surcharge de performance d'environ 20 %. Nous vous recommandons d'activer `etcd` le chiffrement uniquement si vous en avez spécifiquement besoin pour votre cas d'utilisation. Pour plus d'informations, consultez la section [chiffrement etcd](https://access.redhat.com/documentation/en-us/red_hat_openshift_service_on_aws/4/html/introduction_to_rosa/policies-and-service-definition#rosa-sdpolicy-etcd-encryption_rosa-service-definition) dans la définition du ROSA service.
### Gestion des clés
ROSA permet KMS keys de gérer en toute sécurité le plan de contrôle, l'infrastructure et les volumes de données des employés, ainsi que les volumes persistants pour les applications des clients. Lors de la création du cluster, vous avez le choix d'utiliser la clé AWS gérée par défaut KMS key fournie par Amazon EBS ou de spécifier votre propre clé gérée par le client. Pour de plus amples informations, veuillez consulter [Chiffrement des données grâce à KMS](data-protection-key-management.md).
## Chiffrement des données pour le registre d'images intégré
ROSA fournit un registre d'images de conteneur intégré pour stocker, récupérer et partager des images de conteneurs via le stockage par Amazon S3 bucket. Le registre est configuré et géré par l'opérateur de registre OpenShift d'images. Il fournit une out-of-the-box solution permettant aux utilisateurs de gérer les images qui exécutent leurs charges de travail et s'exécute au-dessus de l'infrastructure de cluster existante. Pour plus d'informations, consultez la section [Registre](https://docs.redhat.com/en/documentation/red_hat_openshift_service_on_aws/4/html/registry/index) dans la documentation Red Hat.
ROSA propose des registres d'images publics et privés. Pour les applications d'entreprise, nous vous recommandons d'utiliser un registre privé afin de protéger vos images contre toute utilisation par des utilisateurs non autorisés. Pour protéger les données de votre registre au repos, ROSA utilise le chiffrement côté serveur par défaut avec des clés Amazon S3 gérées (SSE-S3). Cela ne nécessite aucune action de votre part et est proposé sans frais supplémentaires. *Pour plus d'informations, consultez [la section Protection des données à l'aide du chiffrement côté serveur avec des clés de chiffrement Amazon S3 gérées (SSE-S3)](https://docs.aws.amazon.com/AmazonS3/latest/userguide/UsingServerSideEncryption.html) dans le guide de l'utilisateur. Amazon S3 *
ROSA utilise le protocole TLS (Transport Layer Security) pour sécuriser les données en transit vers et depuis le registre d'images. Pour plus d'informations, consultez la section [Registre](https://docs.redhat.com/en/documentation/red_hat_openshift_service_on_aws/4/html/registry/index) dans la documentation Red Hat.
## Confidentialité du trafic inter-réseau
Red Hat OpenShift Service on AWS utilise Amazon Virtual Private Cloud (Amazon VPC) pour créer des limites entre les ressources de votre ROSA cluster et contrôler le trafic entre celles-ci, votre réseau local et Internet. Pour plus d'informations sur Amazon VPC la sécurité, consultez la section [Confidentialité du trafic interréseau Amazon VPC dans](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_Security.html) le *Guide de l' Amazon VPC utilisateur*.
Dans le VPC, vous pouvez configurer vos ROSA clusters pour utiliser un serveur proxy HTTP ou HTTPS afin de refuser l'accès direct à Internet. Si vous êtes administrateur de cluster, vous pouvez également définir des politiques réseau au niveau du pod qui limitent le trafic interréseau aux pods de votre ROSA cluster. Pour de plus amples informations, veuillez consulter [Sécurité de l'infrastructure dans ROSA](infrastructure-security.md).
# Chiffrement des données grâce à KMS
ROSA utilise AWS KMS pour gérer en toute sécurité les clés des données cryptées. Les volumes du plan de contrôle, de l'infrastructure et des nœuds de travail sont chiffrés par défaut à l'aide du AWS système géré KMS key fourni par Amazon EBS. Cela KMS key porte le pseudonyme`aws/ebs`. Les volumes persistants qui utilisent la classe de stockage gp3 par défaut sont également chiffrés par défaut à l'aide de cette KMS key classe.
Les ROSA clusters nouvellement créés sont configurés pour utiliser la classe de stockage gp3 par défaut pour chiffrer les volumes persistants. Les volumes persistants créés à l'aide d'une autre classe de stockage ne sont chiffrés que si la classe de stockage est configurée pour être chiffrée. Pour plus d'informations sur les classes ROSA de stockage prédéfinies, consultez [la section Configuration du stockage persistant](https://access.redhat.com/documentation/en-us/red_hat_openshift_service_on_aws/4/html/storage/configuring-persistent-storage#persistent-storage-aws) dans la documentation Red Hat.
Lors de la création du cluster, vous pouvez choisir de chiffrer les volumes persistants de votre cluster à l'aide de la clé Amazon EBS fournie par défaut ou de spécifier votre propre système symétrique géré par le client. KMS key Pour plus d'informations sur la création de clés, consultez la section [Création de clés KMS de chiffrement symétriques](https://docs.aws.amazon.com/kms/latest/developerguide/create-keys.html#create-symmetric-cmk) dans le *manuel du AWS KMS développeur*.
Vous pouvez également chiffrer des volumes persistants pour des conteneurs individuels au sein d'un cluster en définissant un KMS key. Cela est utile lorsque vous disposez de directives de conformité et de sécurité explicites lors du déploiement vers AWS. Pour plus d'informations, consultez la section [Chiffrer les volumes persistants de conteneurs AWS avec un KMS key](https://access.redhat.com/documentation/en-us/red_hat_openshift_service_on_aws/4/html/storage/configuring-persistent-storage#aws-container-persistent-volumes-encrypt_persistent-storage-aws) dans la documentation Red Hat.
Les points suivants doivent être pris en compte lors du chiffrement de volumes persistants à l'aide des vôtres KMS keys :
+ Lorsque vous utilisez le chiffrement KMS avec le vôtre KMS key, la clé doit se trouver au même Région AWS endroit que votre cluster.
+ Il y a un coût associé à la création et à l'utilisation des vôtres KMS keys. Pour en savoir plus, consultez [Pricing AWS Key Management Service](https://aws.amazon.com/kms/pricing/) (Tarification).
# Gestion des identités et des accès pour ROSA
Gestion des identités et des accès AWS (IAM) est un outil Service AWS qui permet à un administrateur de contrôler en toute sécurité l'accès aux AWS ressources. IAM les administrateurs contrôlent qui peut être *authentifié* (connecté) et *autorisé (autorisé*) à utiliser les ROSA ressources. IAM est un Service AWS outil que vous pouvez utiliser sans frais supplémentaires.
**Topics**
+ [Public ciblé](#security-iam-audience)
+ [Authentification par des identités](#security-iam-authentication)
+ [Gestion de l’accès à l’aide de politiques](#security-iam-access-manage)
+ [ROSA exemples de politiques basées sur l'identité](security-iam-id-based-policy-examples.md)
+ [AWS politiques gérées pour ROSA](security-iam-awsmanpol.md)
+ [Résolution des problèmes ROSA d'identité et d'accès](security-iam-troubleshoot.md)
## Public ciblé
La façon dont vous utilisez Gestion des identités et des accès AWS (IAM) varie en fonction du travail que vous effectuez ROSA.
**Utilisateur du service** : si vous utilisez le ROSA service pour effectuer votre travail, votre administrateur vous fournit les informations d'identification et les autorisations dont vous avez besoin. Au fur et à mesure que vous utilisez de nouvelles ROSA fonctionnalités pour effectuer votre travail, vous aurez peut-être besoin d'autorisations supplémentaires. Si vous comprenez bien la gestion des accès, vous saurez demander les autorisations appropriées à votre administrateur. Si vous ne pouvez pas accéder à une fonctionnalité dans ROSA, consultez[Résolution des problèmes ROSA d'identité et d'accès](security-iam-troubleshoot.md).
**Administrateur du service** - Si vous êtes responsable des ROSA ressources de votre entreprise, vous avez probablement un accès complet à ROSA. C'est à vous de déterminer les ROSA fonctionnalités et les ressources auxquelles les utilisateurs de votre service doivent accéder. Vous devez ensuite envoyer des demandes à votre IAM administrateur pour modifier les autorisations des utilisateurs de votre service. Consultez les informations de cette page pour comprendre les concepts de base de IAM.
** IAM administrateur** - Si vous êtes IAM administrateur, vous souhaiterez peut-être en savoir plus sur les politiques utilisées pour gérer l'accès à ROSA. Pour consulter des exemples de politiques ROSA basées sur l'identité que vous pouvez utiliser dans IAM, consultez. [ROSA exemples de politiques basées sur l'identité](security-iam-id-based-policy-examples.md)
## Authentification par des identités
L'authentification est la façon dont vous vous connectez à AWS l'aide de vos informations d'identification. Vous devez être *authentifié* (connecté à AWS) en tant qu'utilisateur Compte AWS root Utilisateur IAM, ou en assumant un IAM rôle.
Vous pouvez vous connecter en AWS tant qu'identité fédérée en utilisant les informations d'identification fournies par le biais d'une source d'identité. AWS IAM Identity Center (IAM Identity Center) les utilisateurs, l'authentification unique de votre entreprise et vos informations d'identification Google ou Facebook sont des exemples d'identités fédérées. Lorsque vous vous connectez en tant qu'identité fédérée, votre administrateur a préalablement configuré la fédération d'identité à l'aide de IAM rôles. Lorsque vous accédez à AWS l'aide de la fédération, vous assumez indirectement un rôle.
Selon le type d'utilisateur que vous êtes, vous pouvez vous connecter au portail AWS Management Console ou au portail AWS d'accès. Pour plus d'informations sur la connexion à AWS, consultez [Comment vous connecter à votre Compte AWS compte dans](https://docs.aws.amazon.com/signin/latest/userguide/how-to-sign-in.html) le *guide de l'utilisateur de AWS connexion*.
Si vous y accédez AWS par programmation, AWS fournit un kit de développement logiciel (SDK) et une interface de ligne de commande (CLI) pour signer cryptographiquement vos demandes à l'aide de vos informations d'identification. Si vous n'utilisez pas d' AWS outils, vous devez signer vous-même les demandes. Pour plus d'informations sur l'utilisation de la méthode recommandée pour signer vous-même les demandes, consultez la section [Signature des demandes d' AWS API](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_aws-signing.html) dans le *guide de IAM l'utilisateur*.
Quelle que soit la méthode d’authentification que vous utilisez, vous devrez peut-être également fournir des informations de sécurité supplémentaires. Par exemple, il vous AWS recommande d'utiliser l'authentification multifactorielle (MFA) pour renforcer la sécurité de votre compte. *Pour en savoir plus, consultez les sections [Authentification multifactorielle](https://docs.aws.amazon.com/singlesignon/latest/userguide/enable-mfa.html) du Guide de l'*utilisateur d' AWS IAM Identity Center (successeur du Single Sign-On) et [Utilisation de l'authentification multifactorielle (MFA) dans AWS](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_mfa.html) le Guide* de l'utilisateur IAM. AWS *
### Compte AWS utilisateur root
Lorsque vous créez un Compte AWS, vous commencez par une identité de connexion unique qui donne un accès complet à toutes Services AWS les ressources du compte. Cette identité est appelée utilisateur Compte AWS root et est accessible en vous connectant avec l'adresse e-mail et le mot de passe que vous avez utilisés pour créer le compte. Il est vivement recommandé de ne pas utiliser l’utilisateur racine pour vos tâches quotidiennes. Protégez vos informations d’identification d’utilisateur racine et utilisez-les pour effectuer les tâches que seul l’utilisateur root peut effectuer. Pour obtenir la liste complète des tâches qui nécessitent que vous vous connectiez en tant qu'utilisateur root, consultez la section [Tâches nécessitant des informations d'identification utilisateur root](https://docs.aws.amazon.com/IAM/latest/UserGuide/root-user-tasks.html) dans le *guide de IAM l'utilisateur*.
### Identité fédérée
La meilleure pratique consiste à obliger les utilisateurs humains, y compris ceux qui ont besoin d'un accès administrateur, à utiliser la fédération avec un fournisseur d'identité pour accéder à l'aide Services AWS d'informations d'identification temporaires.
Une identité fédérée est un utilisateur de l'annuaire des utilisateurs de votre entreprise, d'un fournisseur d'identité Web AWS Directory Service, du répertoire Identity Center ou de tout utilisateur qui y accède à l'aide des informations d'identification fournies Services AWS par le biais d'une source d'identité. Lorsque des identités fédérées y accèdent Comptes AWS, elles assument des rôles, qui fournissent des informations d'identification temporaires.
Pour une gestion des accès centralisée, nous vous recommandons d’utiliser AWS IAM Identity Center. Vous pouvez créer des utilisateurs et des groupes dans IAM Identity Center, ou vous pouvez vous connecter et synchroniser avec un ensemble d'utilisateurs et de groupes dans votre propre source d'identité afin de les utiliser dans toutes vos applications Comptes AWS et applications. Pour plus d'informations sur IAM Identity Center, voir [Qu'est-ce qu'IAM Identity](https://docs.aws.amazon.com/singlesignon/latest/userguide/what-is.html) Center ? dans le guide de l'*utilisateur d' AWS IAM Identity Center (successeur du Single Sign-On)*. AWS
### Utilisateurs IAM et groupes
An *[Utilisateur IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_users.html)*est une identité au sein de vous Compte AWS qui possède des autorisations spécifiques pour une seule personne ou une seule application. Dans la mesure du possible, nous vous recommandons de vous fier à des informations d'identification temporaires plutôt que de créer des Utilisateurs IAM personnes possédant des informations d'identification à long terme, telles que des mots de passe et des clés d'accès. Toutefois, si vous avez des cas d'utilisation spécifiques qui nécessitent des informations d'identification à long terme Utilisateurs IAM, nous vous recommandons de faire pivoter les clés d'accès. Pour plus d’informations, consultez [Rotation régulière des clés d’accès pour les cas d’utilisation nécessitant des informations d’identification](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html#rotate-credentials) dans le *Guide de l’utilisateur IAM*.
Un [IAM groupe](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_groups.html) est une identité qui spécifie une collection de Utilisateurs IAM. Vous ne pouvez pas vous connecter en tant que groupe. Vous pouvez utiliser les groupes pour spécifier des autorisations pour plusieurs utilisateurs à la fois. Les groupes permettent de gérer plus facilement les autorisations pour de grands ensembles d’utilisateurs. Par exemple, vous pouvez nommer un groupe *IAMAdmins*et lui donner les autorisations nécessaires pour administrer IAM des ressources.
Les utilisateurs sont différents des rôles. Un utilisateur est associé de manière unique à une personne ou une application, alors qu’un rôle est conçu pour être endossé par tout utilisateur qui en a besoin. Les utilisateurs disposent d’informations d’identification permanentes, mais les rôles fournissent des informations d’identification temporaires. Pour en savoir plus, consultez la section [Quand créer un rôle Utilisateur IAM (au lieu d'un rôle)](https://docs.aws.amazon.com/IAM/latest/UserGuide/id.html#id_which-to-choose) dans le *guide de l'utilisateur IAM*.
### IAM rôles
Un *[IAM rôle](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html)* est une identité au sein de Compte AWS vous dotée d'autorisations spécifiques. Il est similaire à un Utilisateur IAM, mais n'est pas associé à une personne en particulier. Vous pouvez assumer temporairement un IAM rôle dans le en AWS Management Console [changeant de rôle](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_use_switch-role-console.html). Vous pouvez assumer un rôle en appelant une opération d' AWS API AWS CLI ou en utilisant une URL personnalisée. Pour plus d'informations sur les méthodes d'utilisation des rôles, consultez la section [Utilisation IAM des rôles](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_use.html) dans le *Guide de l'utilisateur IAM*.
IAM les rôles dotés d'informations d'identification temporaires sont utiles dans les situations suivantes :
+ **Accès utilisateur fédéré** : pour attribuer des autorisations à une identité fédérée, vous devez créer un rôle et définir des autorisations pour ce rôle. Quand une identité externe s’authentifie, l’identité est associée au rôle et reçoit les autorisations qui sont définies par celui-ci. Pour obtenir des informations sur les rôles pour la fédération, consultez [Création d’un rôle pour un fournisseur d’identité tiers (fédération)](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_create_for-idp.html) dans le *Guide de l’utilisateur IAM*. Si vous utilisez IAM Identity Center, vous configurez un jeu d’autorisations. IAM Identity Center met en corrélation le jeu d’autorisations avec un rôle dans IAM afin de contrôler à quoi vos identités peuvent accéder après leur authentification. Pour plus d'informations sur les ensembles d'autorisations, consultez la section [Ensembles d'autorisations](https://docs.aws.amazon.com/singlesignon/latest/userguide/permissionsetsconcept.html) du * AWS guide de l'utilisateur d'IAM Identity Center (successeur de AWS Single Sign-On)*.
+ ** Utilisateur IAM Autorisations temporaires** - Un Utilisateur IAM homme peut assumer un IAM rôle en assumant temporairement différentes autorisations pour une tâche spécifique.
+ **Accès entre comptes** : vous pouvez utiliser un IAM rôle pour autoriser une personne (un mandant fiable) d'un autre compte à accéder aux ressources de votre compte. Les rôles constituent le principal moyen d’accorder l’accès intercompte. Toutefois, dans certains Services AWS cas, vous pouvez associer une politique directement à une ressource (au lieu d'utiliser un rôle comme proxy). *Pour connaître la différence entre les rôles et les politiques basées sur les ressources pour l'accès entre comptes, consultez la section En [quoi les IAM rôles diffèrent des politiques basées sur les ressources](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies-cross-account-resource-access.html) dans le Guide de l'utilisateur IAM.*
+ **Accès multiservices** : certains Services AWS utilisent des fonctionnalités dans d'autres Services AWS. Par exemple, lorsque vous effectuez un appel dans un service, il est courant que ce service exécute des applications Amazon EC2 ou y stocke des objets Amazon S3. Un service peut le faire en utilisant les autorisations d’appel du principal, une fonction du service ou un rôle lié au service.
+ **Sessions d'accès** direct (FAS) - Lorsque vous utilisez un rôle Utilisateur IAM ou pour effectuer des actions AWS, vous êtes considéré comme un mandant. Lorsque vous utilisez certains services, vous pouvez effectuer une action qui initie une autre action dans un autre service. FAS utilise les autorisations du principal appelant et Service AWS, associées Service AWS à la demande, pour adresser des demandes aux services en aval. Les demandes FAS ne sont effectuées que lorsqu'un service reçoit une demande qui nécessite des interactions avec d'autres personnes Services AWS ou des ressources pour être traitée. Dans ce cas, vous devez disposer d’autorisations nécessaires pour effectuer les deux actions. Pour plus de détails sur une politique lors de la formulation de demandes FAS, consultez [Transfert des sessions d’accès](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_forward_access_sessions.html).
+ **Rôle de service** - Un rôle de service est un IAM rôle qu'un service assume pour effectuer des actions en votre nom. Un IAM administrateur peut créer, modifier et supprimer un rôle de service de l'intérieur IAM. Pour plus d’informations, consultez [Création d’un rôle pour la délégation d’autorisations à un Service AWS](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_create_for-service.html) dans le *Guide de l’utilisateur IAM*.
+ **Rôle lié à un service - Un rôle** lié à un service est un type de rôle de service lié à un. Service AWS Le service peut endosser le rôle afin d’effectuer une action en votre nom. Les rôles liés au service apparaissent dans votre IAM compte et appartiennent au service. Un IAM administrateur peut consulter, mais pas modifier les autorisations pour les rôles liés à un service.
+ **Applications exécutées sur Amazon EC2 ** : vous pouvez utiliser un IAM rôle pour gérer les informations d'identification temporaires pour les applications qui s'exécutent sur une Amazon EC2 instance et qui envoient AWS CLI des demandes AWS d'API. Cela est préférable au stockage des clés d'accès dans l' Amazon EC2 instance. Pour attribuer un AWS rôle à une Amazon EC2 instance et le rendre disponible pour toutes ses applications, vous devez créer un profil d'instance attaché à l'instance. Un profil d'instance contient le rôle et permet aux programmes exécutés sur l' Amazon EC2 instance d'obtenir des informations d'identification temporaires. Pour plus d'informations, consultez la section [Utilisation d'un IAM rôle pour accorder des autorisations aux applications exécutées sur des Amazon EC2 instances](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_use_switch-role-ec2.html) dans le *Guide de l'utilisateur IAM*.
Pour savoir s'il faut utiliser IAM des rôles ou des IAM utilisateurs, consultez la section [Quand créer un IAM rôle (au lieu d'un utilisateur)](https://docs.aws.amazon.com/IAM/latest/UserGuide/id.html#id_which-to-choose_role) dans le *guide de l'utilisateur IAM*.
## Gestion de l’accès à l’aide de politiques
Vous contrôlez l'accès en AWS créant des politiques et en les associant à AWS des identités ou à des ressources. Une politique est un objet AWS qui, lorsqu'il est associé à une identité ou à une ressource, définit leurs autorisations. AWS évalue ces politiques lorsqu'un principal (utilisateur, utilisateur root ou session de rôle) fait une demande. Les autorisations dans les politiques déterminent si la demande est autorisée ou refusée. La plupart des politiques sont stockées AWS sous forme de documents JSON. Pour plus d’informations sur la structure et le contenu des documents de politique JSON, consultez [Vue d’ensemble des politiques JSON](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies.html#access_policies-json) dans le *Guide de l’utilisateur IAM*.
Les administrateurs peuvent utiliser les politiques AWS JSON pour spécifier qui a accès à quoi. C’est-à-dire, quel **principal** peut effectuer **des actions** sur quelles **ressources** et dans quelles **conditions**.
Par défaut, les utilisateurs et les rôles ne disposent d’aucune autorisation. Pour autoriser les utilisateurs à effectuer des actions sur les ressources dont ils ont besoin, un IAM administrateur peut créer des IAM politiques. L'administrateur peut ensuite ajouter les IAM politiques aux rôles, et les utilisateurs peuvent assumer les rôles.
IAM les politiques définissent les autorisations pour une action, quelle que soit la méthode que vous utilisez pour effectuer l'opération. Par exemple, supposons que vous disposiez d’une politique qui autorise l’action `iam:GetRole`. Un utilisateur appliquant cette politique peut obtenir des informations sur le rôle à partir de AWS Management Console AWS CLI, de ou de l' AWS API.
### Politiques basées sur l’identité
Les politiques basées sur l'identité sont des documents de politique d'autorisation JSON que vous pouvez associer à une identité, telle qu'un Utilisateur IAM rôle ou un groupe. Ces politiques contrôlent quel type d’actions des utilisateurs et des rôles peuvent exécuter, sur quelles ressources et dans quelles conditions. Pour savoir comment créer une politique basée sur l'identité, consultez la section [Création de IAM politiques](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_create.html) dans le guide de l'utilisateur *IAM*.
Les politiques basées sur l’identité peuvent être classées comme des *politiques en ligne* ou des *politiques gérées*. Les politiques en ligne sont intégrées directement à un utilisateur, groupe ou rôle. Les politiques gérées sont des politiques autonomes que vous pouvez associer à plusieurs utilisateurs, groupes et rôles au sein de votre Compte AWS. Les politiques gérées incluent les politiques AWS gérées et les politiques gérées par le client. Pour découvrir comment choisir entre une politique gérée et une politique en ligne, consultez [Choix entre les politiques gérées et les politiques en ligne](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_managed-vs-inline.html#choosing-managed-or-inline) dans le *Guide de l’utilisateur IAM*.
### Politiques basées sur les ressources
Les politiques basées sur les ressources sont des documents de politique JSON que vous attachez à une ressource. Des politiques basées sur les ressources sont, par exemple, les IAM *politiques de confiance de rôle* et des Amazon S3 *politiques de compartiment Amazon S3*. Dans les services qui sont compatibles avec les politiques basées sur les ressources, les administrateurs de service peuvent les utiliser pour contrôler l’accès à une ressource spécifique. Pour la ressource dans laquelle se trouve la politique, cette dernière définit quel type d’actions un principal spécifié peut effectuer sur cette ressource et dans quelles conditions. Vous devez [spécifier un principal](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_principal.html) dans une politique basée sur les ressources. Les principaux peuvent inclure des comptes, des utilisateurs, des rôles, des utilisateurs fédérés ou. Services AWS
Les politiques basées sur les ressources sont des politiques en ligne situées dans ce service. Vous ne pouvez pas utiliser de politiques AWS gérées depuis une IAM stratégie basée sur les ressources.
### Listes de contrôle d'accès (ACLs)
Les listes de contrôle d'accès (ACLs) contrôlent les principaux (membres du compte, utilisateurs ou rôles) autorisés à accéder à une ressource. ACLs sont similaires aux politiques basées sur les ressources, bien qu'elles n'utilisent pas le format de document de politique JSON.
Amazon S3 AWS WAF, et Amazon VPC sont des exemples de services qui soutiennent ACLs. Pour en savoir plus ACLs, consultez la [présentation de la liste de contrôle d'accès (ACL)](https://docs.aws.amazon.com/AmazonS3/latest/userguide/acl-overview.html) dans le *guide de l'utilisateur d'Amazon Simple Storage Service*.
### Autres types de politique
AWS prend en charge d'autres types de politiques moins courants. Ces types de politiques peuvent définir le nombre maximum d’autorisations qui vous sont accordées par des types de politiques plus courants.
+ **Limites** d'autorisations - Une limite d'autorisations est une fonctionnalité avancée dans laquelle vous définissez le maximum d'autorisations qu'une politique basée sur l'identité peut accorder à une IAM entité (Utilisateur IAM ou à un rôle). Vous pouvez définir une limite d’autorisations pour une entité. Les autorisations obtenues représentent la combinaison des politiques basées sur l’identité de l’entité et de ses limites d’autorisations. Les politiques basées sur les ressources qui spécifient l’utilisateur ou le rôle dans le champ `Principal` ne sont pas limitées par les limites d’autorisations. Un refus explicite dans l’une de ces politiques annule l’autorisation. Pour plus d'informations sur les limites d'autorisations, consultez la section Limites d'[autorisations pour les IAM entités](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_boundaries.html) dans le *guide de l'utilisateur IAM*.
+ **Politiques de contrôle des services (SCPs)** : SCPs sont des politiques JSON qui spécifient les autorisations maximales pour une organisation ou une unité organisationnelle (UO) dans AWS Organizations. AWS Organizations est un service permettant de regrouper et de gérer de manière centralisée Comptes AWS les multiples propriétés de votre entreprise. Si vous activez toutes les fonctionnalités d'une organisation, vous pouvez appliquer des politiques de contrôle des services (SCPs) à l'un ou à l'ensemble de vos comptes. Le SCP limite les autorisations pour les entités des comptes membres, y compris pour chaque utilisateur Compte AWS root. Pour plus d'informations sur les Organizations SCPs, voir [Politiques de contrôle des services (SCPs)](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps.html) dans le *Guide de AWS Organizations l'utilisateur*.
+ **Stratégies de session** - Les stratégies de session sont des stratégies avancées que vous transmettez en tant que paramètre lorsque vous créez par programmation une session temporaire pour un rôle ou un utilisateur fédéré. Les autorisations de la session obtenue sont une combinaison des politiques basées sur l’identité de l’utilisateur ou du rôle et des politiques de session. Les autorisations peuvent également provenir d’une politique basée sur les ressources. Un refus explicite dans l’une de ces politiques annule l’autorisation. Pour plus d’informations, consultez [Politiques de session](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies.html#policies_session) dans le *Guide de l’utilisateur IAM*.
### Plusieurs types de politique
Lorsque plusieurs types de politiques s’appliquent à la requête, les autorisations en résultant sont plus compliquées à comprendre. Pour savoir comment AWS déterminer s'il faut autoriser une demande lorsque plusieurs types de politiques sont impliqués, consultez la section [Logique d'évaluation des politiques](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_evaluation-logic.html) dans le *guide de l'utilisateur IAM*.
# ROSA exemples de politiques basées sur l'identité
Par défaut, Utilisateurs IAM les rôles ne sont pas autorisés à créer ou à modifier AWS des ressources. Ils ne peuvent pas non plus effectuer de tâches à l'aide de l' AWS API AWS Management Console AWS CLI, ou. Un IAM administrateur doit créer des IAM politiques qui accordent aux utilisateurs et aux rôles l'autorisation d'effectuer des opérations d'API spécifiques sur les ressources spécifiques dont ils ont besoin. L'administrateur doit ensuite associer ces politiques au Utilisateurs IAM ou aux groupes qui nécessitent ces autorisations.
Pour savoir comment créer une politique IAM basée sur l'identité à l'aide de ces exemples de documents de stratégie JSON, consultez la section [Création de politiques dans l'onglet JSON du](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_create.html#access_policies_create-json-editor) guide de l'utilisateur *IAM*.
## Utilisation de la ROSA console
Pour s'abonner ROSA depuis la console, votre principal IAM doit disposer des AWS Marketplace autorisations requises. Les autorisations permettent au principal de s'abonner et de se désabonner de la liste des ROSA produits AWS Marketplace et de consulter AWS Marketplace les abonnements. Pour ajouter les autorisations requises, accédez à la [ROSA console](https://console.aws.amazon.com/rosa) et attachez la politique AWS gérée `ROSAManageSubscription` à votre principal IAM. Pour plus d’informations sur `ROSAManageSubscription`, consultez [AWS politique gérée : ROSAManage Abonnement](security-iam-awsmanpol.md#security-iam-awsmanpol-rosamanagesubscription).
## Autoriser ROSA with HCP à gérer les ressources AWS
ROSA avec plans de contrôle hébergés (HCP) utilise des politiques AWS gérées avec des autorisations requises pour le fonctionnement et le support du service. Vous utilisez la ROSA CLI ou IAM la console pour associer ces politiques aux rôles de service de votre Compte AWS.
Pour de plus amples informations, veuillez consulter [AWS politiques gérées pour ROSA](security-iam-awsmanpol.md).
## Autoriser ROSA Classic à gérer les ressources AWS
ROSA classic utilise des politiques IAM gérées par le client avec des autorisations prédéfinies par le service. Vous utilisez la ROSA CLI pour créer ces politiques et les associer à des rôles de service dans votre Compte AWS. ROSA exige que ces politiques soient configurées comme définies par le service afin de garantir un fonctionnement et un support de service continus.
**Note**
Vous ne devez pas modifier les politiques classiques de ROSA sans consulter au préalable Red Hat. Cela pourrait annuler le contrat de niveau de service de 99,95 % de disponibilité du cluster conclu par Red Hat. ROSA avec plans de contrôle hébergés utilise des politiques AWS gérées avec un ensemble d'autorisations plus limité. Pour de plus amples informations, veuillez consulter [AWS politiques gérées pour ROSA](security-iam-awsmanpol.md).
Il existe deux types de politiques gérées par le client pour ROSA : les politiques de compte et les politiques d'opérateur. Les politiques de compte sont associées aux IAM rôles que le service utilise pour établir une relation de confiance avec Red Hat en matière de support technique (SRE), de création de clusters et de fonctionnalités de calcul. Les politiques d'opérateur sont associées aux IAM rôles que OpenShift les opérateurs utilisent pour les opérations de cluster liées à l'entrée, au stockage, au registre d'images et à la gestion des nœuds. Les politiques de compte sont créées une fois par cluster Compte AWS, tandis que les politiques d'opérateur sont créées une fois par cluster.
Pour plus d’informations, consultez [Politiques relatives aux comptes ROSA Classic](security-iam-rosa-classic-account-policies.md) et [Politiques des opérateurs ROSA Classic](security-iam-rosa-classic-operator-policies.md).
## Autorisation accordée aux utilisateurs pour afficher leurs propres autorisations
Cet exemple montre comment vous pouvez créer une politique qui Utilisateurs IAM permet de visualiser les politiques intégrées et gérées associées à leur identité d'utilisateur. Cette politique inclut les autorisations permettant d'effectuer cette action sur la console ou par programmation à l'aide du. AWS CLI
```
{
"Version":"2012-10-17",
"Statement": [
{
"Action": [
"iam:GetUserPolicy",
"iam:ListGroupsForUser",
"iam:ListAttachedUserPolicies",
"iam:ListUserPolicies",
"iam:GetUser"
],
"Effect": "Allow",
"Resource": ["arn:aws:iam::*:user/${aws:username}"]
},
{
"Action": [
"iam:GetGroupPolicy",
"iam:GetPolicyVersion",
"iam:GetPolicy",
"iam:ListAttachedGroupPolicies",
"iam:ListGroupPolicies",
"iam:ListPolicyVersions",
"iam:ListPolicies",
"iam:ListUsers"
],
"Effect": "Allow",
"Resource": "*"
}
]
}
```
# Politiques relatives aux comptes ROSA Classic
Cette section fournit des détails sur les politiques de compte requises pour ROSA Classic. Ces autorisations sont nécessaires pour que ROSA classic puisse gérer les AWS ressources sur lesquelles les clusters s'exécutent et permettre à l'ingénieur de fiabilité des sites Red Hat de prendre en charge les clusters. Vous pouvez attribuer un préfixe personnalisé aux noms des politiques, mais ces politiques doivent sinon être nommées comme indiqué sur cette page (par exemple,`ManagedOpenShift-Installer-Role-Policy`).
Les politiques de compte sont spécifiques à une version OpenShift mineure et sont rétrocompatibles. Avant de créer ou de mettre à niveau un cluster, vous devez vérifier que la version de la politique et la version du cluster sont identiques en exécutant`rosa list account-roles`. Si la version de la politique est inférieure à la version du cluster, exécutez `rosa upgrade account-roles` pour mettre à niveau les rôles et les politiques associées. Vous pouvez utiliser les mêmes politiques de compte et les mêmes rôles pour plusieurs clusters de la même version mineure.
## [Préfixe] -Installer-Role-Policy
Vous pouvez attacher `[Prefix]-Installer-Role-Policy` à vos entités IAM. Avant de créer un cluster ROSA classic, vous devez d'abord associer cette politique à un rôle IAM nommé`[Prefix]-Installer-Role`. Cette politique accorde les autorisations requises qui permettent au ROSA programme d'installation de gérer les AWS ressources nécessaires à la création du cluster.
### Politique d’autorisations
Les autorisations définies dans ce document de politique précisent quelles actions sont autorisées ou refusées.
```
{
"Version":"2012-10-17",
"Statement": [
{
"Action": [
"autoscaling:DescribeAutoScalingGroups",
"ec2:AllocateAddress",
"ec2:AssociateAddress",
"ec2:AssociateDhcpOptions",
"ec2:AssociateRouteTable",
"ec2:AttachInternetGateway",
"ec2:AttachNetworkInterface",
"ec2:AuthorizeSecurityGroupEgress",
"ec2:AuthorizeSecurityGroupIngress",
"ec2:CopyImage",
"ec2:CreateDhcpOptions",
"ec2:CreateInternetGateway",
"ec2:CreateNatGateway",
"ec2:CreateNetworkInterface",
"ec2:CreateRoute",
"ec2:CreateRouteTable",
"ec2:CreateSecurityGroup",
"ec2:CreateSubnet",
"ec2:CreateTags",
"ec2:CreateVolume",
"ec2:CreateVpc",
"ec2:CreateVpcEndpoint",
"ec2:DeleteDhcpOptions",
"ec2:DeleteInternetGateway",
"ec2:DeleteNatGateway",
"ec2:DeleteNetworkInterface",
"ec2:DeleteRoute",
"ec2:DeleteRouteTable",
"ec2:DeleteSecurityGroup",
"ec2:DeleteSnapshot",
"ec2:DeleteSubnet",
"ec2:DeleteTags",
"ec2:DeleteVolume",
"ec2:DeleteVpc",
"ec2:DeleteVpcEndpoints",
"ec2:DeregisterImage",
"ec2:DescribeAccountAttributes",
"ec2:DescribeAddresses",
"ec2:DescribeAvailabilityZones",
"ec2:DescribeDhcpOptions",
"ec2:DescribeImages",
"ec2:DescribeInstanceAttribute",
"ec2:DescribeInstanceCreditSpecifications",
"ec2:DescribeInstances",
"ec2:DescribeInstanceStatus",
"ec2:DescribeInstanceTypeOfferings",
"ec2:DescribeInstanceTypes",
"ec2:DescribeInternetGateways",
"ec2:DescribeKeyPairs",
"ec2:DescribeNatGateways",
"ec2:DescribeNetworkAcls",
"ec2:DescribeNetworkInterfaces",
"ec2:DescribePrefixLists",
"ec2:DescribeRegions",
"ec2:DescribeReservedInstancesOfferings",
"ec2:DescribeRouteTables",
"ec2:DescribeSecurityGroups",
"ec2:DescribeSecurityGroupRules",
"ec2:DescribeSubnets",
"ec2:DescribeTags",
"ec2:DescribeVolumes",
"ec2:DescribeVpcAttribute",
"ec2:DescribeVpcClassicLink",
"ec2:DescribeVpcClassicLinkDnsSupport",
"ec2:DescribeVpcEndpoints",
"ec2:DescribeVpcs",
"ec2:DetachInternetGateway",
"ec2:DisassociateRouteTable",
"ec2:GetConsoleOutput",
"ec2:GetEbsDefaultKmsKeyId",
"ec2:ModifyInstanceAttribute",
"ec2:ModifyNetworkInterfaceAttribute",
"ec2:ModifySubnetAttribute",
"ec2:ModifyVpcAttribute",
"ec2:ReleaseAddress",
"ec2:ReplaceRouteTableAssociation",
"ec2:RevokeSecurityGroupEgress",
"ec2:RevokeSecurityGroupIngress",
"ec2:RunInstances",
"ec2:StartInstances",
"ec2:StopInstances",
"ec2:TerminateInstances",
"elasticloadbalancing:AddTags",
"elasticloadbalancing:ApplySecurityGroupsToLoadBalancer",
"elasticloadbalancing:AttachLoadBalancerToSubnets",
"elasticloadbalancing:ConfigureHealthCheck",
"elasticloadbalancing:CreateListener",
"elasticloadbalancing:CreateLoadBalancer",
"elasticloadbalancing:CreateLoadBalancerListeners",
"elasticloadbalancing:CreateTargetGroup",
"elasticloadbalancing:DeleteLoadBalancer",
"elasticloadbalancing:DeleteTargetGroup",
"elasticloadbalancing:DeregisterInstancesFromLoadBalancer",
"elasticloadbalancing:DeregisterTargets",
"elasticloadbalancing:DescribeAccountLimits",
"elasticloadbalancing:DescribeInstanceHealth",
"elasticloadbalancing:DescribeListeners",
"elasticloadbalancing:DescribeLoadBalancerAttributes",
"elasticloadbalancing:DescribeLoadBalancers",
"elasticloadbalancing:DescribeTags",
"elasticloadbalancing:DescribeTargetGroupAttributes",
"elasticloadbalancing:DescribeTargetGroups",
"elasticloadbalancing:DescribeTargetHealth",
"elasticloadbalancing:ModifyLoadBalancerAttributes",
"elasticloadbalancing:ModifyTargetGroup",
"elasticloadbalancing:ModifyTargetGroupAttributes",
"elasticloadbalancing:RegisterInstancesWithLoadBalancer",
"elasticloadbalancing:RegisterTargets",
"elasticloadbalancing:SetLoadBalancerPoliciesOfListener",
"iam:AddRoleToInstanceProfile",
"iam:CreateInstanceProfile",
"iam:DeleteInstanceProfile",
"iam:GetInstanceProfile",
"iam:TagInstanceProfile",
"iam:GetRole",
"iam:GetRolePolicy",
"iam:GetUser",
"iam:ListAttachedRolePolicies",
"iam:ListInstanceProfiles",
"iam:ListInstanceProfilesForRole",
"iam:ListRolePolicies",
"iam:ListRoles",
"iam:ListUserPolicies",
"iam:ListUsers",
"iam:RemoveRoleFromInstanceProfile",
"iam:SimulatePrincipalPolicy",
"iam:TagRole",
"iam:UntagRole",
"route53:ChangeResourceRecordSets",
"route53:ChangeTagsForResource",
"route53:CreateHostedZone",
"route53:DeleteHostedZone",
"route53:GetAccountLimit",
"route53:GetChange",
"route53:GetHostedZone",
"route53:ListHostedZones",
"route53:ListHostedZonesByName",
"route53:ListResourceRecordSets",
"route53:ListTagsForResource",
"route53:UpdateHostedZoneComment",
"s3:CreateBucket",
"s3:DeleteBucket",
"s3:DeleteObject",
"s3:DeleteObjectVersion",
"s3:GetAccelerateConfiguration",
"s3:GetBucketAcl",
"s3:GetBucketCORS",
"s3:GetBucketLocation",
"s3:GetBucketLogging",
"s3:GetBucketObjectLockConfiguration",
"s3:GetBucketPolicy",
"s3:GetReplicationConfiguration",
"s3:GetBucketRequestPayment",
"s3:GetBucketTagging",
"s3:GetBucketVersioning",
"s3:GetBucketWebsite",
"s3:GetEncryptionConfiguration",
"s3:GetLifecycleConfiguration",
"s3:GetObject",
"s3:GetObjectAcl",
"s3:GetObjectTagging",
"s3:GetObjectVersion",
"s3:GetReplicationConfiguration",
"s3:ListBucket",
"s3:ListBucketVersions",
"s3:PutBucketAcl",
"s3:PutBucketTagging",
"s3:PutBucketVersioning",
"s3:PutEncryptionConfiguration",
"s3:PutObject",
"s3:PutObjectAcl",
"s3:PutObjectTagging",
"servicequotas:GetServiceQuota",
"servicequotas:ListAWSDefaultServiceQuotas",
"sts:AssumeRole",
"sts:AssumeRoleWithWebIdentity",
"sts:GetCallerIdentity",
"tag:GetResources",
"tag:UntagResources",
"ec2:CreateVpcEndpointServiceConfiguration",
"ec2:DeleteVpcEndpointServiceConfigurations",
"ec2:DescribeVpcEndpointServiceConfigurations",
"ec2:DescribeVpcEndpointServicePermissions",
"ec2:DescribeVpcEndpointServices",
"ec2:ModifyVpcEndpointServicePermissions",
"kms:DescribeKey",
"cloudwatch:GetMetricData"
],
"Effect": "Allow",
"Resource": "*"
},
{
"Action": [
"secretsmanager:GetSecretValue"
],
"Effect": "Allow",
"Resource": "*",
"Condition": {
"StringEquals": {
"aws:ResourceTag/red-hat-managed": "true"
}
}
}
]
}
```
## [Préfixe] - ControlPlane -Role-Policy
Vous pouvez attacher `[Prefix]-ControlPlane-Role-Policy` à vos entités IAM. Avant de créer un cluster ROSA classic, vous devez d'abord associer cette politique à un rôle IAM nommé`[Prefix]-ControlPlane-Role`. Cette politique accorde les autorisations requises à ROSA classic pour gérer Amazon EC2 les Elastic Load Balancing ressources hébergeant le plan de ROSA contrôle, ainsi que pour lire KMS keys.
### Politique d’autorisations
Les autorisations définies dans ce document de politique précisent quelles actions sont autorisées ou refusées.
```
{
"Version":"2012-10-17",
"Statement": [
{
"Action": [
"ec2:AttachVolume",
"ec2:AuthorizeSecurityGroupIngress",
"ec2:CreateSecurityGroup",
"ec2:CreateTags",
"ec2:CreateVolume",
"ec2:DeleteSecurityGroup",
"ec2:DeleteVolume",
"ec2:Describe*",
"ec2:DetachVolume",
"ec2:ModifyInstanceAttribute",
"ec2:ModifyVolume",
"ec2:RevokeSecurityGroupIngress",
"elasticloadbalancing:AddTags",
"elasticloadbalancing:AttachLoadBalancerToSubnets",
"elasticloadbalancing:ApplySecurityGroupsToLoadBalancer",
"elasticloadbalancing:CreateListener",
"elasticloadbalancing:CreateLoadBalancer",
"elasticloadbalancing:CreateLoadBalancerPolicy",
"elasticloadbalancing:CreateLoadBalancerListeners",
"elasticloadbalancing:CreateTargetGroup",
"elasticloadbalancing:ConfigureHealthCheck",
"elasticloadbalancing:DeleteListener",
"elasticloadbalancing:DeleteLoadBalancer",
"elasticloadbalancing:DeleteLoadBalancerListeners",
"elasticloadbalancing:DeleteTargetGroup",
"elasticloadbalancing:DeregisterInstancesFromLoadBalancer",
"elasticloadbalancing:DeregisterTargets",
"elasticloadbalancing:Describe*",
"elasticloadbalancing:DetachLoadBalancerFromSubnets",
"elasticloadbalancing:ModifyListener",
"elasticloadbalancing:ModifyLoadBalancerAttributes",
"elasticloadbalancing:ModifyTargetGroup",
"elasticloadbalancing:ModifyTargetGroupAttributes",
"elasticloadbalancing:RegisterInstancesWithLoadBalancer",
"elasticloadbalancing:RegisterTargets",
"elasticloadbalancing:SetLoadBalancerPoliciesForBackendServer",
"elasticloadbalancing:SetLoadBalancerPoliciesOfListener",
"kms:DescribeKey"
],
"Effect": "Allow",
"Resource": "*"
}
]
}
```
## [Préfixe] -Worker-Role-Policy
Vous pouvez attacher `[Prefix]-Worker-Role-Policy` à vos entités IAM. Avant de créer un cluster ROSA classic, vous devez d'abord associer cette politique à un rôle IAM nommé`[Prefix]-Worker-Role`. Cette politique accorde les autorisations requises à ROSA classic pour décrire les instances EC2 exécutées en tant que nœuds de travail.
### Politique d’autorisations
Les autorisations définies dans ce document de politique précisent quelles actions sont autorisées ou refusées.
```
{
"Version":"2012-10-17",
"Statement": [
{
"Action": [
"ec2:DescribeInstances",
"ec2:DescribeRegions"
],
"Effect": "Allow",
"Resource": "*"
}
]
}
```
## [Préfixe] -Support-Role-Policy
Vous pouvez attacher `[Prefix]-Support-Role-Policy` à vos entités IAM. Avant de créer un cluster ROSA classic, vous devez d'abord associer cette politique à un rôle IAM nommé`[Prefix]-Support-Role`. Cette politique accorde les autorisations requises à l'ingénierie de fiabilité des sites Red Hat pour observer, diagnostiquer et prendre en charge les AWS ressources utilisées par les clusters ROSA Classic, y compris la possibilité de modifier l'état des nœuds du cluster.
### Politique d’autorisations
Les autorisations définies dans ce document de politique précisent quelles actions sont autorisées ou refusées.
```
{
"Version":"2012-10-17",
"Statement": [
{
"Action": [
"cloudtrail:DescribeTrails",
"cloudtrail:LookupEvents",
"cloudwatch:GetMetricData",
"cloudwatch:GetMetricStatistics",
"cloudwatch:ListMetrics",
"ec2-instance-connect:SendSerialConsoleSSHPublicKey",
"ec2:CopySnapshot",
"ec2:CreateNetworkInsightsPath",
"ec2:CreateSnapshot",
"ec2:CreateSnapshots",
"ec2:CreateTags",
"ec2:DeleteNetworkInsightsAnalysis",
"ec2:DeleteNetworkInsightsPath",
"ec2:DeleteTags",
"ec2:DescribeAccountAttributes",
"ec2:DescribeAddresses",
"ec2:DescribeAddressesAttribute",
"ec2:DescribeAggregateIdFormat",
"ec2:DescribeAvailabilityZones",
"ec2:DescribeByoipCidrs",
"ec2:DescribeCapacityReservations",
"ec2:DescribeCarrierGateways",
"ec2:DescribeClassicLinkInstances",
"ec2:DescribeClientVpnAuthorizationRules",
"ec2:DescribeClientVpnConnections",
"ec2:DescribeClientVpnEndpoints",
"ec2:DescribeClientVpnRoutes",
"ec2:DescribeClientVpnTargetNetworks",
"ec2:DescribeCoipPools",
"ec2:DescribeCustomerGateways",
"ec2:DescribeDhcpOptions",
"ec2:DescribeEgressOnlyInternetGateways",
"ec2:DescribeIamInstanceProfileAssociations",
"ec2:DescribeIdentityIdFormat",
"ec2:DescribeIdFormat",
"ec2:DescribeImageAttribute",
"ec2:DescribeImages",
"ec2:DescribeInstanceAttribute",
"ec2:DescribeInstances",
"ec2:DescribeInstanceStatus",
"ec2:DescribeInstanceTypeOfferings",
"ec2:DescribeInstanceTypes",
"ec2:DescribeInternetGateways",
"ec2:DescribeIpv6Pools",
"ec2:DescribeKeyPairs",
"ec2:DescribeLaunchTemplates",
"ec2:DescribeLocalGatewayRouteTables",
"ec2:DescribeLocalGatewayRouteTableVirtualInterfaceGroupAssociations",
"ec2:DescribeLocalGatewayRouteTableVpcAssociations",
"ec2:DescribeLocalGateways",
"ec2:DescribeLocalGatewayVirtualInterfaceGroups",
"ec2:DescribeLocalGatewayVirtualInterfaces",
"ec2:DescribeManagedPrefixLists",
"ec2:DescribeNatGateways",
"ec2:DescribeNetworkAcls",
"ec2:DescribeNetworkInsightsAnalyses",
"ec2:DescribeNetworkInsightsPaths",
"ec2:DescribeNetworkInterfaces",
"ec2:DescribePlacementGroups",
"ec2:DescribePrefixLists",
"ec2:DescribePrincipalIdFormat",
"ec2:DescribePublicIpv4Pools",
"ec2:DescribeRegions",
"ec2:DescribeReservedInstances",
"ec2:DescribeRouteTables",
"ec2:DescribeScheduledInstances",
"ec2:DescribeSecurityGroupReferences",
"ec2:DescribeSecurityGroupRules",
"ec2:DescribeSecurityGroups",
"ec2:DescribeSnapshotAttribute",
"ec2:DescribeSnapshots",
"ec2:DescribeSpotFleetInstances",
"ec2:DescribeStaleSecurityGroups",
"ec2:DescribeSubnets",
"ec2:DescribeTags",
"ec2:DescribeTransitGatewayAttachments",
"ec2:DescribeTransitGatewayConnectPeers",
"ec2:DescribeTransitGatewayConnects",
"ec2:DescribeTransitGatewayMulticastDomains",
"ec2:DescribeTransitGatewayPeeringAttachments",
"ec2:DescribeTransitGatewayRouteTables",
"ec2:DescribeTransitGateways",
"ec2:DescribeTransitGatewayVpcAttachments",
"ec2:DescribeVolumeAttribute",
"ec2:DescribeVolumes",
"ec2:DescribeVolumesModifications",
"ec2:DescribeVolumeStatus",
"ec2:DescribeVpcAttribute",
"ec2:DescribeVpcClassicLink",
"ec2:DescribeVpcClassicLinkDnsSupport",
"ec2:DescribeVpcEndpointConnectionNotifications",
"ec2:DescribeVpcEndpointConnections",
"ec2:DescribeVpcEndpoints",
"ec2:DescribeVpcEndpointServiceConfigurations",
"ec2:DescribeVpcEndpointServicePermissions",
"ec2:DescribeVpcEndpointServices",
"ec2:DescribeVpcPeeringConnections",
"ec2:DescribeVpcs",
"ec2:DescribeVpnConnections",
"ec2:DescribeVpnGateways",
"ec2:GetAssociatedIpv6PoolCidrs",
"ec2:GetConsoleOutput",
"ec2:GetManagedPrefixListEntries",
"ec2:GetSerialConsoleAccessStatus",
"ec2:GetTransitGatewayAttachmentPropagations",
"ec2:GetTransitGatewayMulticastDomainAssociations",
"ec2:GetTransitGatewayPrefixListReferences",
"ec2:GetTransitGatewayRouteTableAssociations",
"ec2:GetTransitGatewayRouteTablePropagations",
"ec2:ModifyInstanceAttribute",
"ec2:RebootInstances",
"ec2:RunInstances",
"ec2:SearchLocalGatewayRoutes",
"ec2:SearchTransitGatewayMulticastGroups",
"ec2:SearchTransitGatewayRoutes",
"ec2:StartInstances",
"ec2:StartNetworkInsightsAnalysis",
"ec2:StopInstances",
"ec2:TerminateInstances",
"elasticloadbalancing:ConfigureHealthCheck",
"elasticloadbalancing:DescribeAccountLimits",
"elasticloadbalancing:DescribeInstanceHealth",
"elasticloadbalancing:DescribeListenerCertificates",
"elasticloadbalancing:DescribeListeners",
"elasticloadbalancing:DescribeLoadBalancerAttributes",
"elasticloadbalancing:DescribeLoadBalancerPolicies",
"elasticloadbalancing:DescribeLoadBalancerPolicyTypes",
"elasticloadbalancing:DescribeLoadBalancers",
"elasticloadbalancing:DescribeRules",
"elasticloadbalancing:DescribeSSLPolicies",
"elasticloadbalancing:DescribeTags",
"elasticloadbalancing:DescribeTargetGroupAttributes",
"elasticloadbalancing:DescribeTargetGroups",
"elasticloadbalancing:DescribeTargetHealth",
"iam:GetRole",
"iam:ListRoles",
"kms:CreateGrant",
"route53:GetHostedZone",
"route53:GetHostedZoneCount",
"route53:ListHostedZones",
"route53:ListHostedZonesByName",
"route53:ListResourceRecordSets",
"s3:GetBucketTagging",
"s3:GetObjectAcl",
"s3:GetObjectTagging",
"s3:ListAllMyBuckets",
"sts:DecodeAuthorizationMessage",
"tiros:CreateQuery",
"tiros:GetQueryAnswer",
"tiros:GetQueryExplanation"
],
"Effect": "Allow",
"Resource": "*"
},
{
"Action": [
"s3:ListBucket"
],
"Effect": "Allow",
"Resource": [
"arn:aws:s3:::managed-velero*",
"arn:aws:s3:::*image-registry*"
]
}
]
}
```
# Politiques des opérateurs ROSA Classic
Cette section fournit des détails sur les politiques d'opérateur requises pour ROSA classic. Avant de créer un cluster ROSA classic, vous devez d'abord associer ces politiques aux rôles d'opérateur concernés. Un ensemble unique de rôles d'opérateur est requis pour chaque cluster.
Ces autorisations sont nécessaires pour permettre aux OpenShift opérateurs de gérer les nœuds de cluster ROSA Classic. Vous pouvez attribuer un préfixe personnalisé aux noms des politiques pour simplifier la gestion des politiques (par exemple,`ManagedOpenShift-openshift-ingress-operator-cloud-credentials`).
## [Préfixe] - -credentials openshift-ingress-operator-cloud
Vous pouvez attacher `[Prefix]-openshift-ingress-operator-cloud-credentials` à vos entités IAM. Cette politique accorde les autorisations requises à l'opérateur d'entrée pour provisionner et gérer les équilibreurs de charge et les configurations DNS pour l'accès au cluster externe. La politique permet également à l'opérateur d'entrée de lire et de filtrer les valeurs Route 53 des balises de ressources afin de découvrir les zones hébergées. Pour plus d'informations sur l'opérateur, voir [OpenShift Ingress Operator](https://github.com/openshift/cluster-ingress-operator) dans la OpenShift GitHub documentation.
### Politique d’autorisations
Les autorisations définies dans ce document de politique précisent quelles actions sont autorisées ou refusées.
```
{
"Version":"2012-10-17",
"Statement": [
{
"Action": [
"elasticloadbalancing:DescribeLoadBalancers",
"route53:ListHostedZones",
"route53:ListTagsForResources",
"route53:ChangeResourceRecordSets",
"tag:GetResources"
],
"Effect": "Allow",
"Resource": "*"
}
]
}
```
## [Préfixe] - - openshift-cluster-csi-drivers ebs-cloud-credentials
Vous pouvez attacher `[Prefix]-openshift-cluster-csi-drivers-ebs-cloud-credentials` à vos entités IAM. Cette politique accorde les autorisations requises à l'opérateur du pilote Amazon EBS CSI pour installer et gérer le pilote Amazon EBS CSI sur un cluster ROSA classic. Pour plus d'informations sur l'opérateur, consultez [aws-ebs-csi-driver-operator](https://github.com/openshift/aws-ebs-csi-driver-operator#aws-ebs-csi-driver-operator) dans la OpenShift GitHub documentation.
### Politique d’autorisations
Les autorisations définies dans ce document de politique précisent quelles actions sont autorisées ou refusées.
```
{
"Version":"2012-10-17",
"Statement": [
{
"Action": [
"ec2:AttachVolume",
"ec2:CreateSnapshot",
"ec2:CreateTags",
"ec2:CreateVolume",
"ec2:DeleteSnapshot",
"ec2:DeleteTags",
"ec2:DeleteVolume",
"ec2:DescribeAvailabilityZones",
"ec2:DescribeInstances",
"ec2:DescribeSnapshots",
"ec2:DescribeTags",
"ec2:DescribeVolumes",
"ec2:DescribeVolumesModifications",
"ec2:DetachVolume",
"ec2:EnableFastSnapshotRestores",
"ec2:ModifyVolume"
],
"Effect": "Allow",
"Resource": "*"
}
]
}
```
## [Préfixe] - -cloud-credentials openshift-machine-api-aws
Vous pouvez attacher `[Prefix]-openshift-machine-api-aws-cloud-credentials` à vos entités IAM. Cette politique accorde les autorisations requises à l'opérateur Machine Config pour décrire, exécuter et mettre fin aux Amazon EC2 instances gérées en tant que nœuds de travail. Cette politique accorde également des autorisations permettant le chiffrement du disque du volume racine du nœud de travail utilisé AWS KMS keys. Pour plus d'informations sur l'opérateur, consultez [machine-config-operator](https://github.com/openshift/machine-config-operator)la OpenShift GitHub documentation.
### Politique d’autorisations
Les autorisations définies dans ce document de politique précisent quelles actions sont autorisées ou refusées.
```
{
"Version":"2012-10-17",
"Statement": [
{
"Action": [
"ec2:CreateTags",
"ec2:DescribeAvailabilityZones",
"ec2:DescribeDhcpOptions",
"ec2:DescribeImages",
"ec2:DescribeInstances",
"ec2:DescribeInternetGateways",
"ec2:DescribeInstanceTypes",
"ec2:DescribeSecurityGroups",
"ec2:DescribeRegions",
"ec2:DescribeSubnets",
"ec2:DescribeVpcs",
"ec2:RunInstances",
"ec2:TerminateInstances",
"elasticloadbalancing:DescribeLoadBalancers",
"elasticloadbalancing:DescribeTargetGroups",
"elasticloadbalancing:DescribeTargetHealth",
"elasticloadbalancing:RegisterInstancesWithLoadBalancer",
"elasticloadbalancing:RegisterTargets",
"elasticloadbalancing:DeregisterTargets",
"iam:CreateServiceLinkedRole"
],
"Effect": "Allow",
"Resource": "*"
},
{
"Action": [
"kms:Decrypt",
"kms:Encrypt",
"kms:GenerateDataKey",
"kms:GenerateDataKeyWithoutPlainText",
"kms:DescribeKey"
],
"Effect": "Allow",
"Resource": "*"
},
{
"Action": [
"kms:RevokeGrant",
"kms:CreateGrant",
"kms:ListGrants"
],
"Effect": "Allow",
"Resource": "*",
"Condition": {
"Bool": {
"kms:GrantIsForAWSResource": true
}
}
}
]
}
```
## [Préfixe] - -cloud-credentials openshift-cloud-credential-operator
Vous pouvez attacher `[Prefix]-openshift-cloud-credential-operator-cloud-credentials` à vos entités IAM. Cette politique accorde les autorisations requises à l'opérateur d'identification du cloud pour récupérer des Utilisateur IAM informations, notamment la clé d'accès IDs, les documents de politique intégrés joints, la date de création de l'utilisateur, le chemin, l'ID utilisateur et le nom de ressource Amazon (ARN). Pour plus d'informations sur l'opérateur, consultez [cloud-credential-operator](https://github.com/openshift/cloud-credential-operator)la OpenShift GitHub documentation.
### Politique d’autorisations
Les autorisations définies dans ce document de politique précisent quelles actions sont autorisées ou refusées.
```
{
"Version":"2012-10-17",
"Statement": [
{
"Action": [
"iam:GetUser",
"iam:GetUserPolicy",
"iam:ListAccessKeys"
],
"Effect": "Allow",
"Resource": "*"
}
]
}
```
## [Préfixe] - -cloud-credentials openshift-image-registry-installer
Vous pouvez attacher `[Prefix]-openshift-image-registry-installer-cloud-credentials` à vos entités IAM. Cette politique accorde les autorisations requises à l'opérateur du registre d'images pour fournir et gérer les ressources du registre d'images intégré au cluster de ROSA Classic et des services dépendants, notamment Amazon S3. Cela est nécessaire pour que l'opérateur puisse installer et maintenir le registre interne d'un cluster ROSA classic. Pour plus d'informations sur l'opérateur, consultez la section [Opérateur de registre d'images](https://github.com/openshift/cluster-image-registry-operator#image-registry-operator) dans la OpenShift GitHub documentation.
### Politique d’autorisations
Les autorisations définies dans ce document de politique précisent quelles actions sont autorisées ou refusées.
```
{
"Version":"2012-10-17",
"Statement": [
{
"Action": [
"s3:CreateBucket",
"s3:DeleteBucket",
"s3:PutBucketTagging",
"s3:GetBucketTagging",
"s3:PutBucketPublicAccessBlock",
"s3:GetBucketPublicAccessBlock",
"s3:PutEncryptionConfiguration",
"s3:GetEncryptionConfiguration",
"s3:PutLifecycleConfiguration",
"s3:GetLifecycleConfiguration",
"s3:GetBucketLocation",
"s3:ListBucket",
"s3:GetObject",
"s3:PutObject",
"s3:DeleteObject",
"s3:ListBucketMultipartUploads",
"s3:AbortMultipartUpload",
"s3:ListMultipartUploadParts"
],
"Effect": "Allow",
"Resource": "*"
}
]
}
```
## [Préfixe] - - openshift-cloud-network-config controller-cloud-cr
Vous pouvez attacher `[Prefix]-openshift-cloud-network-config-controller-cloud-cr` à vos entités IAM. Cette politique accorde les autorisations requises à l'opérateur Cloud Network Config Controller pour provisionner et gérer les ressources réseau destinées à être utilisées par la superposition réseau de clusters ROSA Classic. L'opérateur utilise ces autorisations pour gérer les adresses IP privées des Amazon EC2 instances dans le cadre du cluster ROSA Classic. Pour plus d'informations sur l'opérateur, voir [C loud-network-config-controller](https://github.com/openshift/cloud-network-config-controller#cloud-network-config-controller-cncc) dans la OpenShift GitHub documentation.
### Politique d’autorisations
Les autorisations définies dans ce document de politique précisent quelles actions sont autorisées ou refusées.
```
{
"Version":"2012-10-17",
"Statement": [
{
"Action": [
"ec2:DescribeInstances",
"ec2:DescribeInstanceStatus",
"ec2:DescribeInstanceTypes",
"ec2:UnassignPrivateIpAddresses",
"ec2:AssignPrivateIpAddresses",
"ec2:UnassignIpv6Addresses",
"ec2:AssignIpv6Addresses",
"ec2:DescribeSubnets",
"ec2:DescribeNetworkInterfaces"
],
"Effect": "Allow",
"Resource": "*"
}
]
}
```
# AWS politiques gérées pour ROSA
Une politique AWS gérée est une politique autonome créée et administrée par AWS. AWS les politiques gérées sont conçues pour fournir des autorisations pour de nombreux cas d'utilisation courants afin que vous puissiez commencer à attribuer des autorisations aux utilisateurs, aux groupes et aux rôles.
N'oubliez pas que les politiques AWS gérées peuvent ne pas accorder d'autorisations de moindre privilège pour vos cas d'utilisation spécifiques, car elles sont accessibles à tous les AWS clients. Nous vous recommandons de réduire encore les autorisations en définissant des [politiques gérées par le client](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_managed-vs-inline.html#customer-managed-policies) qui sont propres à vos cas d’utilisation.
Vous ne pouvez pas modifier les autorisations définies dans les politiques AWS gérées. Si les autorisations définies dans une politique AWS gérée sont AWS mises à jour, la mise à jour affecte toutes les identités principales (utilisateurs, groupes et rôles) auxquelles la politique est attachée. AWS est le plus susceptible de mettre à jour une politique AWS gérée lorsqu'une nouvelle politique Service AWS est lancée ou lorsque de nouvelles opérations d'API sont disponibles pour les services existants. Pour plus d'informations, consultez la section [Politiques AWS gérées](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_managed-vs-inline.html#aws-managed-policies) dans le *Guide de IAM l'utilisateur*.
## AWS politique gérée : ROSAManage Abonnement
Vous pouvez associer la `ROSAManageSubscription` politique à vos IAM entités. Avant de procéder ROSA à l'activation dans la AWS ROSA console, vous devez d'abord associer cette politique à un rôle IAM.
Cette politique vous accorde les AWS Marketplace autorisations nécessaires pour gérer l' ROSA abonnement.
**Détails de l’autorisation**
Cette politique inclut les autorisations suivantes.
+ `aws-marketplace:Subscribe`- Accorde l'autorisation de s'abonner au AWS Marketplace produit pour ROSA.
+ `aws-marketplace:Unsubscribe`- Permet aux donneurs d'ordre de supprimer les abonnements aux AWS Marketplace produits.
+ `aws-marketplace:ViewSubscriptions`- Permet aux principaux de consulter les abonnements depuis AWS Marketplace. Cela est nécessaire pour que le IAM principal puisse consulter les AWS Marketplace abonnements disponibles.
Pour consulter le document de politique JSON complet, consultez la section [ROSAManageAbonnement](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/ROSAManageSubscription.html) dans le *Guide de référence des politiques AWS gérées*.
## Politiques relatives aux comptes ROSA with HCP
Cette section fournit des détails sur les politiques de compte requises pour ROSA avec des plans de contrôle hébergés (HCP). Ces politiques AWS gérées ajoutent les autorisations utilisées par ROSA avec les rôles HCP IAM. Les autorisations sont requises pour le support technique de l'ingénierie de fiabilité des sites (SRE) Red Hat, l'installation du cluster, le plan de contrôle et les fonctionnalités de calcul.
**Note**
AWS les politiques gérées sont destinées à être utilisées par ROSA avec des plans de contrôle hébergés (HCP). Les clusters ROSA Classic utilisent des politiques IAM gérées par le client. Pour plus d'informations sur les politiques classiques de ROSA, consultez [Politiques relatives aux comptes ROSA Classic](security-iam-rosa-classic-account-policies.md) et[Politiques des opérateurs ROSA Classic](security-iam-rosa-classic-operator-policies.md).
### AWS politique gérée : ROSAWorker InstancePolicy
Vous pouvez les `ROSAWorkerInstancePolicy` rattacher à vos IAM entités. Avant de créer un cluster, vous devez disposer d'un rôle IAM associé à cette politique. Un service ROSA passe des appels à d'autres Services AWS personnes en votre nom. Ils le font pour gérer les ressources que vous utilisez avec chaque cluster.
**Détails de l’autorisation**
Cette politique inclut les autorisations suivantes qui permettent aux nœuds de travail ROSA d'effectuer les tâches suivantes :
+ `ec2`— Évaluez Région AWS les détails de l' Amazon EC2 instance dans le cadre de la gestion du cycle de vie des nœuds du cluster ROSA.
+ `ecr`- Évaluez et obtenez des images à partir de référentiels ECR gérés par Rosa qui sont nécessaires à l'installation du cluster et à la gestion du cycle de vie des nœuds de travail.
Pour consulter le document de politique JSON complet, consultez [ROSAWorkerInstancePolicy](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/ROSAWorkerInstancePolicy.html)le *Guide de référence des politiques AWS gérées*.
### AWS stratégie gérée : ROSASRESupport Politique
Vous pouvez attacher `ROSASRESupportPolicy` à vos entités IAM.
Avant de créer un cluster ROSA avec plans de contrôle hébergés, vous devez d'abord associer cette politique à un rôle IAM. Cette politique accorde les autorisations requises aux ingénieurs de fiabilité des sites Red Hat (SREs) pour observer, diagnostiquer et prendre directement en charge les AWS ressources associées aux ROSA clusters, y compris la possibilité de modifier l'état des nœuds du ROSA cluster.
**Détails de l’autorisation**
Cette politique inclut les autorisations suivantes qui permettent SREs à Red Hat d'effectuer les tâches suivantes :
+ `cloudtrail`— Lisez AWS CloudTrail les événements et les sentiers pertinents pour le cluster.
+ `cloudwatch`— Lisez Amazon CloudWatch les métriques pertinentes pour le cluster.
+ `ec2`— Lisez, décrivez et passez en revue Amazon EC2 les composants liés à l'état du cluster, tels que les groupes de sécurité, les connexions aux points de terminaison VPC et l'état des volumes. Lancez, arrêtez, redémarrez et mettez fin à Amazon EC2 des instances.
+ `elasticloadbalancing`— Lisez, décrivez et passez en revue Elastic Load Balancing les paramètres liés à l'état de santé du cluster.
+ `iam`— Évaluez IAM les rôles liés à l'état de santé du cluster.
+ `route53`— Vérifiez les paramètres DNS liés à l'état du cluster.
+ `sts`— `DecodeAuthorizationMessage` — Lit IAM les messages à des fins de débogage.
Pour consulter le document de politique JSON complet, voir [ROSASRESupportPolitique](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/ROSASRESupportPolicy.html) dans le *Guide de référence des politiques AWS gérées*.
### AWS stratégie gérée : ROSAInstaller Politique
Vous pouvez les `ROSAInstallerPolicy` rattacher à vos IAM entités.
Avant de créer un cluster ROSA avec plans de contrôle hébergés, vous devez d'abord associer cette politique à un rôle IAM nommé`[Prefix]-ROSA-Worker-Role`. Cette politique permet aux entités d'ajouter n'importe quel rôle qui suit le `[Prefix]-ROSA-Worker-Role` modèle à un profil d'instance. Cette politique accorde les autorisations nécessaires au programme d'installation pour gérer les AWS ressources qui prennent en charge l'installation ROSA du cluster.
**Détails de l’autorisation**
Cette politique inclut les autorisations suivantes qui permettent au programme d'installation d'effectuer les tâches suivantes :
+ `ec2`— Exécutez Amazon EC2 des instances à l'aide d'un serveur AMIs hébergé Comptes AWS appartenant à Red Hat et géré par Red Hat. Décrivez les Amazon EC2 instances, les volumes et les ressources réseau associés aux Amazon EC2 nœuds. Cette autorisation est requise pour que le plan de contrôle Kubernetes puisse joindre des instances à un cluster et que le cluster puisse évaluer sa présence au sein de celui-ci. Amazon VPC Consultez Amazon EC2 Capacity Reservations pour prendre en charge la nouvelle fonctionnalité de réservation de capacité de ROSA. Marquez et supprimez des balises sur les sous-réseaux en utilisant la correspondance `"kubernetes.io/cluster/*"` des clés de balise. Cela est nécessaire pour garantir que l'équilibreur de charge utilisé pour l'entrée du cluster est créé uniquement dans les sous-réseaux applicables et pour gérer les balises d'identification du cluster Kubernetes.
+ `elasticloadbalancing`— Ajoutez des équilibreurs de charge aux nœuds cibles d'un cluster. Supprimez les équilibreurs de charge des nœuds cibles d'un cluster. Cette autorisation est requise pour que le plan de contrôle Kubernetes puisse approvisionner dynamiquement les équilibreurs de charge demandés par les services Kubernetes et les services d'application. OpenShift
+ `kms`— Lisez une AWS KMS clé, créez et gérez les autorisations et Amazon EC2 renvoyez une clé de données symétrique unique à utiliser en dehors de AWS KMS. Cela est nécessaire pour l'utilisation de `etcd` données chiffrées lorsque le `etcd` chiffrement est activé lors de la création du cluster.
+ `iam`— Validez les rôles et les politiques IAM. Provisionnez et gérez de manière dynamique les profils d' Amazon EC2 instance pertinents pour le cluster. Ajoutez des balises à un profil d'instance IAM à l'aide de l'`iam:TagInstanceProfile`autorisation. Fournissez des messages d'erreur du programme d'installation lorsque l'installation du cluster échoue en raison de l'absence d'un fournisseur OIDC de cluster spécifié par le client.
+ `route53`— Gérez les Route 53 ressources nécessaires à la création de clusters.
+ `servicequotas`— Évaluez les quotas de service requis pour créer un cluster.
+ `sts`— Créez des AWS STS informations d'identification temporaires pour ROSA les composants. Supposez les informations d'identification nécessaires à la création du cluster.
+ `secretsmanager`— Lisez une valeur secrète pour autoriser en toute sécurité la configuration OIDC gérée par le client dans le cadre du provisionnement du cluster.
Pour consulter le document de politique JSON complet, voir [ROSAInstallerPolitique](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/ROSAInstallerPolicy.html) dans le *Guide de référence des politiques AWS gérées*.
### AWS stratégie gérée : ROSAShared VPCRoute53 Politique
Vous pouvez les `ROSASharedVPCRoute53Policy` rattacher à vos IAM entités. Vous devez associer cette politique à un rôle IAM pour permettre à un cluster ROSA de passer des appels à d'autres utilisateurs Services AWS dans des environnements VPC partagés.
Cette politique permet au programme d'installation ROSA de configurer les enregistrements de la Route 53. Cette politique est destinée à être utilisée sur un VPC partagé et fournit un sous-ensemble d'autorisations Route 53 adaptées aux cas d'utilisation d'un VPC partagé.
**Détails de l’autorisation**
Cette politique inclut les autorisations suivantes qui permettent au programme d'installation de ROSA d'effectuer les tâches suivantes :
+ `route53`— Lisez les informations de zone DNS et les enregistrements DNS existants pour comprendre la configuration DNS actuelle. Créez, modifiez et supprimez des enregistrements DNS, mais uniquement pour des modèles de domaine spécifiques liés à ROSA`.hypershift.local`, notamment, `.openshiftapps.com` `.devshift.org``.openshiftusgov.com`, et. `.devshiftusgov.com` Ajoutez, modifiez ou supprimez des balises sur les ressources Route 53 pour la gestion et l'organisation des ressources.
+ `tag`— Découvrez et listez AWS les ressources en fonction de leurs balises, ce qui est utile pour identifier les ressources gérées par ROSA.
Pour plus de détails sur la politique, y compris la dernière version du document de politique JSON, consultez la section [ROSASharedVPCRoute53Politique](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/ROSASharedVPCRoute53Policy.html) dans le *Guide de référence des politiques AWS gérées*.
### AWS stratégie gérée : ROSAShared VPCEndpoint Politique
Vous pouvez les `ROSASharedVPCEndpointPolicy` rattacher à vos IAM entités. Vous devez associer cette politique à un rôle IAM pour permettre à un cluster ROSA de passer des appels à d'autres utilisateurs Services AWS dans des environnements VPC partagés.
Cette politique permet au programme d'installation ROSA de configurer des points de terminaison et des groupes de sécurité VPC dans des environnements VPC partagés.
**Détails de l’autorisation**
Cette politique inclut les autorisations suivantes qui permettent au programme d'installation de ROSA d'effectuer les tâches suivantes :
+ `ec2`— Autorisations en lecture seule pour décrire les ressources liées au VPC, y compris les points de terminaison VPC et les groupes de sécurité afin de VPCs comprendre l'environnement réseau. Créez, supprimez et modifiez des groupes de sécurité avec des restrictions basées sur des balises, ce qui permet à ROSA de créer et de gérer des groupes de sécurité pour le réseau de clusters tout en limitant les opérations aux seules ressources étiquetées ROSA. Créez, modifiez et supprimez des points de terminaison VPC avec des restrictions basées sur des balises, ce qui permet à ROSA de créer et de gérer des points de terminaison VPC pour une connectivité privée dans des environnements VPC partagés. Services AWS Appliquez des balises aux points de terminaison et aux groupes de sécurité VPC nouvellement créés lors de la création pour une identification et une gestion appropriées des ressources.
Pour plus de détails sur la politique, y compris la dernière version du document de politique JSON, consultez la section [ROSASharedVPCEndpointPolitique](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/ROSASharedVPCEndpointPolicy.html) dans le *Guide de référence des politiques AWS gérées*.
## ROSA avec les politiques des opérateurs HCP
Cette section fournit des détails sur les politiques d'opérateur requises pour ROSA avec des plans de contrôle hébergés (HCP). Vous pouvez associer ces politiques AWS gérées aux rôles d'opérateur nécessaires pour utiliser ROSA avec HCP. Les autorisations sont requises pour permettre aux OpenShift opérateurs de gérer ROSA avec des nœuds de cluster HCP.
**Note**
AWS les politiques gérées sont destinées à être utilisées par ROSA avec des plans de contrôle hébergés (HCP). Les clusters ROSA Classic utilisent des politiques IAM gérées par le client. Pour plus d'informations sur les politiques classiques de ROSA, consultez [Politiques relatives aux comptes ROSA Classic](security-iam-rosa-classic-account-policies.md) et[Politiques des opérateurs ROSA Classic](security-iam-rosa-classic-operator-policies.md).
### AWS politique gérée : ROSAAmazon EBSCSIDriver OperatorPolicy
Vous pouvez les `ROSAAmazonEBSCSIDriverOperatorPolicy` rattacher à vos IAM entités. Vous devez associer cette politique à un rôle IAM d'opérateur pour permettre à un cluster ROSA avec plans de contrôle hébergés de passer des appels à d'autres Services AWS. Un ensemble unique de rôles d'opérateur est requis pour chaque cluster.
Cette politique accorde les autorisations nécessaires à l'opérateur du pilote Amazon EBS CSI pour installer et gérer le pilote Amazon EBS CSI sur un ROSA cluster. Pour plus d'informations sur l'opérateur, voir [aws-ebs-csi-driver opérateur](https://github.com/openshift/aws-ebs-csi-driver-operator#aws-ebs-csi-driver-operator) dans la OpenShift GitHub documentation.
**Détails de l’autorisation**
Cette politique inclut les autorisations suivantes qui permettent au Amazon EBS chauffeur opérateur d'effectuer les tâches suivantes :
+ `ec2`— Créez, modifiez, attachez, détachez et supprimez Amazon EBS des volumes attachés à des Amazon EC2 instances. Créez et supprimez des instantanés de Amazon EBS volume et listez Amazon EC2 les instances, les volumes et les instantanés.
Pour consulter le document de politique JSON complet, consultez [ROSAAmazonEBSCSIDriverOperatorPolicy](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/ROSAAmazonEBSCSIDriverOperatorPolicy.html)le *Guide de référence des politiques AWS gérées*.
### AWS politique gérée : ROSAIngress OperatorPolicy
Vous pouvez les `ROSAIngressOperatorPolicy` rattacher à vos IAM entités. Vous devez associer cette politique à un rôle IAM d'opérateur pour permettre à un cluster ROSA avec plans de contrôle hébergés de passer des appels à d'autres Services AWS. Un ensemble unique de rôles d'opérateur est requis pour chaque cluster.
Cette politique accorde les autorisations requises à l'opérateur d'entrée pour provisionner et gérer les équilibreurs de charge et les configurations DNS pour les ROSA clusters. La politique autorise l'accès en lecture aux valeurs des balises. L'opérateur filtre ensuite les valeurs des balises pour les Route 53 ressources afin de découvrir les zones hébergées. Pour plus d'informations sur l'opérateur, voir [OpenShift Ingress Operator](https://github.com/openshift/cluster-ingress-operator#openshift-ingress-operator) dans la OpenShift GitHub documentation.
**Détails de l’autorisation**
Cette politique inclut les autorisations suivantes qui permettent à l'opérateur d'entrée d'effectuer les tâches suivantes :
+ `elasticloadbalancing`— Décrivez l'état des équilibreurs de charge provisionnés.
+ `route53`— Répertoriez les zones Route 53 hébergées et modifiez les enregistrements qui gèrent le DNS contrôlé par le cluster ROSA.
+ `tag`— Gérez les ressources étiquetées en utilisant l'`tag:GetResources`autorisation.
Pour consulter le document de politique JSON complet, consultez [ROSAIngressOperatorPolicy](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/ROSAIngressOperatorPolicy.html)le *Guide de référence des politiques AWS gérées*.
### AWS politique gérée : ROSAImage RegistryOperatorPolicy
Vous pouvez les `ROSAImageRegistryOperatorPolicy` rattacher à vos IAM entités. Vous devez associer cette politique à un rôle IAM d'opérateur pour permettre à un cluster ROSA avec plans de contrôle hébergés de passer des appels à d'autres Services AWS. Un ensemble unique de rôles d'opérateur est requis pour chaque cluster.
Cette politique accorde les autorisations requises à l'opérateur de registre d'images pour fournir et gérer les ressources pour le registre ROSA d'images du cluster et les services dépendants, y compris S3. Cela est nécessaire pour que l'opérateur puisse installer et gérer le registre interne d'un ROSA cluster. Pour plus d'informations sur l'opérateur, consultez la section [Opérateur de registre d'images](https://github.com/openshift/cluster-image-registry-operator#image-registry-operator) dans la OpenShift GitHub documentation.
**Détails de l’autorisation**
Cette politique inclut les autorisations suivantes qui permettent à l'opérateur du registre d'images d'effectuer les actions suivantes :
+ `s3`— Gérez et évaluez les Amazon S3 buckets en tant que stockage permanent pour le contenu des images du conteneur et les métadonnées du cluster.
Pour consulter le document de politique JSON complet, consultez [ROSAImageRegistryOperatorPolicy](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/ROSAImageRegistryOperatorPolicy.html)le *Guide de référence des politiques AWS gérées*.
### AWS politique gérée : ROSACloud NetworkConfigOperatorPolicy
Vous pouvez les `ROSACloudNetworkConfigOperatorPolicy` rattacher à vos IAM entités. Vous devez associer cette politique à un rôle IAM d'opérateur pour permettre à un cluster ROSA avec plans de contrôle hébergés de passer des appels à d'autres Services AWS. Un ensemble unique de rôles d'opérateur est requis pour chaque cluster.
Cette politique accorde les autorisations requises à l'opérateur Cloud Network Config Controller pour provisionner et gérer les ressources réseau pour la superposition réseau du ROSA cluster. L'opérateur utilise ces autorisations pour gérer les adresses IP privées Amazon EC2 des instances faisant partie du ROSA cluster. Pour plus d'informations sur l'opérateur, voir [C loud-network-config-controller](https://github.com/openshift/cloud-network-config-controller#cloud-network-config-controller-cncc) dans la OpenShift GitHub documentation.
**Détails de l’autorisation**
Cette politique inclut les autorisations suivantes qui permettent à l'opérateur Cloud Network Config Controller d'effectuer les tâches suivantes :
+ `ec2`— Lisez, attribuez et décrivez les configurations pour connecter Amazon EC2 des instances, Amazon VPC des sous-réseaux et des interfaces réseau élastiques dans un ROSA cluster.
Pour consulter le document de politique JSON complet, consultez [ROSACloudNetworkConfigOperatorPolicy](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/ROSACloudNetworkConfigOperatorPolicy.html)le *Guide de référence des politiques AWS gérées*.
### AWS politique gérée : ROSAKube ControllerPolicy
Vous pouvez les `ROSAKubeControllerPolicy` rattacher à vos IAM entités. Vous devez associer cette politique à un rôle IAM d'opérateur pour permettre à un cluster ROSA avec plans de contrôle hébergés de passer des appels à d'autres Services AWS. Un ensemble unique de rôles d'opérateur est requis pour chaque cluster.
Cette politique accorde les autorisations requises au contrôleur Kube pour gérer Amazon EC2 Elastic Load Balancing, et les AWS KMS ressources nécessaires à un cluster ROSA avec plans de contrôle hébergés. Pour plus d'informations sur ce contrôleur, consultez la section [Architecture du contrôleur](https://hypershift-docs.netlify.app/reference/controller-architecture/) dans la OpenShift documentation.
**Détails de l’autorisation**
Cette politique inclut les autorisations suivantes qui permettent au contrôleur Kube d'effectuer les tâches suivantes :
+ `ec2`— Créez, supprimez et ajoutez des balises aux groupes de sécurité des Amazon EC2 instances. Ajoutez des règles de trafic entrant aux groupes de sécurité. Décrivez les zones de disponibilité, Amazon EC2 les instances, les tables de routage VPCs, les groupes de sécurité et les sous-réseaux.
+ `elasticloadbalancing`— Créez et gérez les équilibreurs de charge et leurs politiques. Créez et gérez des écouteurs d'équilibrage de charge. Enregistrez et annulez les cibles auprès des groupes cibles et gérez les groupes cibles. Enregistrez et désenregistrez Amazon EC2 les instances auprès d'un équilibreur de charge, et ajoutez des balises aux équilibreurs de charge.
+ `kms`— Récupère des informations détaillées sur une AWS KMS clé. Cela est nécessaire pour l'utilisation de `etcd` données chiffrées lorsque le `etcd` chiffrement est activé lors de la création du cluster.
Pour consulter le document de politique JSON complet, consultez [ROSAKubeControllerPolicy](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/ROSAKubeControllerPolicy.html)le *Guide de référence des politiques AWS gérées*.
### AWS politique gérée : ROSANode PoolManagementPolicy
Vous pouvez les `ROSANodePoolManagementPolicy` rattacher à vos IAM entités. Vous devez associer cette politique à un rôle IAM d'opérateur pour permettre à un cluster ROSA avec plans de contrôle hébergés de passer des appels vers d'autres AWS services. Un ensemble unique de rôles d'opérateur est requis pour chaque cluster.
Cette politique accorde les autorisations requises au NodePool contrôleur pour décrire, exécuter et mettre fin aux Amazon EC2 instances gérées en tant que nœuds de travail. Cette politique accorde également des autorisations pour autoriser le chiffrement du disque du volume racine du nœud de travail à l'aide de AWS KMS clés, pour baliser l'interface elastic network attachée au nœud de travail et pour accéder aux réservations de capacité Amazon EC2. Pour plus d'informations sur ce contrôleur, consultez la section [Architecture du contrôleur](https://hypershift-docs.netlify.app/reference/controller-architecture/) dans la OpenShift documentation.
**Détails de l’autorisation**
Cette politique inclut les autorisations suivantes qui permettent au NodePool contrôleur d'effectuer les tâches suivantes :
+ `ec2`— Exécutez Amazon EC2 des instances à l'aide d'un serveur AMIs hébergé Comptes AWS appartenant à Red Hat et géré par Red Hat. Gérez les cycles de vie EC2 dans le cluster. ROSA Créez et intégrez dynamiquement des nœuds de travail avec Elastic Load Balancing Amazon VPC Route 53, Amazon EBS,, et Amazon EC2. Accédez aux réservations de capacité et décrivez-les pour prendre en charge la fonctionnalité de réservation de capacité de ROSA.
+ `iam`— À utiliser Elastic Load Balancing via le rôle lié au service nommé. `AWSServiceRoleForElasticLoadBalancing` Attribuez des rôles aux profils d' Amazon EC2 instance.
+ `kms`— Lisez une AWS KMS clé, créez et gérez les autorisations et Amazon EC2 renvoyez une clé de données symétrique unique à utiliser en dehors de AWS KMS. Cela est nécessaire pour permettre le chiffrement du disque du volume racine du nœud de travail.
Pour consulter le document de politique JSON complet, consultez [ROSANodePoolManagementPolicy](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/ROSANodePoolManagementPolicy.html)le *Guide de référence des politiques AWS gérées*.
### AWS stratégie gérée : ROSAKMSProvider Politique
Vous pouvez les `ROSAKMSProviderPolicy` rattacher à vos IAM entités. Vous devez associer cette politique à un rôle IAM d'opérateur pour permettre à un cluster ROSA avec plans de contrôle hébergés de passer des appels à d'autres Services AWS. Un ensemble unique de rôles d'opérateur est requis pour chaque cluster.
Cette politique accorde les autorisations requises au fournisseur de AWS chiffrement intégré pour gérer les AWS KMS clés qui prennent en charge le chiffrement `etcd` des données. Cette politique permet d' Amazon EC2 utiliser les clés KMS fournies par le fournisseur de AWS chiffrement pour chiffrer et déchiffrer `etcd` les données. Pour plus d'informations sur ce fournisseur, consultez la section [Fournisseur de AWS chiffrement](https://github.com/kubernetes-sigs/aws-encryption-provider#aws-encryption-provider) dans la documentation de Kubernetes GitHub .
**Détails de l’autorisation**
Cette politique inclut les autorisations suivantes qui permettent au fournisseur de AWS chiffrement d'effectuer les tâches suivantes :
+ `kms`— Chiffrez, déchiffrez et récupérez une AWS KMS clé. Cela est nécessaire pour l'utilisation de `etcd` données chiffrées lorsque le `etcd` chiffrement est activé lors de la création du cluster.
Pour consulter le document de politique JSON complet, voir [ROSAKMSProviderPolitique](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/ROSAKMSProviderPolicy.html) dans le *Guide de référence des politiques AWS gérées*.
### AWS politique gérée : ROSAControl PlaneOperatorPolicy
Vous pouvez les `ROSAControlPlaneOperatorPolicy` rattacher à vos IAM entités. Vous devez associer cette politique à un rôle IAM d'opérateur pour permettre à un cluster ROSA avec plans de contrôle hébergés de passer des appels à d'autres Services AWS. Un ensemble unique de rôles d'opérateur est requis pour chaque cluster.
Cette politique accorde les autorisations requises à l'opérateur du plan de contrôle pour gérer Amazon EC2 et affecter les Route 53 ressources à ROSA avec des clusters de plans de contrôle hébergés. Pour plus d'informations sur cet opérateur, consultez la section [Architecture du contrôleur](https://hypershift-docs.netlify.app/reference/controller-architecture/) dans la OpenShift documentation.
**Détails de l’autorisation**
Cette politique inclut les autorisations suivantes qui permettent à l'opérateur du plan de contrôle d'effectuer les tâches suivantes :
+ `ec2`— Créez et gérez des Amazon VPC points de terminaison.
+ `route53`— Répertoriez et modifiez les ensembles d' Route 53 enregistrements et listez les zones hébergées.
Pour consulter le document de politique JSON complet, consultez [ROSAControlPlaneOperatorPolicy](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/ROSAControlPlaneOperatorPolicy.html)le *Guide de référence des politiques AWS gérées*.
## ROSA mises à jour des politiques AWS gérées
Consultez les détails des mises à jour des politiques AWS gérées ROSA depuis que ce service a commencé à suivre ces modifications. Pour obtenir des alertes automatiques sur les modifications apportées à cette page, abonnez-vous au flux RSS de la page [Historique du document](doc-history.md).
| Modifier | Description | Date |
| --- | --- | --- |
| ROSANodePoolManagementPolicy — Politique mise à jour | ROSA a mis à jour la politique afin d'ajouter l'accès aux ressources pour les réservations de capacité Amazon EC2. Cette modification permet au NodePool contrôleur d'accéder aux réservations de capacité et de les décrire afin d'améliorer la gestion des ressources. Pour en savoir plus, veuillez consulter la section [AWS politique gérée : ROSANode PoolManagementPolicy](#security-iam-awsmanpol-rosanodepoolmanagementpolicy). | 3 septembre 2025 |
| ROSASharedVPCEndpointPolitique — Ajout d'une nouvelle politique | ROSA a ajouté une nouvelle politique permettant à l' ROSA installateur de configurer les points de terminaison et les groupes de sécurité VPC dans les environnements VPC partagés. Cette politique fournit un sous-ensemble d'autorisations EC2 adaptées aux cas d'utilisation de VPC partagés. Pour en savoir plus, veuillez consulter la section [AWS stratégie gérée : ROSAShared VPCEndpoint Politique](#security-iam-awsmanpol-rosasharedvpcendpointpolicy). | 7 août 2025 |
| ROSASharedVPCRoute53Politique — Ajout d'une nouvelle politique | ROSA a ajouté une nouvelle politique permettant à l' ROSA installateur de configurer les enregistrements Route 53 dans des environnements VPC partagés. Cette politique fournit un sous-ensemble d'autorisations Route 53 adaptées aux cas d'utilisation de VPC partagés. Pour en savoir plus, veuillez consulter la section [AWS stratégie gérée : ROSAShared VPCRoute53 Politique](#security-iam-awsmanpol-rosasharedvpcroute53policy). | 7 août 2025 |
| ROSAInstallerPolitique — Politique mise à jour | ROSA a mis à jour la politique afin de permettre à l' ROSA installateur d'inspecter les réservations de capacité Amazon EC2 afin de prendre en charge la nouvelle fonctionnalité de réservation de capacité de ROSA. Cette mise à jour permet également au programme d'installation de supprimer des balises sur les sous-réseaux à l'aide de clés de balise correspondantes `"kubernetes.io/cluster/*"` pour améliorer la gestion des balises du cluster Kubernetes. Pour en savoir plus, veuillez consulter la section [AWS stratégie gérée : ROSAInstaller Politique](#security-iam-awsmanpol-rosainstallerpolicy). | 7 août 2025 |
| ROSAImageRegistryOperatorPolicy — Politique mise à jour | ROSA a mis à jour la politique afin que les autorisations soient limitées au niveau des ressources du compartiment S3. Cette modification répond aux exigences de stockage ROSA pour les zones AWS commerciales et GovCloud régionales. Pour en savoir plus, veuillez consulter la section [AWS politique gérée : ROSAImage RegistryOperatorPolicy](#security-iam-awsmanpol-rosaimageregistryoperatorpolicy). | 19 mai 2025 |
| ROSANodePoolManagementPolicy — Politique mise à jour | ROSA a mis à jour la politique afin d'autoriser le balisage de l'interface Elastic network attachée au nœud de travail. Pour en savoir plus, veuillez consulter la section [AWS politique gérée : ROSANode PoolManagementPolicy](#security-iam-awsmanpol-rosanodepoolmanagementpolicy). | 5 mai 2025 |
| ROSAImageRegistryOperatorPolicy — Politique mise à jour | ROSA a mis à jour la politique afin de permettre à l'opérateur de registre OpenShift d'images Red Hat de provisionner et de gérer des buckets et des objets Amazon S3 dans AWS GovCloud les régions afin qu'ils soient utilisés par le registre d'images intégré au cluster ROSA. Cette modification répond aux exigences de stockage ROSA pour les AWS GovCloud régions. Pour en savoir plus, veuillez consulter la section [AWS politique gérée : ROSAImage RegistryOperatorPolicy](#security-iam-awsmanpol-rosaimageregistryoperatorpolicy). | 16 avril 2025 |
| ROSAWorkerInstancePolicy — Politique mise à jour | ROSA a mis à jour la politique afin de permettre aux nœuds de travail d'évaluer et d'obtenir des images à partir de référentiels ECR gérés par ROSA qui sont nécessaires à l'installation du cluster et à la gestion du cycle de vie des nœuds de travail. Pour en savoir plus, veuillez consulter la section [AWS politique gérée : ROSAWorker InstancePolicy](#security-iam-awsmanpol-rosaworkerinstancepolicy). | 3 mars 2025 |
| ROSANodePoolManagementPolicy — Politique mise à jour | ROSA a mis à jour la politique pour permettre aux interfaces réseau élastiques d'être étiquetées de la même manière que les instances EC2 uniquement pendant les RunInstances appels ec2 : lorsque la demande inclut la balise. `red-hat-managed: true` Ces autorisations sont nécessaires pour prendre en charge ROSA avec les clusters HCP 4.17. Pour en savoir plus, veuillez consulter la section [AWS politique gérée : ROSANode PoolManagementPolicy](#security-iam-awsmanpol-rosanodepoolmanagementpolicy). | 24 février 2025 |
| ROSAAmazonEBSCSIDriverOperatorPolicy — Politique mise à jour | ROSA a mis à jour la politique pour prendre en charge la nouvelle API d'autorisation des Amazon EBS instantanés. Pour en savoir plus, veuillez consulter la section [AWS politique gérée : ROSAAmazon EBSCSIDriver OperatorPolicy](#security-iam-awsmanpol-rosaamazonebscsidriveroperatorpolicy). | 17 janvier 2025 |
| ROSANodePoolManagementPolicy — Politique mise à jour | ROSA a mis à jour la politique pour permettre au gestionnaire de pool de ROSA nœuds de décrire les ensembles d'options DHCP afin de définir les noms DNS privés appropriés. Pour en savoir plus, veuillez consulter la section [AWS politique gérée : ROSANode PoolManagementPolicy](#security-iam-awsmanpol-rosanodepoolmanagementpolicy). | 2 mai 2024 |
| ROSAInstallerPolitique — Politique mise à jour | ROSA a mis à jour la politique pour permettre au ROSA programme d'installation d'ajouter des balises aux sous-réseaux en utilisant la correspondance `"kubernetes.io/cluster/*"` des clés de balise. Pour en savoir plus, veuillez consulter la section [AWS stratégie gérée : ROSAInstaller Politique](#security-iam-awsmanpol-rosainstallerpolicy). | 24 avril 2024 |
| ROSASRESupportPolitique — Politique mise à jour | ROSA a mis à jour la politique pour permettre au rôle SRE de récupérer des informations sur les profils d'instance marqués ROSA comme`red-hat-managed`. Pour en savoir plus, veuillez consulter la section [AWS stratégie gérée : ROSASRESupport Politique](#security-iam-awsmanpol-rosasresupportpolicy). | 10 avril 2024 |
| ROSAInstallerPolitique — Politique mise à jour | ROSA a mis à jour la politique pour permettre au ROSA programme d'installation de valider que les politiques AWS gérées pour ROSA sont attachées aux IAM rôles utilisés par ROSA. Cette mise à jour permet également au programme d'installation de déterminer si des politiques gérées par le client ont été associées aux ROSA rôles. Pour en savoir plus, veuillez consulter la section [AWS stratégie gérée : ROSAInstaller Politique](#security-iam-awsmanpol-rosainstallerpolicy). | 10 avril 2024 |
| ROSAInstallerPolitique — Politique mise à jour | ROSA a mis à jour la politique pour permettre au service de fournir des messages d'alerte au programme d'installation lorsque l'installation du cluster échoue en raison de l'absence d'un fournisseur OIDC de cluster spécifié par le client. Cette mise à jour permet également au service de récupérer les serveurs de noms DNS existants afin que les opérations de provisionnement de clusters soient idempotentes. Pour en savoir plus, veuillez consulter la section [AWS stratégie gérée : ROSAInstaller Politique](#security-iam-awsmanpol-rosainstallerpolicy). | 26 janvier 2024 |
| ROSASRESupportPolitique — Politique mise à jour | ROSA a mis à jour la politique pour permettre au service d'effectuer des opérations de lecture sur les groupes de sécurité à l'aide de l' DescribeSecurityGroups API. Pour en savoir plus, veuillez consulter la section [AWS stratégie gérée : ROSASRESupport Politique](#security-iam-awsmanpol-rosasresupportpolicy). | 22 janvier 2024 |
| ROSAImageRegistryOperatorPolicy — Politique mise à jour | ROSA a mis à jour la politique afin de permettre à l'opérateur du registre d'images d'effectuer des actions sur les Amazon S3 compartiments dans les régions portant des noms à 14 caractères. Pour en savoir plus, veuillez consulter la section [AWS politique gérée : ROSAImage RegistryOperatorPolicy](#security-iam-awsmanpol-rosaimageregistryoperatorpolicy). | 12 décembre 2023 |
| ROSAKubeControllerPolicy — Politique mise à jour | ROSA a mis à jour la politique pour permettre kube-controller-manager de décrire les zones de disponibilité, Amazon EC2 les instances, les tables de routage VPCs, les groupes de sécurité et les sous-réseaux. Pour en savoir plus, veuillez consulter la section [AWS politique gérée : ROSAKube ControllerPolicy](#security-iam-awsmanpol-rosakubecontrollerpolicy). | 16 octobre 2023 |
| ROSAManageAbonnement — Politique mise à jour | ROSA a mis à jour la politique pour ajouter le ROSA avec des plans de contrôle hébergés ProductId. Pour en savoir plus, veuillez consulter la section [AWS politique gérée : ROSAManage Abonnement](#security-iam-awsmanpol-rosamanagesubscription). | 1er août 2023 |
| ROSAKubeControllerPolicy — Politique mise à jour | ROSA a mis à jour la politique pour permettre de kube-controller-manager créer des équilibreurs de charge réseau en tant qu'équilibreurs de charge de service Kubernetes. Les équilibreurs de charge réseau offrent une meilleure capacité à gérer les charges de travail volatiles et prennent en charge les adresses IP statiques pour l'équilibreur de charge. Pour en savoir plus, veuillez consulter la section [AWS politique gérée : ROSAKube ControllerPolicy](#security-iam-awsmanpol-rosakubecontrollerpolicy). | 13 juillet 2023 |
| ROSANodePoolManagementPolicy — Ajout d'une nouvelle politique | ROSA a ajouté une nouvelle politique permettant au NodePool contrôleur de décrire, d'exécuter et de mettre fin aux Amazon EC2 instances gérées en tant que nœuds de travail. Cette politique permet également le chiffrement du disque du volume racine du nœud de travail à l'aide de AWS KMS clés. Pour en savoir plus, veuillez consulter la section [AWS politique gérée : ROSANode PoolManagementPolicy](#security-iam-awsmanpol-rosanodepoolmanagementpolicy). | 8 juin 2023 |
| ROSAInstallerPolitique — Ajout d'une nouvelle politique | ROSA a ajouté une nouvelle politique pour permettre au programme d'installation de gérer les AWS ressources qui prennent en charge l'installation du cluster. Pour en savoir plus, veuillez consulter la section [AWS stratégie gérée : ROSAInstaller Politique](#security-iam-awsmanpol-rosainstallerpolicy). | 6 juin 2023 |
| ROSASRESupportPolitique — Ajout d'une nouvelle politique | ROSA a ajouté une nouvelle politique permettant à Red Hat SREs d'observer, de diagnostiquer et de prendre directement en charge les AWS ressources associées aux ROSA clusters, y compris la possibilité de modifier l'état des nœuds du ROSA cluster. Pour en savoir plus, veuillez consulter la section [AWS stratégie gérée : ROSASRESupport Politique](#security-iam-awsmanpol-rosasresupportpolicy). | 1er juin 2023 |
| ROSAKMSProviderPolitique — Ajout d'une nouvelle politique | ROSA a ajouté une nouvelle politique pour permettre au fournisseur de AWS chiffrement intégré de gérer les AWS KMS clés afin de prendre en charge le chiffrement des données etcd. Pour en savoir plus, veuillez consulter la section [AWS stratégie gérée : ROSAKMSProvider Politique](#security-iam-awsmanpol-rosakmsproviderpolicy). | 27 avril 2023 |
| ROSAKubeControllerPolicy — Ajout d'une nouvelle politique | ROSA a ajouté une nouvelle politique pour permettre au contrôleur Kube de gérer les clusters de plans de contrôle ROSA hébergés Amazon EC2 Elastic Load Balancing, ainsi que les AWS KMS ressources nécessaires. Pour en savoir plus, veuillez consulter la section [AWS politique gérée : ROSAKube ControllerPolicy](#security-iam-awsmanpol-rosakubecontrollerpolicy). | 27 avril 2023 |
| ROSAImageRegistryOperatorPolicy — Ajout d'une nouvelle politique | ROSA a ajouté une nouvelle politique permettant à l'opérateur de registre d'images de fournir et de gérer les ressources pour le registre d'images ROSA intégré au cluster et les services dépendants, y compris S3. Pour en savoir plus, veuillez consulter la section [AWS politique gérée : ROSAImage RegistryOperatorPolicy](#security-iam-awsmanpol-rosaimageregistryoperatorpolicy). | 27 avril 2023 |
| ROSAControlPlaneOperatorPolicy — Ajout d'une nouvelle politique | ROSA a ajouté une nouvelle politique permettant à l'opérateur du plan de contrôle de gérer les clusters de plans de contrôle ROSA hébergés Amazon EC2 et de gérer les Route 53 ressources nécessaires. Pour en savoir plus, veuillez consulter la section [AWS politique gérée : ROSAControl PlaneOperatorPolicy](#security-iam-awsmanpol-rosacontrolplaneoperatorpolicy). | 24 avril 2023 |
| ROSACloudNetworkConfigOperatorPolicy — Ajout d'une nouvelle politique | ROSA a ajouté une nouvelle politique permettant à l'opérateur Cloud Network Config Controller de provisionner et de gérer les ressources réseau pour la superposition réseau du ROSA cluster. Pour en savoir plus, veuillez consulter la section [AWS politique gérée : ROSACloud NetworkConfigOperatorPolicy](#security-iam-awsmanpol-rosacloudnetworkconfigoperatorpolicy). | 20 avril 2023 |
| ROSAIngressOperatorPolicy — Ajout d'une nouvelle politique | ROSA a ajouté une nouvelle politique permettant à l'opérateur d'entrée de provisionner et de gérer les équilibreurs de charge et les configurations DNS pour les ROSA clusters. Pour en savoir plus, veuillez consulter la section [AWS politique gérée : ROSAIngress OperatorPolicy](#security-iam-awsmanpol-rosaingressoperatorpolicy). | 20 avril 2023 |
| ROSAAmazonEBSCSIDriverOperatorPolicy — Ajout d'une nouvelle politique | ROSA a ajouté une nouvelle politique permettant à l'opérateur du pilote Amazon EBS CSI d'installer et de gérer le pilote Amazon EBS CSI sur un ROSA cluster. Pour en savoir plus, veuillez consulter la section [AWS politique gérée : ROSAAmazon EBSCSIDriver OperatorPolicy](#security-iam-awsmanpol-rosaamazonebscsidriveroperatorpolicy). | 20 avril 2023 |
| ROSAWorkerInstancePolicy — Ajout d'une nouvelle politique | ROSA a ajouté une nouvelle politique pour permettre au service de gérer les ressources du cluster. Pour en savoir plus, veuillez consulter la section [AWS politique gérée : ROSAWorker InstancePolicy](#security-iam-awsmanpol-rosaworkerinstancepolicy). | 20 avril 2023 |
| ROSAManageAbonnement — Ajout d'une nouvelle politique | ROSA a ajouté une nouvelle politique pour accorder les AWS Marketplace autorisations nécessaires à la gestion de l' ROSA abonnement. Pour en savoir plus, veuillez consulter la section [AWS politique gérée : ROSAManage Abonnement](#security-iam-awsmanpol-rosamanagesubscription). | 11 avril 2022 |
| Red Hat OpenShift Service on AWS a commencé à suivre les modifications | Red Hat OpenShift Service on AWS a commencé à suivre les modifications apportées AWS à ses politiques gérées. | 2 mars 2022 |
# Résolution des problèmes ROSA d'identité et d'accès
Utilisez les informations suivantes pour vous aider à diagnostiquer et à résoudre les problèmes courants que vous pouvez rencontrer lorsque vous travaillez avec ROSA et IAM.
## AWS Organizations la politique de contrôle des services refuse AWS Marketplace les autorisations requises
Si votre politique AWS Organizations de contrôle des services (SCP) n'autorise pas les autorisations AWS Marketplace d'abonnement requises lorsque vous tentez de les activer ROSA, l'erreur de console suivante se produit.
```
An error occurred while enabling ROSA, because a service control policy (SCP) is denying required permissions. Contact your management account administrator, and consult the documentation for troubleshooting.
```
Si ce message d'erreur s'affiche, vous devez contacter votre administrateur pour obtenir de l'aide. Votre administrateur est la personne qui gère les comptes de votre organisation. Demandez à cette personne de faire ce qui suit :
1. Configurez le SCP pour autoriser `aws-marketplace:Subscribe``aws-marketplace:Unsubscribe`, et `aws-marketplace:ViewSubscriptions` autorisations. Pour plus d'informations, consultez la section [Mise à jour d'un SCP](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps_create.html#update_policy) dans le *guide de AWS Organizations l'utilisateur*.
1. Activez ROSA dans le compte de gestion de l'organisation.
1. Partagez l' ROSA abonnement avec les comptes des membres qui nécessitent un accès au sein de l'organisation. Pour plus d'informations, consultez la section [Partage des abonnements au sein d'une organisation](https://docs.aws.amazon.com/marketplace/latest/buyerguide/organizations-sharing.html) dans le *Guide de AWS Marketplace l'acheteur*.
## L'utilisateur ou le rôle ne dispose pas des AWS Marketplace autorisations requises
Si votre IAM principal ne dispose pas des autorisations AWS Marketplace d'abonnement requises lorsque vous tentez de l'activer ROSA, l'erreur de console suivante se produit.
```
An error occurred while enabling ROSA, because your user or role does not have the required permissions.
```
Pour résoudre ce problème, procédez comme suit :
1. Accédez à la [IAM console](https://console.aws.amazon.com/iam) et associez la politique AWS gérée `ROSAManageSubscription` à votre identité IAM. Pour plus d'informations, consultez la section [ROSAManageAbonnement](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/ROSAManageSubscription.html) dans le *Guide de référence des politiques AWS gérées*.
1. Suivez la procédure décrite dans [Activer ROSA et configurer les AWS prérequis](set-up.md#enable-rosa).
Si vous n'êtes pas autorisé à consulter ou à mettre à jour les autorisations définies IAM ou si vous recevez un message d'erreur, vous devez contacter votre administrateur pour obtenir de l'aide. Demandez à cette personne de `ROSAManageSubscription` s' IAM identifier et de suivre la procédure décrite dans[Activer ROSA et configurer les AWS prérequis](set-up.md#enable-rosa). Lorsqu'un administrateur exécute cette action, elle l'active ROSA en mettant à jour l'ensemble d'autorisations pour toutes les IAM identités relevant du Compte AWS.
## AWS Marketplace Autorisations requises bloquées par un administrateur
Si l'administrateur de votre compte a bloqué les autorisations AWS Marketplace d'abonnement requises, l'erreur de console suivante se produit lorsque vous tentez de les activer ROSA.
```
An error occurred while enabling ROSA because required permissions have been blocked by an administrator. ROSAManageSubscription includes the permissions required to enable ROSA. Consult the documentation and try again.
```
Si ce message d'erreur s'affiche, vous devez contacter votre administrateur pour obtenir de l'aide. Demandez à cette personne de faire ce qui suit :
1. Accédez à la [ROSA console](https://console.aws.amazon.com/rosa) et associez la politique AWS gérée `ROSAManageSubscription` à votre identité IAM. Pour plus d'informations, consultez la section [ROSAManageAbonnement](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/ROSAManageSubscription.html) dans le *Guide de référence des politiques AWS gérées*.
1. Suivez la procédure [Activer ROSA et configurer les AWS prérequis](set-up.md#enable-rosa) pour l'activer ROSA. Cette procédure est activée ROSA en mettant à jour l'ensemble d'autorisations pour toutes les IAM identités relevant du Compte AWS.
## Erreur lors de la création de l'équilibreur de charge : AccessDenied
Si vous n'avez pas créé d'équilibreur de charge, le rôle `AWSServiceRoleForElasticLoadBalacing` lié au service n'existe peut-être pas dans votre compte. L'erreur suivante se produit si vous tentez de créer un rôle ROSA cluster sans le `AWSServiceRoleForElasticLoadBalacing` rôle dans votre compte.
```
Error creating network Load Balancer: AccessDenied
```
Pour résoudre ce problème, procédez comme suit :
1. Vérifiez si le `AWSServiceRoleForElasticLoadBalancing` rôle est attribué à votre compte.
```
aws iam get-role --role-name "AWSServiceRoleForElasticLoadBalancing"
```
1. Si vous ne possédez pas ce rôle, suivez les instructions pour créer le rôle figurant dans la section [Créer le rôle lié à un service](https://docs.aws.amazon.com/elasticloadbalancing/latest/userguide/elb-service-linked-roles.html) dans le Guide de l'* Elastic Load Balancing utilisateur*.
# Résilience dans ROSA
## AWS résilience des infrastructures mondiales
L'infrastructure AWS mondiale est construite autour Régions AWS de zones de disponibilité. Régions AWS fournissent plusieurs zones de disponibilité physiquement séparées et isolées, connectées via un réseau à faible latence, à haut débit et hautement redondant. Avec les zones de disponibilité, vous pouvez concevoir et exploiter des applications et des bases de données qui basculent automatiquement d’une zone à l’autre sans interruption. Les zones de disponibilité sont davantage disponibles, tolérantes aux pannes et ont une plus grande capacité de mise à l’échelle que les infrastructures traditionnelles à un ou plusieurs centres de données.
ROSA offre aux clients la possibilité d'exécuter le plan de contrôle et le plan de données Kubernetes dans une seule zone de AWS disponibilité ou dans plusieurs zones de disponibilité. Bien que les clusters mono-AZ puissent être utiles à des fins d'expérimentation, les clients sont invités à exécuter leurs charges de travail dans plusieurs zones de disponibilité. Cela garantit que les applications peuvent résister même à une défaillance complète de la zone de disponibilité, un événement très rare en soi.
Pour plus d'informations sur les zones de disponibilité Régions AWS et les zones de disponibilité, consultez la section [Infrastructure AWS globale](https://aws.amazon.com/about-aws/global-infrastructure/).
## ROSA résilience des clusters
Le plan de ROSA contrôle comprend au moins trois nœuds du plan OpenShift de contrôle. Chaque nœud du plan de contrôle est composé d'une instance de serveur API, d'une `etcd` instance et de contrôleurs. En cas de défaillance d'un nœud du plan de contrôle, toutes les demandes d'API sont automatiquement acheminées vers les autres nœuds disponibles afin de garantir la disponibilité du cluster.
Le plan de ROSA données comprend au moins deux nœuds OpenShift d'infrastructure et deux nœuds OpenShift de travail. Les nœuds d'infrastructure exécutent des pods qui prennent en charge les composants de l'infrastructure du OpenShift cluster tels que le routeur par défaut, le OpenShift registre intégré et les composants pour les métriques et la surveillance du cluster. OpenShift les nœuds de travail exécutent des pods d'applications pour les utilisateurs finaux.
Les ingénieurs de fiabilité des sites Red Hat (SREs) gèrent entièrement le plan de contrôle et les nœuds d'infrastructure. Red Hat surveille le ROSA cluster de SREs manière proactive et est responsable du remplacement des nœuds du plan de contrôle et des nœuds d'infrastructure défaillants. Pour de plus amples informations, veuillez consulter [Vue d'ensemble des responsabilités pour ROSA](rosa-responsibilities.md).
**Important**
Étant donné qu' ROSA il s'agit d'un service géré, Red Hat est responsable de la gestion de l' AWS infrastructure sous-jacente qu'il ROSA utilise. Les clients ne doivent pas essayer d'arrêter manuellement les Amazon EC2 instances ROSA utilisées depuis la AWS console ou AWS CLI. Cette action peut entraîner une perte de données client.
Si un nœud de travail tombe en panne sur le plan de données, le plan de contrôle déplace les pods non planifiés vers le ou les nœuds de travail fonctionnels jusqu'à ce que le nœud défaillant soit récupéré ou remplacé. Les nœuds de travail défaillants peuvent être remplacés manuellement ou automatiquement en activant le dimensionnement automatique des machines d'un cluster. Pour plus d'informations, consultez la section [Mise à l'échelle automatique du cluster](https://access.redhat.com/documentation/en-us/red_hat_openshift_service_on_aws/4/html/cluster_administration/rosa-cluster-autoscaling) dans la documentation Red Hat.
## Résilience des applications déployées par le client
Bien qu'il ROSA fournisse de nombreuses protections pour garantir la haute disponibilité du service, les clients ont la responsabilité de développer leurs applications déployées dans un souci de haute disponibilité afin de protéger les charges de travail contre les temps d'arrêt. Pour plus d'informations, consultez [À propos de la disponibilité ROSA](https://access.redhat.com/documentation/en-us/red_hat_openshift_service_on_aws/4/html/introduction_to_rosa/policies-and-service-definition#about-availability-for-rosa) dans la documentation Red Hat.
# Sécurité de l'infrastructure dans ROSA
En tant que service géré, Red Hat OpenShift Service on AWS il est protégé par la sécurité du réseau AWS mondial. Pour plus d'informations sur les services AWS de sécurité et sur la manière dont AWS l'infrastructure est protégée, consultez la section [Sécurité du AWS cloud](https://aws.amazon.com/security). Pour concevoir votre AWS environnement en utilisant les meilleures pratiques en matière de sécurité de l'infrastructure, voir [Protection de l'infrastructure](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/infrastructure-protection.html) dans *Security Pillar — AWS Well-Architected Framework*.
Vous utilisez des appels d'API AWS publiés pour accéder ROSA via le AWS réseau. Les clients doivent prendre en charge les éléments suivants :
+ Protocole TLS (Transport Layer Security). Nous exigeons TLS 1.2 et recommandons TLS 1.3.
+ Ses suites de chiffrement PFS (Perfect Forward Secrecy) comme DHE (Ephemeral Diffie-Hellman) ou ECDHE (Elliptic Curve Ephemeral Diffie-Hellman). La plupart des systèmes modernes tels que Java 7 et les versions ultérieures prennent en charge ces modes.
En outre, les demandes doivent être signées à l’aide d’un ID de clé d’accès et d’une clé d’accès secrète associée à un principal IAM. Vous pouvez également utiliser [AWS Security Token Service](https://docs.aws.amazon.com/STS/latest/APIReference/) (AWS STS) pour générer des informations d’identification de sécurité temporaires et signer les demandes.
## Isolation du réseau en cluster
Les ingénieurs de fiabilité des sites Red Hat (SREs) sont responsables de la gestion continue et de la sécurité réseau du cluster et de la plate-forme d'application sous-jacente. Pour plus d'informations sur les responsabilités de Red Hat en matière de ROSA, consultez[Vue d'ensemble des responsabilités pour ROSA](rosa-responsibilities.md).
Lorsque vous créez un nouveau cluster, ROSA vous avez la possibilité de créer un point de terminaison et des routes d'application du serveur d'API Kubernetes public ou un point de terminaison d'API Kubernetes privé et des routes d'application. Cette connexion est utilisée pour communiquer avec votre cluster (à l'aide d'outils OpenShift de gestion tels que les CLI et OpenShift CLI ROSA). Une connexion privée permet à toutes les communications entre vos nœuds et le serveur d'API de rester au sein de votre VPC. Si vous activez l'accès privé au serveur d'API et aux routes d'application, vous devez utiliser un VPC existant et AWS PrivateLink connecter le VPC au service principal. OpenShift
L'accès au serveur d'API Kubernetes est sécurisé à l'aide d'une combinaison de Gestion des identités et des accès AWS (IAM) et d'un contrôle d'accès basé sur les rôles (RBAC) Kubernetes natif. Pour plus d'informations sur Kubernetes RBAC, consultez la section [Utilisation de l'autorisation](https://kubernetes.io/docs/reference/access-authn-authz/rbac/) RBAC dans la documentation de Kubernetes.
ROSA vous permet de créer des itinéraires d'application sécurisés à l'aide de plusieurs types de terminaison TLS pour délivrer des certificats au client. Pour plus d'informations, consultez la section [Routes sécurisées](https://access.redhat.com/documentation/en-us/red_hat_openshift_service_on_aws/4/html/networking/configuring-routes#configuring-default-certificate) dans la documentation Red Hat.
Si vous créez un ROSA cluster dans un VPC existant, vous spécifiez les sous-réseaux VPC et les zones de disponibilité que votre cluster doit utiliser. Vous définissez également les plages d'adresses CIDR que le réseau de clusters doit utiliser et vous associez ces plages d'adresses CIDR aux sous-réseaux VPC. Pour plus d'informations, consultez les [définitions des plages CIDR](https://access.redhat.com/documentation/en-us/red_hat_openshift_service_on_aws/4/html/networking/cidr-range-definitions) dans la documentation Red Hat.
Pour les clusters qui utilisent le point de terminaison d'API public, votre VPC ROSA doit être configuré avec un sous-réseau public et privé pour chaque zone de disponibilité dans laquelle vous souhaitez déployer le cluster. Pour les clusters qui utilisent le point de terminaison d'API privé, seuls les sous-réseaux privés sont requis.
Si vous utilisez un VPC existant, vous pouvez configurer vos ROSA clusters pour qu'ils utilisent un serveur proxy HTTP ou HTTPS pendant ou après la création du cluster afin de chiffrer le trafic Web du cluster, ajoutant ainsi un niveau de sécurité supplémentaire à vos données. Lorsque vous activez un proxy, l'accès direct à Internet est refusé aux composants principaux du cluster. Le proxy ne refuse pas l'accès à Internet pour les charges de travail des utilisateurs. Pour plus d'informations, consultez [la section Configuration d'un proxy à l'échelle du cluster](https://access.redhat.com/documentation/en-us/red_hat_openshift_service_on_aws/4/html/networking/configuring-a-cluster-wide-proxy) dans la documentation Red Hat.
## Isolation du réseau de pods
Si vous êtes administrateur de cluster, vous pouvez définir des politiques réseau au niveau du pod qui limitent le trafic aux pods de votre ROSA cluster.