Créez un cluster ROSA classic qui utilise AWS PrivateLink - Red Hat OpenShift Service on AWS
PrérequisCréation d'une Amazon VPC architectureCréez un cluster ROSA classic à l'aide de la ROSA CLI et AWS PrivateLinkConfigurer le transfert AWS PrivateLink DNSConfiguration d'un fournisseur d'identité et autorisation cluster d'accèsAccorder à l'utilisateur l'accès à un clusterConfiguration cluster-admin des autorisationsConfiguration dedicated-admin des autorisationsAccédez à un cluster via la console Red Hat Hybrid CloudDéployer une application depuis le catalogue des développeursRévoquer cluster-admin les autorisations d'un utilisateurRévoquer dedicated-admin les autorisations d'un utilisateurRévoquer l'accès d'un utilisateur à un clusterSupprimer un cluster et des AWS STS ressources

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.

Créez un cluster ROSA classic 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, voirROSA architecture. 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 ?

Effectuez les actions préalables répertoriées dansConfigurer pour utiliser ROSA.

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.

Important

Si Amazon VPC les exigences ne sont pas satisfaites, la création du cluster échoue.

Amazon VPC console

  1. Ouvrez la Amazon VPC console.

  2. Sur le tableau de bord VPC, choisissez Create VPC (Créer un VPC).

  3. Sous Ressources à créer, choisissez VPC et plus encore.

  4. 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.

  5. Pour le bloc IPv4 CIDR, entrez une plage d' IPv4 adresses pour le VPC. Un VPC doit avoir une plage d' IPv4 adresses.

  6. (Facultatif) Pour prendre en charge IPv6 le trafic, choisissez le bloc IPv6 CIDR, le bloc CIDR fourni par Amazon IPv6 .

  7. Laissez la location telle Default quelle.

  8. 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 commandeaws ec2 describe-instance-type-offerings --location-type availability-zone --filters Name=location,Values=<availability_zone> --region <region> --output text | egrep "<instance_type>".

  9. 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.

  10. 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.

  11. (Facultatif) Si vous devez accéder Amazon S3 directement depuis votre VPC, choisissez les points de terminaison du VPC, S3 Gateway.

  12. 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.

  13. Sélectionnez Create VPC (Créer un VPC).

AWS CLI

  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

  2. Stockez l'ID du VPC dans une variable d'environnement.

    export VPC_ID=vpc-1234567890abcdef0

  3. Créez une Name balise pour le VPC à l'aide de la variable d'VPC_IDenvironnement.

    aws ec2 create-tags --resources $VPC_ID --tags Key=Name,Value=MyVPC

  4. 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

  5. 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 commandeaws ec2 describe-instance-type-offerings --location-type availability-zone --filters Name=location,Values=<availability_zone> --region <region> --output text | egrep "<instance_type>".

    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

  6. Stockez les sous-réseaux public et privé IDs dans des variables d'environnement.

    export PUBLIC_SUB=subnet-1234567890abcdef0
export PRIVATE_SUB=subnet-0987654321fedcba0

  7. 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

  8. 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

  9. Connectez la passerelle Internet au VPC.

    aws ec2 attach-internet-gateway \
    --vpc-id $VPC_ID \
    --internet-gateway-id $IGW

  10. 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

  11. 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

  12. 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

  13. (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.

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 les conditions requises pour le AWS pare-feu dans la OpenShift 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 de résolution des problèmes, voirRésoudre les problèmes liés aux ROSA CLI jetons d'accès hors ligne expirés.

  2. Créez un cluster en exécutant l'une des commandes suivantes.

    • Mono-AZ

      rosa create cluster --private-link --cluster-name=<CLUSTER_NAME> --machine-cidr=10.0.0.0/16 --subnet-ids=<PRIVATE_SUBNET_ID>

    • Multi-AZ

      rosa create cluster --private-link --multi-az --cluster-name=<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.

  3. Créez les IAM rôles d' cluster opérateur en suivant les instructions interactives.

    rosa create operator-roles --interactive -c <CLUSTER_NAME>

  4. Créez le fournisseur OpenID Connect (OIDC) que les cluster opérateurs utilisent pour s'authentifier.

    rosa create oidc-provider --interactive -c <CLUSTER_NAME>

  5. Vérifiez l'état de votre cluster.

    rosa describe cluster -c <CLUSTER_NAME>
    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 ready après 40 minutes, consultezRésolution des problèmes. Pour contacter le support Red Hat Support ou obtenir de l'aide, consultezObtenir de ROSA l'aide.

  6. Suivez la progression de la cluster création en consultant les journaux du OpenShift programme d'installation.

    rosa logs install -c <CLUSTER_NAME> --watch

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. Pour plus d'informations sur les zones hébergées publiques, consultez la section Utilisation des zones hébergées publiques.

  1. Pour autoriser des enregistrements tels que api.<cluster_domain> et pour les *.apps.<cluster_domain> résoudre en dehors du VPC, configurez un point de terminaison Route 53 Resolver entrant.

    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.

  2. 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.

Une fois que le point de terminaison Route 53 Resolver interne est 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 quedrow-pl-01.htno.p1.openshiftapps.com.

  2. 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.

  3. 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é.

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.

  1. Accédez à github.com et connectez-vous à votre GitHub compte.

  2. 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.

  3. À 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=<CLUSTER_NAME> --interactive

  4. 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: <GITHUB_ORG_NAME>
? To use GitHub as an identity provider, you must first register the application:
  - Open the following URL:
    https://github.com/organizations/<GITHUB_ORG_NAME>/settings/applications/new?oauth_application%5Bcallback_url%5D=https%3A%2F%2Foauth-openshift.apps.<CLUSTER_NAME>/<RANDOM_STRING>.p1.openshiftapps.com%2Foauth2callback%2Fgithub-1&oauth_application%5Bname%5D=<CLUSTER_NAME>&oauth_application%5Burl%5D=https%3A%2F%2Fconsole-openshift-console.apps.<CLUSTER_NAME>/<RANDOM_STRING>.p1.openshiftapps.com
  - Click on 'Register application'
...

  5. Ouvrez l'URL dans la sortie, en la <GITHUB_ORG_NAME> remplaçant par le nom de votre GitHub organisation.

  6. Sur la page GitHub Web, choisissez Enregistrer une application pour enregistrer une nouvelle OAuth application dans votre GitHub organisation.

  7. Utilisez les informations de la GitHub OAuth page pour remplir les autres invites rosa create idp interactives, en remplaçant <GITHUB_CLIENT_ID> et <GITHUB_CLIENT_SECRET> par les informations d'identification de votre GitHub OAuth application.

    ...
? Client ID: <GITHUB_CLIENT_ID>
? Client Secret: [? for help] <GITHUB_CLIENT_SECRET>
? GitHub Enterprise Hostname (optional):
? Mapping method: claim
I: Configuring IDP for cluster '<CLUSTER_NAME>'
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.<CLUSTER_NAME>.<RANDOM_STRING>.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.

  8. Vérifiez que le fournisseur d'identité a été correctement configuré.

    rosa list idps --cluster=<CLUSTER_NAME>

Vous pouvez autoriser un utilisateur à accéder à 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 et connectez-vous à votre GitHub compte.

  2. 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 dans la GitHub documentation.

  1. Accordez les cluster-admin autorisations à l'aide de la commande suivante. Remplacez <IDP_USER_NAME> et <CLUSTER_NAME> par votre nom d'utilisateur et de cluster.

    rosa grant user cluster-admin --user=<IDP_USER_NAME> --cluster=<CLUSTER_NAME>

  2. Vérifiez que l'utilisateur est répertorié comme membre du cluster-admins groupe.

    rosa list users --cluster=<CLUSTER_NAME>

  1. Accordez les dedicated-admin autorisations à l'aide de la commande suivante. Remplacez <IDP_USER_NAME> et <CLUSTER_NAME> par votre nom d'utilisateur et votre cluster nom.

    rosa grant user dedicated-admin --user=<IDP_USER_NAME> --cluster=<CLUSTER_NAME>

  2. Vérifiez que l'utilisateur est répertorié comme membre du cluster-admins groupe.

    rosa list users --cluster=<CLUSTER_NAME>

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 <CLUSTER_NAME> par le nom de votre cluster.

    rosa describe cluster -c <CLUSTER_NAME> | grep Console

  2. 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.

À 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 et choisissez le cluster dans lequel vous souhaitez déployer l'application.

  2. Sur la page du cluster, choisissez Ouvrir la console.

  3. Du point de vue de l'administrateur, choisissez Accueil > Projets > Créer un projet.

  4. Entrez un nom pour votre projet et ajoutez éventuellement un nom d'affichage et une description.

  5. Choisissez Create pour créer le projet.

  6. Passez au point de vue Développeur et choisissez +Ajouter. Assurez-vous que le projet sélectionné est celui qui vient d'être créé.

  7. Dans la boîte de dialogue Developer Catalog, sélectionnez Tous les services.

  8. Sur la page du catalogue pour développeurs, choisissez Langues > dans le JavaScriptmenu.

  9. 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.

  10. Dans la section Git, choisissez Try Sample.

  11. Dans le champ Nom, ajoutez un nom unique.

  12. Sélectionnez Create (Créer).

    Note

    Le déploiement de la nouvelle application prend plusieurs minutes.

  13. 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

  14. (Facultatif) Supprimez l'application et nettoyez les ressources.

    1. Du point de vue de l'administrateur, choisissez Accueil > Projets.

    2. Ouvrez le menu d'actions de votre projet et choisissez Supprimer le projet.

  1. Révoquez les cluster-admin autorisations à l'aide de la commande suivante. Remplacez <IDP_USER_NAME> et <CLUSTER_NAME> par votre nom d'utilisateur et votre cluster nom.

    rosa revoke user cluster-admin --user=<IDP_USER_NAME> --cluster=<CLUSTER_NAME>

  2. Vérifiez que l'utilisateur n'est pas répertorié comme membre du cluster-admins groupe.

    rosa list users --cluster=<CLUSTER_NAME>

  1. Révoquez les dedicated-admin autorisations à l'aide de la commande suivante. Remplacez <IDP_USER_NAME> et <CLUSTER_NAME> par votre nom d'utilisateur et votre cluster nom.

    rosa revoke user dedicated-admin --user=<IDP_USER_NAME> --cluster=<CLUSTER_NAME>

  2. Vérifiez que l'utilisateur n'est pas répertorié comme membre du dedicated-admins groupe.

    rosa list users --cluster=<CLUSTER_NAME>

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 et connectez-vous à votre GitHub compte.

  2. Supprimez l'utilisateur de votre GitHub organisation. Pour plus d'informations, consultez la section Suppression d'un membre de votre organisation dans la GitHub documentation.

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 <CLUSTER_NAME> par le nom ou l'identifiant de votre cluster.

    rosa delete cluster --cluster=<CLUSTER_NAME> --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.

  2. Supprimez le fournisseur OIDC que les cluster opérateurs utilisent pour s'authentifier en exécutant la commande suivante.

    rosa delete oidc-provider -c <CLUSTER_ID> --mode auto

  3. Supprimez les rôles d'opérateur spécifiques au cluster. IAM 

    rosa delete operator-roles -c <CLUSTER_ID> --mode auto

  4. Supprimez les rôles IAM du compte à l'aide de la commande suivante. Remplacez <PREFIX> 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éfautManagedOpenShift.

    rosa delete account-roles --prefix <PREFIX> --mode auto

  5. Supprimez les IAM politiques créées par ROSA.

    1. Connectez-vous à la console IAM.

    2. Dans le menu de gauche, sous Gestion des accès, sélectionnez Politiques.

    3. Sélectionnez la politique que vous souhaitez supprimer, puis sélectionnez Actions > Supprimer.

    4. Entrez le nom de la politique et choisissez Supprimer.

    5. Répétez cette étape pour supprimer chacune des politiques IAM pour. cluster