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.
# Commencez avec ROSA
Red Hat OpenShift Service on AWS (ROSA) est un service géré que vous pouvez utiliser pour créer, dimensionner et déployer des applications conteneurisées avec la plateforme Red Hat OpenShift Enterprise Kubernetes. AWS
Vous pouvez utiliser les guides suivants pour créer votre premier ROSA cluster, accorder l'accès aux utilisateurs, déployer votre première application et apprendre à révoquer l'accès des utilisateurs et à supprimer votre cluster.
+ [Créez un cluster ROSA avec HCP à l'aide de la ROSA CLI](getting-started-hcp.md)- Créez votre premier cluster ROSA avec HCP à l'aide de AWS STS la ROSA CLI.
+ [Créez un cluster ROSA classique qui utilise AWS PrivateLink](getting-started-classic-private-link.md)- Créez votre premier cluster ROSA Classic en utilisant AWS PrivateLink.
+ [Créez un cluster ROSA classic à l'aide de la ROSA CLI](getting-started-classic-cli.md)- Créez votre premier cluster ROSA Classic à l'aide AWS STS de la ROSA CLI.
# Configurer pour utiliser ROSA
Pour préparer votre environnement à la création d'un ROSA cluster, vous devez effectuer les actions suivantes.
## Conditions préalables
Les conditions préalables suivantes doivent être remplies pour permettre la création de ROSA clusters.
+ Installez et configurez la dernière version AWS CLI. Pour plus d'informations, consultez [Installation ou mise à jour de la version la plus récente de l' AWS CLI](https://docs.aws.amazon.com/cli/latest/userguide/getting-started-install.html).
+ Installez et configurez les dernières ROSA CLI et OpenShift Container Platform CLI. Pour plus d'informations, consultez [Getting started with the ROSA CLI](https://access.redhat.com/documentation/en-us/red_hat_openshift_service_on_aws/4/html/rosa_cli/rosa-get-started-cli).
+ Les quotas de service requis doivent être définis pour Amazon EC2 Amazon VPC, Amazon EBS, et Elastic Load Balancing. AWS ou Red Hat peut demander des augmentations de quota de service en votre nom, selon les besoins de résolution du problème. Pour consulter les quotas de service requis ROSA, consultez les [Red Hat OpenShift Service on AWS points de terminaison et les quotas](https://docs.aws.amazon.com/general/latest/gr/rosa.html#limits_rosa) dans la *référence AWS générale*.
+ Pour bénéficier de l' AWS assistance ROSA, vous devez activer les plans de support AWS Business, Enterprise On-Ramp ou Enterprise. Red Hat peut demander une AWS assistance en votre nom pour résoudre le problème. Pour de plus amples informations, veuillez consulter [Obtenir de ROSA l'aide](rosa-support.md). Pour l'activer Support, consultez la [Support page](https://aws.amazon.com/premiumsupport/).
+ Si vous utilisez AWS Organizations pour gérer le service Comptes AWS qui héberge le ROSA service, la politique de contrôle des services (SCP) de l'organisation doit être configurée pour permettre à Red Hat d'exécuter les actions politiques répertoriées dans le SCP sans restriction. Pour de plus amples informations, veuillez consulter [AWS Organizations la politique de contrôle des services refuse AWS Marketplace les autorisations requises](security-iam-troubleshoot.md#error-aws-orgs-scp-denies-permissions). Pour plus d'informations SCPs, voir [Politiques de contrôle des services (SCPs)](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps.html).
+ Si vous déployez un ROSA cluster jeton de sécurité AWS STS dans une région activée Région AWS désactivée par défaut, vous devez mettre à jour le jeton de sécurité vers la version 2 pour toutes les régions du à l' Compte AWS aide de la commande suivante.
```
aws iam set-security-token-service-preferences --global-endpoint-token-version v2Token
```
Pour plus d'informations sur l'activation des régions, consultez le lien : accounts/latest/reference/manage
## Activer ROSA et configurer les AWS prérequis
Pour créer un ROSA cluster, vous devez activer le ROSA service dans la AWS ROSA console. La AWS ROSA console vérifie si vous disposez Compte AWS des AWS Marketplace autorisations nécessaires, des quotas de service et du nom du rôle lié au service Elastic Load Balancing (ELB). `AWSServiceRoleForElasticLoadBalancing` Si l'un de ces prérequis est absent, la console fournit des instructions sur la façon de configurer votre compte afin de répondre à ces prérequis.
1. Accédez à la [console ROSA](https://console.aws.amazon.com/rosa).
1. Choisissez **Démarrer**.
1. Sur la page **Vérifier ROSA les conditions requises**, sélectionnez **J'accepte de partager mes informations de contact avec Red Hat**.
1. Choisissez **Activer ROSA **.
1. Une fois que la page a vérifié que vos quotas de service répondent aux ROSA prérequis et que le rôle lié au service ELB est créé, ouvrez une nouvelle session de terminal pour créer votre première session à l'aide ROSA cluster de la CLI. ROSA
# Créez un cluster ROSA avec HCP à l'aide de la ROSA CLI
Les sections suivantes décrivent comment démarrer avec ROSA avec des plans de contrôle hébergés (ROSA avec HCP) à l'aide AWS STS de la ROSA CLI. Pour savoir comment créer un cluster ROSA avec HCP à l'aide de Terraform, consultez [la documentation Red Hat](https://docs.openshift.com/rosa/rosa_hcp/terraform/rosa-hcp-creating-a-cluster-quickly-terraform.html). Pour en savoir plus sur le fournisseur Terraform pour la création de ROSA clusters, consultez [la documentation Terraform](https://registry.terraform.io/providers/terraform-redhat/rhcs/latest/docs).
La ROSA CLI utilise le `auto` mode ou le `manual` mode pour créer les IAM ressources et la configuration OpenID Connect (OIDC) requises pour créer un. ROSA cluster`auto`le mode crée automatiquement les IAM rôles et politiques requis et le fournisseur OIDC. `manual`le mode affiche les AWS CLI commandes nécessaires pour créer les IAM ressources manuellement. En utilisant `manual` le mode, vous pouvez consulter les AWS CLI commandes générées avant de les exécuter manuellement. Avec `manual` le mode, vous pouvez également transmettre les commandes à un autre administrateur ou à un autre groupe de votre organisation afin qu'il puisse créer les ressources.
Les procédures décrites dans ce document utilisent le `auto` mode de la ROSA CLI pour créer les IAM ressources requises et la configuration OIDC pour ROSA avec HCP. Pour plus d'options de démarrage, consultez[Commencez avec ROSA](getting-started.md).
**Topics**
+ [Conditions préalables](#getting-started-hcp-prereqs)
+ [Création d'une Amazon VPC architecture](#create-vpc-hcp)
+ [Créez les IAM rôles requis et la configuration d'OpenID Connect](#create-iam-roles-oidc-hcp)
+ [Créez un cluster ROSA avec HCP à l'aide de la ROSA CLI et AWS STS](#create-hcp-cluster-cli)
+ [Configuration d'un fournisseur d'identité et autorisation cluster d'accès](#configure-oidc-hcp-cli)
+ [Accorder à l'utilisateur l'accès à un cluster](#grant-user-access-hcp-cli)
+ [Configurer les autorisations `cluster-admin`](#configure-cluster-admin-hcp)
+ [Configurer les autorisations `dedicated-admin`](#configure-dedicated-admin-hcp)
+ [Accédez à un cluster via la console Red Hat Hybrid Cloud](#console-access-hcp-cli)
+ [Déployer une application depuis le catalogue des développeurs](#deploy-app-hcp-cli)
+ [Révoquer `cluster-admin` les autorisations d'un utilisateur](#revoke-cluster-admin-hcp-cli)
+ [Révoquer `dedicated-admin` les autorisations d'un utilisateur](#revoke-dedicated-admin-hcp-cli)
+ [Révoquer l'accès d'un utilisateur à un cluster](#revoke-user-hcp-cli)
+ [Supprimer un cluster et des AWS STS ressources](#delete-cluster-hcp-cli)
## Conditions préalables
Effectuez les actions préalables répertoriées dans[Configurer pour utiliser ROSA](set-up.md).
## Création d'une Amazon VPC architecture
La procédure suivante crée une Amazon VPC architecture qui peut être utilisée pour héberger un cluster. Toutes les cluster ressources sont hébergées dans le sous-réseau privé. Le sous-réseau public achemine le trafic sortant du sous-réseau privé via une passerelle NAT vers l'Internet public. Cet exemple utilise le bloc CIDR `10.0.0.0/16` pour le Amazon VPC. Vous pouvez toutefois choisir un autre bloc CIDR. Pour de plus amples informations, veuillez consulter [Dimensionnement d’un VPC](https://docs.aws.amazon.com/vpc/latest/userguide/configure-your-vpc.html#vpc-sizing).
**Important**
Si Amazon VPC les exigences ne sont pas satisfaites, la création du cluster échoue.
**Example**
1. Installez la CLI Terraform. Pour plus d'informations, consultez les [instructions d'installation dans la documentation Terraform](https://developer.hashicorp.com/terraform/tutorials/aws-get-started/install-cli).
1. Ouvrez une session de terminal et clonez le référentiel VPC Terraform.
```
git clone https://github.com/openshift-cs/terraform-vpc-example
```
1. Accédez au répertoire créé.
```
cd terraform-vpc-example
```
1. Initiez le fichier Terraform.
```
terraform init
```
Une fois terminé, la CLI renvoie un message indiquant que Terraform a été initialisé avec succès.
1. Pour créer un plan Terraform basé sur le modèle existant, exécutez la commande suivante. Le Région AWS doit être spécifié. Vous pouvez éventuellement choisir de spécifier un nom de cluster.
```
terraform plan -out rosa.tfplan -var region=
```
Une fois la commande exécutée, un `rosa.tfplan` fichier est ajouté au `hypershift-tf` répertoire. Pour des options plus détaillées, consultez [le fichier README du référentiel Terraform VPC](https://github.com/openshift-cs/terraform-vpc-example/blob/main/README.md).
1. Appliquez le fichier de plan pour créer le VPC.
```
terraform apply rosa.tfplan
```
Une fois l'opération terminée, la CLI a renvoyé un message de réussite qui vérifie les ressources ajoutées.
1. (Facultatif) Créez des variables d'environnement pour le sous-réseau privé, public et machinepool approvisionné par Terraform à utiliser lors de la création de votre cluster ROSA avec IDs HCP.
```
export SUBNET_IDS=$(terraform output -raw cluster-subnets-string)
```
1. (Facultatif) Vérifiez que les variables d'environnement ont été correctement définies.
```
echo $SUBNET_IDS
```
1. Ouvrez la [Amazon VPC console](https://console.aws.amazon.com/vpc).
1. Sur le tableau de bord VPC, choisissez **Create VPC (Créer un VPC)**.
1. Sous **Ressources à créer**, choisissez **VPC et plus encore**.
1. Maintenez l'option **Génération automatique de balise de nom** sélectionnée pour créer des balises de nom pour les ressources VPC, ou désactivez-la pour fournir vos propres balises de nom pour les ressources VPC.
1. Pour le **bloc IPv4 CIDR**, entrez une plage d' IPv4 adresses pour le VPC. Un VPC doit avoir une plage d' IPv4 adresses.
1. (Facultatif) Pour prendre en charge IPv6 le trafic, choisissez le bloc **IPv6 CIDR, le bloc CIDR fourni par Amazon IPv6 **.
1. Laissez la **location telle `Default` quelle**.
1. Pour **Nombre de zones de disponibilité (AZs)**, choisissez le nombre dont vous avez besoin. Pour les déploiements multi-AZ, ROSA trois zones de disponibilité sont nécessaires. Pour choisir le AZs pour vos sous-réseaux, développez **Personnaliser AZs**.
**Note**
Certains types d' ROSA instances ne sont disponibles que dans certaines zones de disponibilité. Vous pouvez utiliser la `rosa list instance-types` commande ROSA CLI pour répertorier tous les types d' ROSA instances disponibles. Pour vérifier si un type d'instance est disponible pour une zone de disponibilité donnée, utilisez la AWS CLI commande`aws ec2 describe-instance-type-offerings --location-type availability-zone --filters Name=location,Values= --region --output text | egrep ""`.
1. Pour configurer vos sous-réseaux, choisissez des valeurs pour **Nombre de sous-réseaux publics** et **Nombre de sous-réseaux privés**. Pour choisir les plages d'adresses IP pour vos sous-réseaux, développez **Personnaliser les blocs CIDR des sous-réseaux**.
**Note**
ROSA avec HCP exige que les clients configurent au moins un sous-réseau public et privé par zone de disponibilité utilisée pour créer des clusters.
1. Pour accorder aux ressources du sous-réseau privé l'accès à l'Internet public via IPv4, pour les **passerelles NAT**, choisissez le nombre de AZs passerelles NAT à créer. En production, nous vous recommandons de déployer une passerelle NAT dans chaque zone de disponibilité avec des ressources nécessitant un accès à l'Internet public.
1. (Facultatif) Si vous devez accéder Amazon S3 directement depuis votre VPC, choisissez les points de **terminaison du VPC**, S3 Gateway.
1. Laissez les options DNS par défaut sélectionnées. ROSA nécessite la prise en charge du nom d'hôte DNS sur le VPC.
1. Développez les **balises supplémentaires**, choisissez **Ajouter une nouvelle balise** et ajoutez les clés de balise suivantes. ROSA utilise des contrôles automatisés avant le vol qui vérifient que ces balises sont utilisées.
+ **Clé :** `kubernetes.io/role/elb`
+ **Clé :** `kubernetes.io/role/internal-elb`
1. Sélectionnez **Create VPC** (Créer un VPC).
1. Créez un VPC avec un bloc d'adresse CIDR `10.0.0.0/16`.
```
aws ec2 create-vpc \
--cidr-block 10.0.0.0/16 \
--query Vpc.VpcId \
--output text
```
La commande précédente renvoie l'ID du VPC. Voici un exemple de sortie.
```
vpc-1234567890abcdef0
```
1. Stockez l'ID du VPC dans une variable d'environnement.
```
export VPC_ID=vpc-1234567890abcdef0
```
1. Créez une `Name` balise pour le VPC à l'aide de la variable d'`VPC_ID`environnement.
```
aws ec2 create-tags --resources $VPC_ID --tags Key=Name,Value=MyVPC
```
1. Activez la prise en charge des noms d'hôte DNS sur le VPC.
```
aws ec2 modify-vpc-attribute \
--vpc-id $VPC_ID \
--enable-dns-hostnames
```
1. Créez un sous-réseau public et privé dans le VPC, en spécifiant les zones de disponibilité dans lesquelles les ressources doivent être créées.
**Important**
ROSA avec HCP exige que les clients configurent au moins un sous-réseau public et privé par zone de disponibilité utilisée pour créer des clusters. Pour les déploiements multi-AZ, trois zones de disponibilité sont requises. Si ces conditions ne sont pas remplies, la création du cluster échoue.
**Note**
Certains types d' ROSA instances ne sont disponibles que dans certaines zones de disponibilité. Vous pouvez utiliser la `rosa list instance-types` commande ROSA CLI pour répertorier tous les types d' ROSA instances disponibles. Pour vérifier si un type d'instance est disponible pour une zone de disponibilité donnée, utilisez la AWS CLI commande`aws ec2 describe-instance-type-offerings --location-type availability-zone --filters Name=location,Values= --region --output text | egrep ""`.
```
aws ec2 create-subnet \
--vpc-id $VPC_ID \
--cidr-block 10.0.1.0/24 \
--availability-zone us-east-1a \
--query Subnet.SubnetId \
--output text
aws ec2 create-subnet \
--vpc-id $VPC_ID \
--cidr-block 10.0.0.0/24 \
--availability-zone us-east-1a \
--query Subnet.SubnetId \
--output text
```
1. Stockez les sous-réseaux public et privé IDs dans des variables d'environnement.
```
export PUBLIC_SUB=subnet-1234567890abcdef0
export PRIVATE_SUB=subnet-0987654321fedcba0
```
1. Créez les balises suivantes pour vos sous-réseaux VPC. ROSA utilise des contrôles automatisés avant le vol qui vérifient que ces balises sont utilisées.
**Note**
Vous devez baliser au moins un sous-réseau privé et, le cas échéant, un sous-réseau public.
```
aws ec2 create-tags --resources $PUBLIC_SUB --tags Key=kubernetes.io/role/elb,Value=1
aws ec2 create-tags --resources $PRIVATE_SUB --tags Key=kubernetes.io/role/internal-elb,Value=1
```
1. Créez une passerelle Internet et une table de routage pour le trafic sortant. Créez une table de routage et une adresse IP élastique pour le trafic privé.
```
aws ec2 create-internet-gateway \
--query InternetGateway.InternetGatewayId \
--output text
aws ec2 create-route-table \
--vpc-id $VPC_ID \
--query RouteTable.RouteTableId \
--output text
aws ec2 allocate-address \
--domain vpc \
--query AllocationId \
--output text
aws ec2 create-route-table \
--vpc-id $VPC_ID \
--query RouteTable.RouteTableId \
--output text
```
1. Stockez les IDs dans les variables d'environnement.
```
export IGW=igw-1234567890abcdef0
export PUBLIC_RT=rtb-0987654321fedcba0
export EIP=eipalloc-0be6ecac95EXAMPLE
export PRIVATE_RT=rtb-1234567890abcdef0
```
1. Connectez la passerelle Internet au VPC.
```
aws ec2 attach-internet-gateway \
--vpc-id $VPC_ID \
--internet-gateway-id $IGW
```
1. Associez la table de routage publique au sous-réseau public et configurez le trafic pour qu'il soit acheminé vers la passerelle Internet.
```
aws ec2 associate-route-table \
--subnet-id $PUBLIC_SUB \
--route-table-id $PUBLIC_RT
aws ec2 create-route \
--route-table-id $PUBLIC_RT \
--destination-cidr-block 0.0.0.0/0 \
--gateway-id $IGW
```
1. Créez la passerelle NAT et associez-la à l'adresse IP élastique pour activer le trafic vers le sous-réseau privé.
```
aws ec2 create-nat-gateway \
--subnet-id $PUBLIC_SUB \
--allocation-id $EIP \
--query NatGateway.NatGatewayId \
--output text
```
1. Associez la table de routage privée au sous-réseau privé et configurez le trafic pour qu'il soit acheminé vers la passerelle NAT.
```
aws ec2 associate-route-table \
--subnet-id $PRIVATE_SUB \
--route-table-id $PRIVATE_RT
aws ec2 create-route \
--route-table-id $PRIVATE_RT \
--destination-cidr-block 0.0.0.0/0 \
--gateway-id $NATGW
```
1. (Facultatif) Pour les déploiements multi-AZ, répétez les étapes ci-dessus pour configurer deux autres zones de disponibilité avec des sous-réseaux publics et privés.
## Créez les IAM rôles requis et la configuration d'OpenID Connect
Avant de créer un cluster ROSA avec HCP, vous devez créer les IAM rôles et politiques nécessaires ainsi que la configuration OpenID Connect (OIDC). Pour plus d'informations sur IAM les rôles et les politiques de ROSA avec HCP, consultez[AWS politiques gérées pour ROSA](security-iam-awsmanpol.md).
Cette procédure utilise le `auto` mode de la ROSA CLI pour créer automatiquement la configuration OIDC nécessaire à la création d'un cluster ROSA avec HCP.
1. Créez les rôles et politiques de IAM compte requis. Le `--force-policy-creation` paramètre met à jour tous les rôles et politiques existants. Si aucun rôle ni aucune politique n'est présent, la commande crée ces ressources à la place.
```
rosa create account-roles --force-policy-creation
```
**Note**
Si votre jeton d'accès hors ligne a expiré, la ROSA CLI affiche un message d'erreur indiquant que votre jeton d'autorisation doit être mis à jour. Pour connaître les étapes de résolution des problèmes, voir[Résoudre les problèmes liés aux jetons d'accès hors ligne expirés de la ROSA CLI](troubleshooting-rosa.md#rosa-cli-expired-token).
1. Créez la configuration OpenID Connect (OIDC) qui permet l'authentification des utilisateurs auprès du cluster. Cette configuration est enregistrée pour être utilisée avec OpenShift Cluster Manager (OCM).
```
rosa create oidc-config --mode=auto
```
1. Copiez l'ID de configuration OIDC fourni dans la sortie de la ROSA CLI. L'ID de configuration OIDC doit être fourni ultérieurement pour créer le cluster ROSA avec HCP.
1. Pour vérifier les configurations OIDC disponibles pour les clusters associés à votre organisation d'utilisateurs, exécutez la commande suivante.
```
rosa list oidc-config
```
1. Créez les rôles d' IAM opérateur requis, en les `` remplaçant par l'ID de configuration OIDC copié précédemment.
**Example**
**Important**
Vous devez fournir un préfixe `` lors de la création des rôles d'opérateur. Si vous ne le faites pas, une erreur se produit.
```
rosa create operator-roles --prefix --oidc-config-id --hosted-cp
```
1. Pour vérifier que les rôles d' IAM opérateur ont été créés, exécutez la commande suivante :
```
rosa list operator-roles
```
## Créez un cluster ROSA avec HCP à l'aide de la ROSA CLI et AWS STS
Vous pouvez créer un ROSA avec HCP cluster en utilisant AWS Security Token Service (AWS STS) et le `auto` mode fourni dans la ROSA CLI. Vous avez la possibilité de créer un cluster avec une API publique et Ingress ou une API privée et Ingress.
Vous pouvez créer une cluster avec une seule zone de disponibilité (mono-AZ) ou plusieurs zones de disponibilité (multi-AZ). Dans les deux cas, la valeur CIDR de votre machine doit correspondre à la valeur CIDR de votre VPC.
La procédure suivante utilise la `rosa create cluster --hosted-cp` commande pour créer un ROSA mono-AZ avec HCP cluster. Pour créer un Multi-AZ cluster, spécifiez `multi-az` dans la commande et le sous-réseau privé IDs pour chaque sous-réseau privé sur lequel vous souhaitez effectuer le déploiement.
1. Créez un cluster ROSA avec HCP à l'aide de l'une des commandes suivantes.
+ Créez un cluster ROSA avec HCP avec une API publique et une entrée, en spécifiant le nom du cluster, le préfixe du rôle d'opérateur, l'ID de configuration OIDC et le sous-réseau public et privé. IDs
```
rosa create cluster --cluster-name= --sts --mode=auto --hosted-cp --operator-roles-prefix --oidc-config-id --subnet-ids=,
```
+ Créez un cluster ROSA avec HCP avec une API privée et une entrée, en spécifiant le nom du cluster, le préfixe du rôle d'opérateur, l'ID de configuration OIDC et le sous-réseau privé. IDs
```
rosa create cluster --private --cluster-name= --sts --mode=auto --hosted-cp --subnet-ids=
```
1. Vérifiez l'état de votre cluster.
```
rosa describe cluster -c
```
**Note**
Si le processus de création échoue ou si le `State` champ ne passe pas à l'état « prêt » au bout de 10 minutes, consultez[Résolution des problèmes](troubleshooting-rosa.md).
Pour contacter le support Red Hat Support ou obtenir de l'aide, consultez[Obtenir de ROSA l'aide](rosa-support.md).
1. Suivez la progression de la cluster création en consultant les journaux du OpenShift programme d'installation.
```
rosa logs install -c --watch
```
## Configuration d'un fournisseur d'identité et autorisation cluster d'accès
ROSA inclut un OAuth serveur intégré. Une fois votre cluster identifiant créé, vous devez le configurer OAuth pour utiliser un fournisseur d'identité. Vous pouvez ensuite ajouter des utilisateurs à votre fournisseur d'identité configuré pour leur accorder l'accès à votre cluster. Vous pouvez accorder ces utilisateurs `cluster-admin` ou `dedicated-admin` autorisations selon les besoins.
Vous pouvez configurer différents types de fournisseurs d'identité pour votre ROSA cluster. Les types pris en charge incluent GitHub Enterprise GitHub GitLab, Google, LDAP, OpenID Connect et les fournisseurs HTPasswd d'identité.
**Important**
Le fournisseur HTPasswd d'identité est inclus uniquement pour permettre la création d'un seul utilisateur administrateur statique. HTPasswd n'est pas pris en charge en tant que fournisseur d'identité à usage général pour. ROSA
La procédure suivante configure un fournisseur d' GitHub identité à titre d'exemple. Pour obtenir des instructions sur la configuration de chacun des types de fournisseurs d'identité pris en charge, consultez [la section Configuration des fournisseurs d'identité pour AWS STS](https://access.redhat.com/documentation/en-us/red_hat_openshift_service_on_aws/4/html/install_rosa_classic_clusters/rosa-sts-config-identity-providers).
1. Accédez à [github.com](https://github.com/) et connectez-vous à votre GitHub compte.
1. Si vous n'avez aucune GitHub organisation à utiliser pour vous fournir des identités cluster, créez-en une. Pour plus d'informations, consultez [les étapes décrites dans la GitHub documentation](https://docs.github.com/en/organizations/collaborating-with-groups-in-organizations/creating-a-new-organization-from-scratch).
1. À l'aide du mode interactif de l' ROSA interface de ligne de commande, configurez un fournisseur d'identité pour votre cluster.
```
rosa create idp --cluster= --interactive
```
1. Suivez les instructions de configuration affichées dans le résultat pour restreindre cluster l'accès aux membres de votre GitHub organisation.
```
I: Interactive mode enabled.
Any optional fields can be left empty and a default will be selected.
? Type of identity provider: github
? Identity provider name: github-1
? Restrict to members of: organizations
? GitHub organizations:
? To use GitHub as an identity provider, you must first register the application:
- Open the following URL:
https://github.com/organizations//settings/applications/new?oauth_application%5Bcallback_url%5D=https%3A%2F%2Foauth-openshift.apps./.p1.openshiftapps.com%2Foauth2callback%2Fgithub-1&oauth_application%5Bname%5D=&oauth_application%5Burl%5D=https%3A%2F%2Fconsole-openshift-console.apps./.p1.openshiftapps.com
- Click on 'Register application'
...
```
1. Ouvrez l'URL dans la sortie, en la `` remplaçant par le nom de votre GitHub organisation.
1. Sur la page GitHub Web, choisissez **Enregistrer une application** pour enregistrer une nouvelle OAuth application dans votre GitHub organisation.
1. Utilisez les informations de la GitHub OAuth page pour remplir les autres invites `rosa create idp` interactives en exécutant la commande suivante. Remplacez `` et `` par les informations d'identification de votre GitHub OAuth application.
```
...
? Client ID:
? Client Secret: [? for help]
? GitHub Enterprise Hostname (optional):
? Mapping method: claim
I: Configuring IDP for cluster ''
I: Identity Provider 'github-1' has been created.
It will take up to 1 minute for this configuration to be enabled.
To add cluster administrators, see 'rosa grant user --help'.
To login into the console, open https://console-openshift-console.apps...p1.openshiftapps.com and click on github-1.
```
**Note**
L'activation de la configuration du fournisseur d'identité peut prendre environ deux minutes. Si vous avez configuré un `cluster-admin` utilisateur, vous pouvez courir `oc get pods -n openshift-authentication --watch` pour regarder les OAuth pods se redéployer avec la configuration mise à jour.
1. Vérifiez que le fournisseur d'identité est correctement configuré.
```
rosa list idps --cluster=
```
## Accorder à l'utilisateur l'accès à un cluster
Vous pouvez accorder à un utilisateur l'accès à votre cluster compte en l'ajoutant au fournisseur d'identité configuré.
La procédure suivante ajoute un utilisateur à une GitHub organisation configurée pour l'attribution d'identités au cluster.
1. Accédez à [github.com](https://github.com/) et connectez-vous à votre GitHub compte.
1. Invitez les utilisateurs qui ont besoin cluster d'accéder à votre GitHub organisation. Pour plus d'informations, consultez la section [Inviter des utilisateurs à rejoindre votre organisation](https://docs.github.com/en/organizations/managing-membership-in-your-organization/inviting-users-to-join-your-organization) dans la GitHub documentation.
## Configurer les autorisations `cluster-admin`
1. Accordez les `cluster-admin` autorisations en exécutant la commande suivante. Remplacez `` et `` par votre nom d'utilisateur et de cluster.
```
rosa grant user cluster-admin --user= --cluster=
```
1. Vérifiez que l'utilisateur est répertorié comme membre du `cluster-admins` groupe.
```
rosa list users --cluster=
```
## Configurer les autorisations `dedicated-admin`
1. Accordez les `dedicated-admin` autorisations à l'aide de la commande suivante. Remplacez `` et `` par votre nom d'utilisateur et votre cluster nom en exécutant la commande suivante.
```
rosa grant user dedicated-admin --user= --cluster=
```
1. Vérifiez que l'utilisateur est répertorié comme membre du `cluster-admins` groupe.
```
rosa list users --cluster=
```
## Accédez à un cluster via la console Red Hat Hybrid Cloud
Connectez-vous à votre compte cluster via la console Red Hat Hybrid Cloud.
1. Obtenez l'URL de la console correspondante cluster à l'aide de la commande suivante. Remplacez `` par le nom de votre cluster.
```
rosa describe cluster -c | grep Console
```
1. Accédez à l'URL de la console dans la sortie et connectez-vous.
Dans la boîte de dialogue **Se connecter avec...**, choisissez le nom du fournisseur d'identité et complétez toutes les demandes d'autorisation présentées par votre fournisseur.
## Déployer une application depuis le catalogue des développeurs
À partir de la console Red Hat Hybrid Cloud, vous pouvez déployer une application de test Developer Catalog et l'exposer à l'aide d'un itinéraire.
1. Accédez à [Red Hat Hybrid Cloud Console](https://console.redhat.com/openshift) et choisissez le cluster dans lequel vous souhaitez déployer l'application.
1. Sur la page du cluster, choisissez **Ouvrir la console**.
1. Du point de vue de **l'administrateur**, choisissez **Accueil** > **Projets** > **Créer un projet**.
1. Entrez un nom pour votre projet et ajoutez éventuellement un **nom d'affichage** et une **description**.
1. Choisissez **Create** pour créer le projet.
1. Passez au point de vue **Développeur** et choisissez **\$1Ajouter**. Assurez-vous que le projet sélectionné est bien celui qui vient d'être créé.
1. Dans la boîte de dialogue **Developer Catalog**, sélectionnez **Tous les services**.
1. Sur la page du **catalogue pour développeurs**, choisissez **Langues** > dans le **JavaScript**menu.
1. Choisissez **Node.js**, puis sélectionnez **Créer une application** pour ouvrir la page **Créer Source-to-Image une application**.
**Note**
Vous devrez peut-être choisir **Effacer tous les filtres** pour afficher l'option **Node.js**.
1. Dans la section **Git**, choisissez **Try Sample**.
1. Dans le champ **Nom**, ajoutez un nom unique.
1. Choisissez **Créer**.
**Note**
Le déploiement de la nouvelle application prend plusieurs minutes.
1. Lorsque le déploiement est terminé, choisissez l'URL de route pour l'application.
Un nouvel onglet du navigateur s'ouvre avec un message similaire au suivant.
```
Welcome to your Node.js application on OpenShift
```
1. (Facultatif) Supprimez l'application et nettoyez les ressources :
1. Du point de vue de **l'administrateur**, choisissez **Accueil** > **Projets**.
1. Ouvrez le menu d'actions de votre projet et choisissez **Supprimer le projet**.
## Révoquer `cluster-admin` les autorisations d'un utilisateur
1. Révoquez les `cluster-admin` autorisations à l'aide de la commande suivante. Remplacez `` et `` par votre nom d'utilisateur et votre cluster nom.
```
rosa revoke user cluster-admin --user= --cluster=
```
1. Vérifiez que l'utilisateur n'est pas répertorié comme membre du `cluster-admins` groupe.
```
rosa list users --cluster=
```
## Révoquer `dedicated-admin` les autorisations d'un utilisateur
1. Révoquez les `dedicated-admin` autorisations à l'aide de la commande suivante. Remplacez `` et `` par votre nom d'utilisateur et votre cluster nom.
```
rosa revoke user dedicated-admin --user= --cluster=
```
1. Vérifiez que l'utilisateur n'est pas répertorié comme membre du `dedicated-admins` groupe.
```
rosa list users --cluster=
```
## Révoquer l'accès d'un utilisateur à un cluster
Vous pouvez révoquer cluster l'accès d'un utilisateur du fournisseur d'identité en le supprimant du fournisseur d'identité configuré.
Vous pouvez configurer différents types de fournisseurs d'identité pour votre cluster. La procédure suivante révoque cluster l'accès d'un membre d'une GitHub organisation.
1. Accédez à [github.com](https://github.com/) et connectez-vous à votre GitHub compte.
1. Supprimez l'utilisateur de votre GitHub organisation. Pour plus d'informations, consultez la section [Suppression d'un membre de votre organisation](https://docs.github.com/en/organizations/managing-membership-in-your-organization/removing-a-member-from-your-organization) dans la GitHub documentation.
## Supprimer un cluster et des AWS STS ressources
Vous pouvez utiliser la ROSA CLI pour supprimer un cluster qui utilise AWS Security Token Service (AWS STS). Vous pouvez également utiliser la ROSA CLI pour supprimer les IAM rôles et le fournisseur OIDC créés par ROSA. Pour supprimer les IAM politiques créées par ROSA, vous pouvez utiliser la IAM console.
**Note**
IAM les rôles et les politiques créés par ROSA peuvent être utilisés par d'autres ROSA clusters du même compte.
1. cluster Supprimez-les et observez les journaux. Remplacez `` par le nom ou l'identifiant de votre cluster.
```
rosa delete cluster --cluster= --watch
```
**Important**
Vous devez attendre que la suppression cluster soit complète avant de supprimer les IAM rôles, les politiques et le fournisseur OIDC. Les rôles IAM du compte sont nécessaires pour supprimer les ressources créées par le programme d'installation. Les rôles IAM des opérateurs sont nécessaires pour nettoyer les ressources créées par les OpenShift opérateurs. Les opérateurs utilisent le fournisseur OIDC pour s'authentifier.
1. Supprimez le fournisseur OIDC que les cluster opérateurs utilisent pour s'authentifier en exécutant la commande suivante.
```
rosa delete oidc-provider -c --mode auto
```
1. Supprimez les rôles d'opérateur spécifiques au cluster. IAM
```
rosa delete operator-roles -c --mode auto
```
1. Supprimez les rôles IAM du compte à l'aide de la commande suivante. ``Remplacez-le par le préfixe du compte IAM roles à supprimer. Si vous avez spécifié un préfixe personnalisé lors de la création des rôles IAM du compte, spécifiez le préfixe par défaut`ManagedOpenShift`.
```
rosa delete account-roles --prefix --mode auto
```
1. Supprimez les IAM politiques créées par ROSA.
1. Connectez-vous à la [console IAM](https://console.aws.amazon.com/iamv2/home#/home).
1. Dans le menu de gauche, sous **Gestion des accès**, sélectionnez **Politiques**.
1. Sélectionnez la politique que vous souhaitez supprimer, puis sélectionnez **Actions** > **Supprimer**.
1. Entrez le nom de la politique et choisissez **Supprimer**.
1. Répétez cette étape pour supprimer chacune des politiques IAM pour le cluster.
# Créez un cluster ROSA classic à l'aide de la ROSA CLI
Les sections suivantes décrivent comment démarrer avec ROSA Classic en utilisant AWS STS la ROSA CLI. Pour savoir comment créer un cluster ROSA Classic à l'aide de Terraform, consultez [la documentation Red Hat](https://docs.openshift.com/rosa/rosa_install_access_delete_clusters/terraform/rosa-classic-creating-a-cluster-quickly-terraform.html). Pour en savoir plus sur le fournisseur Terraform pour la création de ROSA clusters, consultez [la documentation Terraform](https://registry.terraform.io/providers/terraform-redhat/rhcs/latest/docs).
La ROSA CLI utilise le `auto` mode ou le `manual` mode pour créer les IAM ressources nécessaires au provisionnement d'un ROSA cluster. `auto`le mode crée immédiatement les IAM rôles et les politiques requis ainsi qu'un fournisseur OpenID Connect (OIDC). `manual`le mode affiche les AWS CLI commandes nécessaires à la création des IAM ressources. En utilisant `manual` le mode, vous pouvez consulter les AWS CLI commandes générées avant de les exécuter manuellement. Avec `manual` le mode, vous pouvez également transmettre les commandes à un autre administrateur ou à un autre groupe de votre organisation afin qu'il puisse créer les ressources.
Pour plus d'options de démarrage, consultez[Commencez avec ROSA](getting-started.md).
**Topics**
+ [Conditions préalables](#getting-started-classic-cli-prereqs)
+ [Créez un cluster ROSA classic à l'aide de la ROSA CLI et AWS STS](#create-rosa-classic-cluster-cli-sts)
+ [Configuration d'un fournisseur d'identité et autorisation cluster d'accès](#getting-started-classic-cli-configure-oidc)
+ [Accorder à l'utilisateur l'accès à un cluster](#getting-started-classic-cli-grant-user-access)
+ [Configurer les autorisations `cluster-admin`](#configure-cluster-admin-classic-cli)
+ [Configurer les autorisations `dedicated-admin`](#configure-dedicated-admin-classic-cli)
+ [Accédez à un cluster via la console Red Hat Hybrid Cloud](#console-access-classic-cli)
+ [Déployer une application depuis le catalogue des développeurs](#deploy-app-classic-cli)
+ [Révoquer `cluster-admin` les autorisations d'un utilisateur](#revoke-cluster-admin-classic-cli)
+ [Révoquer `dedicated-admin` les autorisations d'un utilisateur](#revoke-dedicated-admin-classic-cli)
+ [Révoquer l'accès d'un utilisateur à un cluster](#revoke-user-classic-cli)
+ [Supprimer un cluster et des AWS STS ressources](#delete-cluster-classic-cli)
## Conditions préalables
Effectuez les actions préalables répertoriées dans[Configurer pour utiliser ROSA](set-up.md).
## Créez un cluster ROSA classic à l'aide de la ROSA CLI et AWS STS
Vous pouvez créer un classique ROSA à cluster l'aide de la ROSA CLI et AWS STS.
1. Créez les rôles et politiques de IAM compte requis à l'aide de `--mode auto` ou`--mode manual`.
+
```
rosa create account-roles --classic --mode auto
```
+
```
rosa create account-roles --classic --mode manual
```
**Note**
Si votre jeton d'accès hors ligne a expiré, la ROSA CLI affiche un message d'erreur indiquant que votre jeton d'autorisation doit être mis à jour. Pour connaître les étapes de résolution des problèmes, voir[Résoudre les problèmes liés aux jetons d'accès hors ligne expirés de la ROSA CLI](troubleshooting-rosa.md#rosa-cli-expired-token).
1. Créez un cluster en utilisant `--mode auto` ou`--mode manual`. `auto`le mode permet de créer un cluster plus rapidement. `manual`le mode vous invite à définir des paramètres personnalisés pour votre cluster.
+
```
rosa create cluster --cluster-name --sts --mode auto
```
**Note**
Lorsque vous le spécifiez`--mode auto`, la `rosa create cluster` commande crée automatiquement les IAM rôles d'opérateur spécifiques au cluster et le fournisseur OIDC. Les opérateurs utilisent le fournisseur OIDC pour s'authentifier.
**Note**
Lorsque vous utilisez les `--mode auto` valeurs par défaut, la dernière OpenShift version stable est installée.
+
```
rosa create cluster --cluster-name --sts --mode manual
```
**Important**
Si vous activez le chiffrement etcd en `manual` mode, vous encourez une surcharge de performance d'environ 20 %. La surcharge est due à l'introduction de cette deuxième couche de chiffrement, en plus du chiffrement Amazon EBS par défaut qui chiffre les volumes etcd.
**Note**
Après avoir exécuté le `manual` mode pour créer le cluster, vous devez créer manuellement les rôles IAM des opérateurs spécifiques au cluster et le fournisseur OpenID Connect que les opérateurs du cluster utilisent pour s'authentifier.
1. Vérifiez l'état de votre cluster.
```
rosa describe cluster -c
```
**Note**
Si le processus de provisionnement échoue ou si le `State` champ ne passe pas à l'état « prêt » après 40 minutes, consultez[Résolution des problèmes](troubleshooting-rosa.md). Pour contacter le support Red Hat Support ou obtenir de l'aide, consultez[Obtenir de ROSA l'aide](rosa-support.md).
1. Suivez la progression de la cluster création en consultant les journaux du OpenShift programme d'installation.
```
rosa logs install -c --watch
```
## Configuration d'un fournisseur d'identité et autorisation cluster d'accès
ROSA inclut un OAuth serveur intégré. Une fois votre cluster identifiant créé, vous devez le configurer OAuth pour utiliser un fournisseur d'identité. Vous pouvez ensuite ajouter des utilisateurs à votre fournisseur d'identité configuré pour leur accorder l'accès à votre cluster. Vous pouvez accorder ces utilisateurs `cluster-admin` ou `dedicated-admin` autorisations selon les besoins.
Vous pouvez configurer différents types de fournisseurs d'identité pour votre ROSA cluster. Les types pris en charge incluent GitHub Enterprise GitHub GitLab, Google, LDAP, OpenID Connect et les fournisseurs HTPasswd d'identité.
**Important**
Le fournisseur HTPasswd d'identité est inclus uniquement pour permettre la création d'un seul utilisateur administrateur statique. HTPasswd n'est pas pris en charge en tant que fournisseur d'identité à usage général pour. ROSA
La procédure suivante configure un fournisseur d' GitHub identité à titre d'exemple. Pour obtenir des instructions sur la configuration de chacun des types de fournisseurs d'identité pris en charge, consultez [la section Configuration des fournisseurs d'identité pour AWS STS](https://access.redhat.com/documentation/en-us/red_hat_openshift_service_on_aws/4/html/install_rosa_classic_clusters/rosa-sts-config-identity-providers).
1. Accédez à [github.com](https://github.com/) et connectez-vous à votre GitHub compte.
1. Si vous n'avez aucune GitHub organisation à utiliser pour vous fournir des identités cluster, créez-en une. Pour plus d'informations, consultez [les étapes décrites dans la GitHub documentation](https://docs.github.com/en/organizations/collaborating-with-groups-in-organizations/creating-a-new-organization-from-scratch).
1. À l'aide du mode interactif de l' ROSA interface de ligne de commande, configurez un fournisseur d'identité pour votre cluster.
```
rosa create idp --cluster= --interactive
```
1. Suivez les instructions de configuration affichées dans le résultat pour restreindre cluster l'accès aux membres de votre GitHub organisation.
```
I: Interactive mode enabled.
Any optional fields can be left empty and a default will be selected.
? Type of identity provider: github
? Identity provider name: github-1
? Restrict to members of: organizations
? GitHub organizations:
? To use GitHub as an identity provider, you must first register the application:
- Open the following URL:
https://github.com/organizations//settings/applications/new?oauth_application%5Bcallback_url%5D=https%3A%2F%2Foauth-openshift.apps./.p1.openshiftapps.com%2Foauth2callback%2Fgithub-1&oauth_application%5Bname%5D=&oauth_application%5Burl%5D=https%3A%2F%2Fconsole-openshift-console.apps./.p1.openshiftapps.com
- Click on 'Register application'
...
```
1. Ouvrez l'URL dans la sortie, en la `` remplaçant par le nom de votre GitHub organisation.
1. Sur la page GitHub Web, choisissez **Enregistrer une application** pour enregistrer une nouvelle OAuth application dans votre GitHub organisation.
1. Utilisez les informations de la GitHub OAuth page pour remplir les autres invites `rosa create idp` interactives en exécutant la commande suivante. Remplacez `` et `` par les informations d'identification de votre GitHub OAuth application.
```
...
? Client ID:
? Client Secret: [? for help]
? GitHub Enterprise Hostname (optional):
? Mapping method: claim
I: Configuring IDP for cluster ''
I: Identity Provider 'github-1' has been created.
It will take up to 1 minute for this configuration to be enabled.
To add cluster administrators, see 'rosa grant user --help'.
To login into the console, open https://console-openshift-console.apps...p1.openshiftapps.com and click on github-1.
```
**Note**
L'activation de la configuration du fournisseur d'identité peut prendre environ deux minutes. Si vous avez configuré un `cluster-admin` utilisateur, vous pouvez courir `oc get pods -n openshift-authentication --watch` pour regarder les OAuth pods se redéployer avec la configuration mise à jour.
1. Vérifiez que le fournisseur d'identité est correctement configuré.
```
rosa list idps --cluster=
```
## Accorder à l'utilisateur l'accès à un cluster
Vous pouvez accorder à un utilisateur l'accès à votre cluster compte en l'ajoutant au fournisseur d'identité configuré.
La procédure suivante ajoute un utilisateur à une GitHub organisation configurée pour l'attribution d'identités au cluster.
1. Accédez à [github.com](https://github.com/) et connectez-vous à votre GitHub compte.
1. Invitez les utilisateurs qui ont besoin cluster d'accéder à votre GitHub organisation. Pour plus d'informations, consultez la section [Inviter des utilisateurs à rejoindre votre organisation](https://docs.github.com/en/organizations/managing-membership-in-your-organization/inviting-users-to-join-your-organization) dans la GitHub documentation.
## Configurer les autorisations `cluster-admin`
1. Accordez les `cluster-admin` autorisations en exécutant la commande suivante. Remplacez `` et `` par votre nom d'utilisateur et de cluster.
```
rosa grant user cluster-admin --user= --cluster=
```
1. Vérifiez que l'utilisateur est répertorié comme membre du `cluster-admins` groupe.
```
rosa list users --cluster=
```
## Configurer les autorisations `dedicated-admin`
1. Accordez les `dedicated-admin` autorisations à l'aide de la commande suivante. Remplacez `` et `` par votre nom d'utilisateur et votre cluster nom en exécutant la commande suivante.
```
rosa grant user dedicated-admin --user= --cluster=
```
1. Vérifiez que l'utilisateur est répertorié comme membre du `cluster-admins` groupe.
```
rosa list users --cluster=
```
## Accédez à un cluster via la console Red Hat Hybrid Cloud
Après avoir créé un utilisateur cluster administrateur ou ajouté un utilisateur à votre fournisseur d'identité configuré, vous pouvez vous connecter à votre compte cluster via la Red Hat Hybrid Cloud Console.
1. Obtenez l'URL de la console correspondante cluster à l'aide de la commande suivante. Remplacez `` par le nom de votre cluster.
```
rosa describe cluster -c | grep Console
```
1. Accédez à l'URL de la console dans la sortie et connectez-vous.
+ Si vous avez créé un `cluster-admin` utilisateur, connectez-vous à l'aide des informations d'identification fournies.
+ Si vous avez configuré un fournisseur d'identité pour vous cluster, choisissez le nom du fournisseur d'identité dans la boîte de dialogue **Se connecter avec...** et répondez à toutes les demandes d'autorisation présentées par votre fournisseur.
## Déployer une application depuis le catalogue des développeurs
À partir de la console Red Hat Hybrid Cloud, vous pouvez déployer une application de test Developer Catalog et l'exposer à l'aide d'un itinéraire.
1. Accédez à [Red Hat Hybrid Cloud Console](https://console.redhat.com/openshift) et choisissez le cluster dans lequel vous souhaitez déployer l'application.
1. Sur la page du cluster, choisissez **Open console**.
1. Du point de vue de **l'administrateur**, choisissez **Accueil** > **Projets** > **Créer un projet**.
1. Entrez un nom pour votre projet et ajoutez éventuellement un **nom d'affichage** et une **description**.
1. Choisissez **Create** pour créer le projet.
1. Passez au point de vue **Développeur** et choisissez **\$1Ajouter**. Assurez-vous que le projet sélectionné est bien celui qui vient d'être créé.
1. Dans la boîte de dialogue **Developer Catalog**, sélectionnez **Tous les services**.
1. Sur la page du **catalogue pour développeurs**, choisissez **Langues** > dans le **JavaScript**menu.
1. Choisissez **Node.js**, puis sélectionnez **Créer une application** pour ouvrir la page **Créer Source-to-Image une application**.
**Note**
Vous devrez peut-être choisir **Effacer tous les filtres** pour afficher l'option **Node.js**.
1. Dans la section **Git**, choisissez **Try Sample**.
1. Dans le champ **Nom**, ajoutez un nom unique.
1. Choisissez **Créer**.
**Note**
Le déploiement de la nouvelle application prend plusieurs minutes.
1. Lorsque le déploiement est terminé, choisissez l'URL de route pour l'application.
Un nouvel onglet du navigateur s'ouvre avec un message similaire au suivant.
```
Welcome to your Node.js application on OpenShift
```
1. (Facultatif) Supprimez l'application et nettoyez les ressources :
1. Du point de vue de **l'administrateur**, choisissez **Accueil** > **Projets**.
1. Ouvrez le menu d'actions de votre projet et choisissez **Supprimer le projet**.
## Révoquer `cluster-admin` les autorisations d'un utilisateur
1. Révoquez les `cluster-admin` autorisations à l'aide de la commande suivante. Remplacez `` et `` par votre nom d'utilisateur et votre cluster nom.
```
rosa revoke user cluster-admin --user= --cluster=
```
1. Vérifiez que l'utilisateur n'est pas répertorié comme membre du `cluster-admins` groupe.
```
rosa list users --cluster=
```
## Révoquer `dedicated-admin` les autorisations d'un utilisateur
1. Révoquez les `dedicated-admin` autorisations à l'aide de la commande suivante. Remplacez `` et `` par votre nom d'utilisateur et votre cluster nom.
```
rosa revoke user dedicated-admin --user= --cluster=
```
1. Vérifiez que l'utilisateur n'est pas répertorié comme membre du `dedicated-admins` groupe.
```
rosa list users --cluster=
```
## Révoquer l'accès d'un utilisateur à un cluster
Vous pouvez révoquer cluster l'accès d'un utilisateur du fournisseur d'identité en le supprimant du fournisseur d'identité configuré.
Vous pouvez configurer différents types de fournisseurs d'identité pour votre cluster. La procédure suivante révoque cluster l'accès d'un membre d'une GitHub organisation.
1. Accédez à [github.com](https://github.com/) et connectez-vous à votre GitHub compte.
1. Supprimez l'utilisateur de votre GitHub organisation. Pour plus d'informations, consultez la section [Suppression d'un membre de votre organisation](https://docs.github.com/en/organizations/managing-membership-in-your-organization/removing-a-member-from-your-organization) dans la GitHub documentation.
## Supprimer un cluster et des AWS STS ressources
Vous pouvez utiliser la ROSA CLI pour supprimer un cluster qui utilise AWS Security Token Service (AWS STS). Vous pouvez également utiliser la ROSA CLI pour supprimer les IAM rôles et le fournisseur OIDC créés par ROSA. Pour supprimer les IAM politiques créées par ROSA, vous pouvez utiliser la IAM console.
**Important**
IAM les rôles et les politiques créés par ROSA peuvent être utilisés par d'autres ROSA clusters du même compte.
1. cluster Supprimez-les et observez les journaux. Remplacez `` par le nom ou l'identifiant de votre cluster.
```
rosa delete cluster --cluster= --watch
```
**Important**
Vous devez attendre que la suppression cluster soit complète avant de supprimer les IAM rôles, les politiques et le fournisseur OIDC. Les rôles IAM du compte sont nécessaires pour supprimer les ressources créées par le programme d'installation. Les rôles IAM des opérateurs sont nécessaires pour nettoyer les ressources créées par les OpenShift opérateurs. Les opérateurs utilisent le fournisseur OIDC pour s'authentifier.
1. Supprimez le fournisseur OIDC que les cluster opérateurs utilisent pour s'authentifier en exécutant la commande suivante.
```
rosa delete oidc-provider -c --mode auto
```
1. Supprimez les rôles d'opérateur spécifiques au cluster. IAM
```
rosa delete operator-roles -c --mode auto
```
1. Supprimez les rôles IAM du compte à l'aide de la commande suivante. ``Remplacez-le par le préfixe du compte IAM roles à supprimer. Si vous avez spécifié un préfixe personnalisé lors de la création des rôles IAM du compte, spécifiez le préfixe par défaut`ManagedOpenShift`.
```
rosa delete account-roles --prefix --mode auto
```
1. Supprimez les IAM politiques créées par ROSA.
1. Connectez-vous à la [console IAM](https://console.aws.amazon.com/iamv2/home#/home).
1. Dans le menu de gauche, sous **Gestion des accès**, sélectionnez **Politiques**.
1. Sélectionnez la politique que vous souhaitez supprimer, puis sélectionnez **Actions** > **Supprimer**.
1. Entrez le nom de la politique et choisissez **Supprimer**.
1. Répétez cette étape pour supprimer chacune des politiques IAM pour le cluster.
# Créez un cluster ROSA classique qui utilise AWS PrivateLink
Les clusters ROSA Classic peuvent être déployés de différentes manières : en public, en privé ou en mode privé avec AWS PrivateLink. Pour plus d'informations sur ROSA classic, voir[ROSA architecture](rosa-architecture-models.md). Pour les cluster configurations publiques et privées, ils OpenShift cluster ont accès à Internet et la confidentialité est définie sur les charges de travail des applications au niveau de la couche application.
Si vous souhaitez que les charges de travail cluster et les charges de travail des applications soient privées, vous pouvez les configurer AWS PrivateLink avec ROSA classic. AWS PrivateLink est une technologie hautement disponible et évolutive qui permet ROSA de créer une connexion privée entre le ROSA service et les ressources du cluster dans le compte AWS client. L'équipe d' AWS PrivateLink ingénierie de fiabilité des sites (SRE) de Red Hat peut ainsi accéder au cluster à des fins de support et de correction en utilisant un sous-réseau privé connecté au point de terminaison du AWS PrivateLink cluster.
Pour plus d'informations AWS PrivateLink, voir [Qu'est-ce que c'est AWS PrivateLink ?](https://docs.aws.amazon.com/vpc/latest/privatelink/what-is-privatelink.html)
**Topics**
+ [Conditions préalables](#getting-started-classic-private-link-prereqs)
+ [Création d'une Amazon VPC architecture](#create-vpc-classic-privatelink)
+ [Créez un cluster ROSA classic à l'aide de la ROSA CLI et AWS PrivateLink](#create-classic-cluster-cli-privatelink)
+ [Configurer le transfert AWS PrivateLink DNS](#configure-dns-forwarding-classic-cli-privatelink)
+ [Configuration d'un fournisseur d'identité et autorisation cluster d'accès](#configure-oidc-classic-cli-privatelink)
+ [Accorder à l'utilisateur l'accès à un cluster](#grant-user-access-classic-cli-privatelink)
+ [Configurer les autorisations `cluster-admin`](#configure-cluster-admin-classic-privatelink)
+ [Configurer les autorisations `dedicated-admin`](#configure-dedicated-admin-classic-privatelink)
+ [Accédez à un cluster via la console Red Hat Hybrid Cloud](#console-access-classic-cli-privatelink)
+ [Déployer une application depuis le catalogue des développeurs](#deploy-app-classic-cli-privatelink)
+ [Révoquer `cluster-admin` les autorisations d'un utilisateur](#revoke-cluster-admin-classic-privatelink)
+ [Révoquer `dedicated-admin` les autorisations d'un utilisateur](#revoke-dedicated-admin-classic-privatelink)
+ [Révoquer l'accès d'un utilisateur à un cluster](#revoke-user-classic-privatelink)
+ [Supprimer un cluster et des AWS STS ressources](#delete-cluster-classic-cli-privatelink)
## Conditions préalables
Effectuez les actions préalables répertoriées dans[Configurer pour utiliser ROSA](set-up.md).
## Création d'une Amazon VPC architecture
La procédure suivante crée une Amazon VPC architecture qui peut être utilisée pour héberger un cluster. Toutes les cluster ressources sont hébergées dans le sous-réseau privé. Le sous-réseau public achemine le trafic sortant du sous-réseau privé via une passerelle NAT vers l'Internet public. Cet exemple utilise le bloc CIDR `10.0.0.0/16` pour le Amazon VPC. Cependant, vous pouvez choisir un autre bloc CIDR. Pour de plus amples informations, veuillez consulter [Dimensionnement d’un VPC](https://docs.aws.amazon.com/vpc/latest/userguide/configure-your-vpc.html#vpc-sizing).
**Important**
Si Amazon VPC les exigences ne sont pas satisfaites, la création du cluster échoue.
**Example**
1. Ouvrez la [Amazon VPC console](https://console.aws.amazon.com/vpc).
1. Sur le tableau de bord VPC, choisissez **Create VPC (Créer un VPC)**.
1. Sous **Ressources à créer**, choisissez **VPC et plus encore**.
1. Maintenez l'option **Génération automatique de balise de nom** sélectionnée pour créer des balises de nom pour les ressources VPC, ou désactivez-la pour fournir vos propres balises de nom pour les ressources VPC.
1. Pour le **bloc IPv4 CIDR**, entrez une plage d' IPv4 adresses pour le VPC. Un VPC doit avoir une plage d' IPv4 adresses.
1. (Facultatif) Pour prendre en charge IPv6 le trafic, choisissez le bloc **IPv6 CIDR, le bloc CIDR fourni par Amazon IPv6 **.
1. Laissez la **location telle `Default` quelle**.
1. Pour **Nombre de zones de disponibilité (AZs)**, choisissez le nombre dont vous avez besoin. Pour les déploiements multi-AZ, ROSA trois zones de disponibilité sont nécessaires. Pour choisir le AZs pour vos sous-réseaux, développez **Personnaliser AZs**.
**Note**
Certains types d' ROSA instances ne sont disponibles que dans certaines zones de disponibilité. Vous pouvez utiliser la `rosa list instance-types` commande ROSA CLI pour répertorier tous les types d' ROSA instances disponibles. Pour vérifier si un type d'instance est disponible pour une zone de disponibilité donnée, utilisez la AWS CLI commande`aws ec2 describe-instance-type-offerings --location-type availability-zone --filters Name=location,Values= --region --output text | egrep ""`.
1. Pour configurer vos sous-réseaux, choisissez des valeurs pour **Nombre de sous-réseaux publics** et **Nombre de sous-réseaux privés**. Pour choisir les plages d'adresses IP pour vos sous-réseaux, développez **Personnaliser les blocs CIDR des sous-réseaux**.
**Note**
ROSA exige que les clients configurent au moins un sous-réseau privé par zone de disponibilité utilisée pour créer des clusters.
1. Pour accorder aux ressources du sous-réseau privé l'accès à l'Internet public via IPv4, pour les **passerelles NAT**, choisissez le nombre de AZs passerelles NAT à créer. En production, nous vous recommandons de déployer une passerelle NAT dans chaque zone de disponibilité avec des ressources nécessitant un accès à l'Internet public.
1. (Facultatif) Si vous devez accéder Amazon S3 directement depuis votre VPC, choisissez les points de **terminaison du VPC**, S3 Gateway.
1. Laissez les options DNS par défaut sélectionnées. ROSA nécessite la prise en charge du nom d'hôte DNS sur le VPC.
1. Sélectionnez **Create VPC** (Créer un VPC).
1. Créez un VPC avec un bloc d'adresse CIDR `10.0.0.0/16`.
```
aws ec2 create-vpc \
--cidr-block 10.0.0.0/16 \
--query Vpc.VpcId \
--output text
```
La commande précédente renvoie l'ID du VPC. Voici un exemple de sortie.
```
vpc-1234567890abcdef0
```
1. Stockez l'ID du VPC dans une variable d'environnement.
```
export VPC_ID=vpc-1234567890abcdef0
```
1. Créez une `Name` balise pour le VPC à l'aide de la variable d'`VPC_ID`environnement.
```
aws ec2 create-tags --resources $VPC_ID --tags Key=Name,Value=MyVPC
```
1. Activez la prise en charge des noms d'hôte DNS sur le VPC.
```
aws ec2 modify-vpc-attribute \
--vpc-id $VPC_ID \
--enable-dns-hostnames
```
1. Créez un sous-réseau public et privé dans le VPC, en spécifiant les zones de disponibilité dans lesquelles les ressources doivent être créées.
**Important**
ROSA exige que les clients configurent au moins un sous-réseau privé par zone de disponibilité utilisée pour créer des clusters. Pour les déploiements multi-AZ, trois zones de disponibilité sont requises. Si ces exigences ne sont pas satisfaites, la création du cluster échoue.
**Note**
Certains types d' ROSA instances ne sont disponibles que dans certaines zones de disponibilité. Vous pouvez utiliser la `rosa list instance-types` commande ROSA CLI pour répertorier tous les types d' ROSA instances disponibles. Pour vérifier si un type d'instance est disponible pour une zone de disponibilité donnée, utilisez la AWS CLI commande`aws ec2 describe-instance-type-offerings --location-type availability-zone --filters Name=location,Values= --region --output text | egrep ""`.
```
aws ec2 create-subnet \
--vpc-id $VPC_ID \
--cidr-block 10.0.1.0/24 \
--availability-zone us-east-1a \
--query Subnet.SubnetId \
--output text
aws ec2 create-subnet \
--vpc-id $VPC_ID \
--cidr-block 10.0.0.0/24 \
--availability-zone us-east-1a \
--query Subnet.SubnetId \
--output text
```
1. Stockez les sous-réseaux public et privé IDs dans des variables d'environnement.
```
export PUBLIC_SUB=subnet-1234567890abcdef0
export PRIVATE_SUB=subnet-0987654321fedcba0
```
1. Créez une passerelle Internet et une table de routage pour le trafic sortant. Créez une table de routage et une adresse IP élastique pour le trafic privé.
```
aws ec2 create-internet-gateway \
--query InternetGateway.InternetGatewayId \
--output text
aws ec2 create-route-table \
--vpc-id $VPC_ID \
--query RouteTable.RouteTableId \
--output text
aws ec2 allocate-address \
--domain vpc \
--query AllocationId \
--output text
aws ec2 create-route-table \
--vpc-id $VPC_ID \
--query RouteTable.RouteTableId \
--output text
```
1. Stockez les IDs dans les variables d'environnement.
```
export IGW=igw-1234567890abcdef0
export PUBLIC_RT=rtb-0987654321fedcba0
export EIP=eipalloc-0be6ecac95EXAMPLE
export PRIVATE_RT=rtb-1234567890abcdef0
```
1. Connectez la passerelle Internet au VPC.
```
aws ec2 attach-internet-gateway \
--vpc-id $VPC_ID \
--internet-gateway-id $IGW
```
1. Associez la table de routage publique au sous-réseau public et configurez le trafic pour qu'il soit acheminé vers la passerelle Internet.
```
aws ec2 associate-route-table \
--subnet-id $PUBLIC_SUB \
--route-table-id $PUBLIC_RT
aws ec2 create-route \
--route-table-id $PUBLIC_RT \
--destination-cidr-block 0.0.0.0/0 \
--gateway-id $IGW
```
1. Créez la passerelle NAT et associez-la à l'adresse IP élastique pour activer le trafic vers le sous-réseau privé.
```
aws ec2 create-nat-gateway \
--subnet-id $PUBLIC_SUB \
--allocation-id $EIP \
--query NatGateway.NatGatewayId \
--output text
```
1. Associez la table de routage privée au sous-réseau privé et configurez le trafic pour qu'il soit acheminé vers la passerelle NAT.
```
aws ec2 associate-route-table \
--subnet-id $PRIVATE_SUB \
--route-table-id $PRIVATE_RT
aws ec2 create-route \
--route-table-id $PRIVATE_RT \
--destination-cidr-block 0.0.0.0/0 \
--gateway-id $NATGW
```
1. (Facultatif) Pour les déploiements multi-AZ, répétez les étapes ci-dessus pour configurer deux autres zones de disponibilité avec des sous-réseaux publics et privés.
## Créez un cluster ROSA classic à l'aide de la ROSA CLI et AWS PrivateLink
Vous pouvez utiliser la ROSA CLI AWS PrivateLink pour créer une zone cluster de disponibilité unique (mono-AZ) ou plusieurs zones de disponibilité (multi-AZ). Dans les deux cas, la valeur CIDR de votre machine doit correspondre à la valeur CIDR de votre VPC.
La procédure suivante utilise la `rosa create cluster` commande pour créer un ROSA classic cluster. Pour créer un Multi-AZ cluster, spécifiez-le `--multi-az` dans la commande, puis sélectionnez le sous-réseau privé IDs que vous souhaitez utiliser lorsque vous y êtes invité.
**Note**
Si vous utilisez un pare-feu, vous devez le configurer de manière à ROSA pouvoir accéder aux sites dont il a besoin pour fonctionner.
Pour plus d'informations, consultez la section [Exigences relatives à l'utilisation des AWS PrivateLink clusters](https://docs.redhat.com/en/documentation/red_hat_openshift_service_on_aws/4/html/install_rosa_classic_clusters/rosa-aws-privatelink-creating-cluster#osd-aws-privatelink-required-resources_rosa-aws-privatelink-creating-cluster) dans la documentation Red Hat.
1. Créez les rôles et politiques de IAM compte requis à l'aide de `--mode auto` ou`--mode manual`.
+
```
rosa create account-roles --classic --mode auto
```
+
```
rosa create account-roles --classic --mode manual
```
**Note**
Si votre jeton d'accès hors ligne a expiré, la ROSA CLI affiche un message d'erreur indiquant que votre jeton d'autorisation doit être mis à jour. Pour connaître les étapes à suivre pour résoudre les problèmes, consultez[Résoudre les problèmes liés aux jetons d'accès hors ligne expirés de la ROSA CLI](troubleshooting-rosa.md#rosa-cli-expired-token).
1. Créez un cluster en exécutant l'une des commandes suivantes.
+ Mono-AZ
```
rosa create cluster --private-link --cluster-name= --machine-cidr=10.0.0.0/16 --subnet-ids=
```
+ Multi-AZ
```
rosa create cluster --private-link --multi-az --cluster-name= --machine-cidr=10.0.0.0/16
```
**Note**
Pour créer un cluster qui utilise des informations d'identification de courte durée AWS PrivateLink with AWS Security Token Service (AWS STS), ajoutez `--sts --mode auto` ou `--sts --mode manual` à la fin de la `rosa create cluster` commande.
1. Créez les IAM rôles d' cluster opérateur en suivant les instructions interactives.
```
rosa create operator-roles --interactive -c
```
1. Créez le fournisseur OpenID Connect (OIDC) que les cluster opérateurs utilisent pour s'authentifier.
```
rosa create oidc-provider --interactive -c
```
1. Vérifiez l'état de votre cluster.
```
rosa describe cluster -c
```
**Note**
L'affichage du `ready` statut dans le cluster `State` champ peut prendre jusqu'à 40 minutes. Si le provisionnement échoue ou ne s'affiche pas au `ready` bout de 40 minutes, consultez[Résolution des problèmes](troubleshooting-rosa.md). Pour contacter le support Red Hat Support ou obtenir de l'aide, consultez[Obtenir de ROSA l'aide](rosa-support.md).
1. Suivez la progression de la cluster création en consultant les journaux du OpenShift programme d'installation.
```
rosa logs install -c --watch
```
## Configurer le transfert AWS PrivateLink DNS
Les clusters utilisés AWS PrivateLink créent une zone hébergée publique et une zone hébergée privée dans Route 53. Les enregistrements de la zone hébergée Route 53 privée ne peuvent être résolus que depuis le VPC auquel ils sont assignés.
La validation Let's Encrypt DNS-01 nécessite une zone publique afin que des certificats valides et approuvés par le public puissent être émis pour le domaine. Les enregistrements de validation sont supprimés une fois la validation de Let's Encrypt terminée. La zone est toujours requise pour la délivrance et le renouvellement de ces certificats, qui sont généralement requis tous les 60 jours. Bien que ces zones semblent généralement vides, une zone publique joue un rôle essentiel dans le processus de validation.
Pour plus d'informations sur les zones hébergées AWS privées, consultez la section [Utilisation des zones privées](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/hosted-zones-private.html). Pour plus d'informations sur les zones hébergées publiques, consultez la section [Utilisation des zones hébergées publiques](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/AboutHZWorkingWith.html).
### Configuration d'un point de Route 53 Resolver terminaison entrant
1. Pour autoriser des enregistrements tels que `api.` et pour les `*.apps.` résoudre en dehors du VPC, [configurez un point de terminaison Route 53 Resolver entrant](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/resolver-forwarding-inbound-queries.html#resolver-forwarding-inbound-queries-configuring).
**Note**
Lorsque vous configurez un point de terminaison entrant, vous devez spécifier au moins deux adresses IP à des fins de redondance. Nous vous recommandons de spécifier des adresses IP dans au moins deux zones de disponibilité. Si vous le souhaitez, vous pouvez spécifier des adresses IP supplémentaires dans ces zones de disponibilité ou dans d’autres.
1. Lorsque vous configurez le point de terminaison entrant, sélectionnez le VPC et les sous-réseaux privés utilisés lors de la création du cluster.
### Configurer le transfert DNS pour le cluster
Une fois le point de terminaison Route 53 Resolver interne associé et opérationnel, configurez le transfert DNS afin que les requêtes DNS puissent être traitées par les serveurs désignés sur votre réseau.
1. Configurez votre réseau d'entreprise pour transférer les requêtes DNS vers les adresses IP du domaine de premier niveau, telles que`drow-pl-01.htno.p1.openshiftapps.com`.
1. [Si vous transférez des requêtes DNS d'un VPC à un autre VPC, suivez les instructions de la section Gestion des règles de transfert.](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/resolver-rules-managing.html)
1. Si vous configurez le serveur DNS de votre réseau distant, consultez la documentation de votre serveur DNS spécifique pour configurer le transfert DNS sélectif pour le domaine de cluster installé.
## Configuration d'un fournisseur d'identité et autorisation cluster d'accès
ROSA inclut un OAuth serveur intégré. Une fois votre ROSA cluster identifiant créé, vous devez le configurer OAuth pour utiliser un fournisseur d'identité. Vous pouvez ensuite ajouter des utilisateurs à votre fournisseur d'identité configuré pour leur accorder l'accès à votre cluster. Vous pouvez accorder ces utilisateurs `cluster-admin` ou `dedicated-admin` autorisations selon les besoins.
Vous pouvez configurer différents types de fournisseurs d'identité pour votre cluster. Les types pris en charge incluent GitHub Enterprise GitHub, Google GitLab, LDAP, OpenID Connect et les fournisseurs HTPasswd d'identité.
**Important**
Le fournisseur HTPasswd d'identité est inclus uniquement pour permettre la création d'un seul utilisateur administrateur statique. HTPasswd n'est pas pris en charge en tant que fournisseur d'identité à usage général pour. ROSA
La procédure suivante configure un fournisseur d' GitHub identité à titre d'exemple. Pour obtenir des instructions sur la configuration de chacun des types de fournisseurs d'identité pris en charge, consultez [la section Configuration des fournisseurs d'identité pour AWS STS](https://access.redhat.com/documentation/en-us/red_hat_openshift_service_on_aws/4/html/install_rosa_classic_clusters/rosa-sts-config-identity-providers).
1. Accédez à [github.com](https://github.com/) et connectez-vous à votre GitHub compte.
1. Si vous n'avez aucune GitHub organisation à utiliser pour vous fournir des identités ROSA cluster, créez-en une. Pour plus d'informations, consultez [les étapes décrites dans la GitHub documentation](https://docs.github.com/en/organizations/collaborating-with-groups-in-organizations/creating-a-new-organization-from-scratch).
1. À l'aide du mode interactif de l' ROSA interface de ligne de commande, configurez un fournisseur d'identité pour votre cluster en exécutant la commande suivante.
```
rosa create idp --cluster= --interactive
```
1. Suivez les instructions de configuration affichées dans le résultat pour restreindre cluster l'accès aux membres de votre GitHub organisation.
```
I: Interactive mode enabled.
Any optional fields can be left empty and a default will be selected.
? Type of identity provider: github
? Identity provider name: github-1
? Restrict to members of: organizations
? GitHub organizations:
? To use GitHub as an identity provider, you must first register the application:
- Open the following URL:
https://github.com/organizations//settings/applications/new?oauth_application%5Bcallback_url%5D=https%3A%2F%2Foauth-openshift.apps./.p1.openshiftapps.com%2Foauth2callback%2Fgithub-1&oauth_application%5Bname%5D=&oauth_application%5Burl%5D=https%3A%2F%2Fconsole-openshift-console.apps./.p1.openshiftapps.com
- Click on 'Register application'
...
```
1. Ouvrez l'URL dans la sortie, en la `` remplaçant par le nom de votre GitHub organisation.
1. Sur la page GitHub Web, choisissez **Enregistrer une application** pour enregistrer une nouvelle OAuth application dans votre GitHub organisation.
1. Utilisez les informations de la GitHub OAuth page pour remplir les autres invites `rosa create idp` interactives, en remplaçant `` et `` par les informations d'identification de votre GitHub OAuth application.
```
...
? Client ID:
? Client Secret: [? for help]
? GitHub Enterprise Hostname (optional):
? Mapping method: claim
I: Configuring IDP for cluster ''
I: Identity Provider 'github-1' has been created.
It will take up to 1 minute for this configuration to be enabled.
To add cluster administrators, see 'rosa grant user --help'.
To login into the console, open https://console-openshift-console.apps...p1.openshiftapps.com and click on github-1.
```
**Note**
L'activation de la configuration du fournisseur d'identité peut prendre environ deux minutes. Si vous avez configuré un `cluster-admin` utilisateur, vous pouvez exécuter la `oc get pods -n openshift-authentication --watch` commande pour voir les OAuth pods se redéployer avec la configuration mise à jour.
1. Vérifiez que le fournisseur d'identité a été correctement configuré.
```
rosa list idps --cluster=
```
## Accorder à l'utilisateur l'accès à un cluster
Vous pouvez accorder à un utilisateur l'accès à votre cluster compte en l'ajoutant au fournisseur d'identité configuré.
La procédure suivante ajoute un utilisateur à une GitHub organisation configurée pour l'attribution d'identités au cluster.
1. Accédez à [github.com](https://github.com/) et connectez-vous à votre GitHub compte.
1. Invitez les utilisateurs qui ont besoin cluster d'accéder à votre GitHub organisation. Pour plus d'informations, consultez la section [Inviter des utilisateurs à rejoindre votre organisation](https://docs.github.com/en/organizations/managing-membership-in-your-organization/inviting-users-to-join-your-organization) dans la GitHub documentation.
## Configurer les autorisations `cluster-admin`
1. Accordez les `cluster-admin` autorisations à l'aide de la commande suivante. Remplacez `` et `` par votre nom d'utilisateur et de cluster.
```
rosa grant user cluster-admin --user= --cluster=
```
1. Vérifiez que l'utilisateur est répertorié comme membre du `cluster-admins` groupe.
```
rosa list users --cluster=
```
## Configurer les autorisations `dedicated-admin`
1. Accordez les `dedicated-admin` autorisations à l'aide de la commande suivante. Remplacez `` et `` par votre nom d'utilisateur et votre cluster nom.
```
rosa grant user dedicated-admin --user= --cluster=
```
1. Vérifiez que l'utilisateur est répertorié comme membre du `cluster-admins` groupe.
```
rosa list users --cluster=
```
## Accédez à un cluster via la console Red Hat Hybrid Cloud
Après avoir créé un utilisateur cluster administrateur ou ajouté un utilisateur à votre fournisseur d'identité configuré, vous pouvez vous connecter à votre compte cluster via la Red Hat Hybrid Cloud Console.
1. Obtenez l'URL de la console correspondante cluster à l'aide de la commande suivante. Remplacez `` par le nom de votre cluster.
```
rosa describe cluster -c | grep Console
```
1. Accédez à l'URL de la console dans la sortie et connectez-vous.
+ Si vous avez créé un `cluster-admin` utilisateur, connectez-vous à l'aide des informations d'identification fournies.
+ Si vous avez configuré un fournisseur d'identité pour vous cluster, choisissez le nom du fournisseur d'identité dans la boîte de dialogue **Se connecter avec...** et répondez à toutes les demandes d'autorisation présentées par votre fournisseur.
## Déployer une application depuis le catalogue des développeurs
À partir de la console Red Hat Hybrid Cloud, vous pouvez déployer une application de test Developer Catalog et l'exposer à l'aide d'un itinéraire.
1. Accédez à [Red Hat Hybrid Cloud Console](https://console.redhat.com/openshift) et choisissez le cluster dans lequel vous souhaitez déployer l'application.
1. Sur la page du cluster, choisissez **Ouvrir la console**.
1. Du point de vue de **l'administrateur**, choisissez **Accueil** > **Projets** > **Créer un projet**.
1. Entrez un nom pour votre projet et ajoutez éventuellement un **nom d'affichage** et une **description**.
1. Choisissez **Create** pour créer le projet.
1. Passez au point de vue **Développeur** et choisissez **\$1Ajouter**. Assurez-vous que le projet sélectionné est bien celui qui vient d'être créé.
1. Dans la boîte de dialogue **Developer Catalog**, sélectionnez **Tous les services**.
1. Sur la page du **catalogue pour développeurs**, choisissez **Langues** > dans le **JavaScript**menu.
1. Choisissez **Node.js**, puis sélectionnez **Créer une application** pour ouvrir la page **Créer Source-to-Image une application**.
**Note**
Vous devrez peut-être choisir **Effacer tous les filtres** pour afficher l'option **Node.js**.
1. Dans la section **Git**, choisissez **Try Sample**.
1. Dans le champ **Nom**, ajoutez un nom unique.
1. Choisissez **Créer**.
**Note**
Le déploiement de la nouvelle application prend plusieurs minutes.
1. Lorsque le déploiement est terminé, choisissez l'URL de route pour l'application.
Un nouvel onglet du navigateur s'ouvre avec un message similaire au suivant.
```
Welcome to your Node.js application on OpenShift
```
1. (Facultatif) Supprimez l'application et nettoyez les ressources.
1. Du point de vue de **l'administrateur**, choisissez **Accueil** > **Projets**.
1. Ouvrez le menu d'actions de votre projet et choisissez **Supprimer le projet**.
## Révoquer `cluster-admin` les autorisations d'un utilisateur
1. Révoquez les `cluster-admin` autorisations à l'aide de la commande suivante. Remplacez `` et `` par votre nom d'utilisateur et votre cluster nom.
```
rosa revoke user cluster-admin --user= --cluster=
```
1. Vérifiez que l'utilisateur n'est pas répertorié comme membre du `cluster-admins` groupe.
```
rosa list users --cluster=
```
## Révoquer `dedicated-admin` les autorisations d'un utilisateur
1. Révoquez les `dedicated-admin` autorisations à l'aide de la commande suivante. Remplacez `` et `` par votre nom d'utilisateur et votre cluster nom.
```
rosa revoke user dedicated-admin --user= --cluster=
```
1. Vérifiez que l'utilisateur n'est pas répertorié comme membre du `dedicated-admins` groupe.
```
rosa list users --cluster=
```
## Révoquer l'accès d'un utilisateur à un cluster
Vous pouvez révoquer cluster l'accès d'un utilisateur du fournisseur d'identité en le supprimant du fournisseur d'identité configuré.
Vous pouvez configurer différents types de fournisseurs d'identité pour votre cluster. La procédure suivante révoque cluster l'accès d'un membre d'une GitHub organisation.
1. Accédez à [github.com](https://github.com/) et connectez-vous à votre GitHub compte.
1. Supprimez l'utilisateur de votre GitHub organisation. Pour plus d'informations, consultez la section [Suppression d'un membre de votre organisation](https://docs.github.com/en/organizations/managing-membership-in-your-organization/removing-a-member-from-your-organization) dans la GitHub documentation.
## Supprimer un cluster et des AWS STS ressources
Vous pouvez utiliser la ROSA CLI pour supprimer un cluster qui utilise AWS Security Token Service (AWS STS). Vous pouvez également utiliser la ROSA CLI pour supprimer les IAM rôles et le fournisseur OIDC créés par ROSA. Pour supprimer les IAM politiques créées par ROSA, vous pouvez utiliser la IAM console.
**Important**
IAM les rôles et les politiques créés par ROSA peuvent être utilisés par d'autres ROSA clusters du même compte.
1. cluster Supprimez-les et observez les journaux. Remplacez `` par le nom ou l'identifiant de votre cluster.
```
rosa delete cluster --cluster= --watch
```
**Important**
Vous devez attendre que la suppression cluster soit complète avant de supprimer les IAM rôles, les politiques et le fournisseur OIDC. Les rôles IAM du compte sont nécessaires pour supprimer les ressources créées par le programme d'installation. Les rôles IAM des opérateurs sont nécessaires pour nettoyer les ressources créées par les OpenShift opérateurs. Les opérateurs utilisent le fournisseur OIDC pour s'authentifier.
1. Supprimez le fournisseur OIDC que les cluster opérateurs utilisent pour s'authentifier en exécutant la commande suivante.
```
rosa delete oidc-provider -c --mode auto
```
1. Supprimez les rôles d'opérateur spécifiques au cluster. IAM
```
rosa delete operator-roles -c --mode auto
```
1. Supprimez les rôles IAM du compte à l'aide de la commande suivante. ``Remplacez-le par le préfixe du compte IAM roles à supprimer. Si vous avez spécifié un préfixe personnalisé lors de la création des rôles IAM du compte, spécifiez le préfixe par défaut`ManagedOpenShift`.
```
rosa delete account-roles --prefix --mode auto
```
1. Supprimez les IAM politiques créées par ROSA.
1. Connectez-vous à la [console IAM](https://console.aws.amazon.com/iamv2/home#/home).
1. Dans le menu de gauche, sous **Gestion des accès**, sélectionnez **Politiques**.
1. Sélectionnez la politique que vous souhaitez supprimer, puis sélectionnez **Actions** > **Supprimer**.
1. Entrez le nom de la politique et choisissez **Supprimer**.
1. Répétez cette étape pour supprimer chacune des politiques IAM pour le cluster.