Créez un cluster ROSA classique qui utilise AWS PrivateLink - Red Hat OpenShift Service on AWS
PrérequisCréation Amazon VPC applicationCréez un cluster ROSA classique à l'aide du ROSA CLIet AWS PrivateLinkConfiguration AWS PrivateLink DNStransfertConfiguration d'un fournisseur d'identité et autorisation cluster 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 à partir du catalogue pour 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 AWS STS resources

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 classique qui utilise AWS PrivateLink

ROSAles clusters classiques peuvent être déployés de différentes manières : public, privé ou privé avec AWS PrivateLink. Pour plus d'informations sur la ROSA version classique, consultezModèles d'architecture. Pour le public comme pour le privé cluster configurations, les OpenShift cluster a accès à Internet, et la confidentialité est définie sur les charges de travail des applications au niveau de la couche application.

Si vous avez besoin des deux cluster et les charges de travail des applications doivent être privées, vous pouvez configurer AWS PrivateLink avec du ROSA classique. AWS PrivateLink est une technologie hautement disponible et évolutive qui ROSA utilise pour créer une connexion privée entre ROSA ressources de service et de cluster dans AWS compte client. Avec AWS PrivateLink, l'équipe d'ingénierie de fiabilité des sites de Red Hat (SRE) peut accéder au cluster à des fins de support et de correction en utilisant un sous-réseau privé connecté au AWS PrivateLink point de terminaison.

Pour plus d'informations sur AWS PrivateLink, voir Qu'est-ce que AWS PrivateLink?

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

Création Amazon VPC application

La procédure suivante crée Amazon VPC architecture pouvant être utilisée pour héberger un cluster. Tous cluster les 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 NAT passerelle vers l'Internet public. Cet exemple utilise le CIDR bloc 10.0.0.0/16 pour Amazon VPC. Vous pouvez toutefois choisir un autre CIDR bloc. Pour plus d'informations, consultez la section VPCDimensionnement.

Important

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

Amazon VPC console

  1. Ouvrez le fichier Amazon VPC console.

  2. Sur le VPC tableau de bord, choisissez Create VPC.

  3. Pour que Resources crée, choisissez VPCet plus encore.

  4. Conservez l'option Génération automatique de balises de nom sélectionnée pour créer des balises de nom pour les VPC ressources, ou désactivez-la pour fournir vos propres balises de nom pour les VPC ressources.

  5. Pour le IPv4CIDRbloc, entrez une plage d'IPv4adresses pourVPC. A VPC doit avoir une plage d'IPv4adresses.

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

  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 nécessite trois zones de disponibilité. Pour choisir le AZs pour vos sous-réseaux, développez Personnaliser AZs.

    Note

    Momentanée ROSA les types d'instance ne sont disponibles que dans certaines zones de disponibilité. Vous pouvez utiliser le plugin ROSA CLIrosa list instance-typescommande pour tout lister ROSA types d'instances disponibles. Pour vérifier si un type d'instance est disponible pour une zone de disponibilité donnée, utilisez 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 les blocs Personnaliser les sous-réseaux CIDR.

    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 publicIPv4, pour les passerelles, choisissez le nombre de NATpasserelles AZs dans lesquelles vous souhaitez créer NAT des passerelles. En production, nous vous recommandons de déployer une NAT passerelle dans chaque AZ avec des ressources nécessitant un accès à l'Internet public.

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

  12. Laissez les DNS options par défaut sélectionnées. ROSA nécessite la prise en charge DNS du nom d'hôte sur le. VPC

  13. Choisissez Create VPC.

AWS CLI

  1. Créez un VPC avec un 10.0.0.0/16 CIDR bloc.

     aws ec2 create-vpc \
     --cidr-block 10.0.0.0/16 \
     --query Vpc.VpcId \
     --output text

    La commande précédente renvoie l'VPCID. Voici un exemple de sortie.

    vpc-1234567890abcdef0

  2. Stockez l'VPCID dans une variable d'environnement.

    export VPC_ID=vpc-1234567890abcdef0

  3. Créez une Name balise pour leVPC, à 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 DNS noms d'hôte 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 leVPC, 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 conditions ne sont pas remplies, la création du cluster échoue.

    Note

    Momentanée ROSA les types d'instance ne sont disponibles que dans certaines zones de disponibilité. Vous pouvez utiliser le plugin ROSA CLIrosa list instance-typescommande pour tout lister ROSA types d'instances disponibles. Pour vérifier si un type d'instance est disponible pour une zone de disponibilité donnée, utilisez 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. Reliez la passerelle Internet auVPC.

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

    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 le plugin ROSA CLIet AWS PrivateLink pour créer un cluster avec une seule zone de disponibilité (mono-AZ) ou plusieurs zones de disponibilité (multi-AZ). Dans les deux cas, la CIDR valeur de votre machine doit correspondre à VPC la CIDR vôtre.

La procédure suivante utilise la rosa create cluster commande pour créer un ROSA classique cluster. Pour créer un Multi-AZ cluster, spécifiez --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 telle sorte que ROSA peut accéder aux sites dont il a besoin pour fonctionner.

Pour plus d’informations, consultez .AWS les prérequis en matière de pare-feu sont décrits dans la OpenShift documentation Red Hat.

  1. Créez le requis IAM rôles et politiques de compte utilisant --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é, ROSA CLIaffiche 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, consultezRé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 AWS PrivateLink avec AWS Security Token Service (AWS STS) informations d'identification de courte durée, à ajouter --sts --mode auto ou --sts --mode manual à la fin de la rosa create cluster commande.

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

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

  4. Créez le fournisseur OpenID Connect (OIDC) cluster les 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

    Cela peut prendre jusqu'à 40 minutes pour cluster Statechamp pour afficher le ready statut. Si le provisionnement échoue ou ne s'affiche pas au ready bout de 40 minutes, consultezRésolution des problèmes. Pour contacter AWS Support ou le support Red Hat pour obtenir de l'aide, consultezObtenir de ROSA l'aide.

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

    rosa logs install -c <CLUSTER_NAME> --watch

Clusters qui utilisent AWS PrivateLink créer une zone hébergée publique et une zone hébergée privée dans Route 53. Enregistrements au sein du Route 53 les zones hébergées privées ne peuvent être résolues qu'à partir de VPC celle à laquelle elles sont assignées.

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 AWS zones hébergées privées, voir 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 *.apps.<cluster_domain> pour les résoudre en dehors deVPC, configurez un Route 53 Resolver point de terminaison 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 les sous-réseaux VPC et les sous-réseaux privés utilisés lors de la création du cluster.

Après le Route 53 Resolver le point de terminaison interne est associé et opérationnel, configurez le DNS transfert afin que les DNS requêtes 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 DNS requêtes vers les adresses IP du domaine de premier niveau, telles quedrow-pl-01.htno.p1.openshiftapps.com.

  2. Si vous transférez DNS des requêtes de l'un VPC à l'autreVPC, suivez les instructions de la section Gestion des règles de transfert.

  3. Si vous configurez votre DNS serveur réseau distant, consultez la documentation de votre DNS serveur spécifique pour configurer le DNS transfert sélectif pour le domaine de cluster installé.

ROSA inclut un OAuth serveur intégré. Après votre ROSA cluster est 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 GitLab, GoogleLDAP, 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. HTPasswdn'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, voir 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 le provisionnement des identités pour votre ROSA cluster, créez-en un. Pour plus d'informations, consultez les étapes décrites dans la GitHub documentation.

  3. Utilisation de ROSA CLIen mode interactif, 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 dans la sortie pour restreindre cluster 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 le URL dans la sortie, en le <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 accorder à un utilisateur l'accès à votre cluster en les 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. Inviter les utilisateurs qui ont besoin cluster accès à 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 utilisateur et 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 cluster utilisateur administrateur ou vous avez ajouté un utilisateur à votre fournisseur d'identité configuré, vous pouvez vous connecter à votre cluster via la console Red Hat Hybrid Cloud.

  1. Procurez-vous la console URL pour votre 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 à la console URL 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 votre cluster, choisissez le nom du fournisseur d'identité dans la boîte de dialogue Se connecter avec... et répondez aux 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 Open 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 bien 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 choisissez Create Application pour ouvrir la page Create Source-to-Image 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'itinéraire URL de 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 utilisateur et 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 utilisateur et 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 accès pour 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 accès pour 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 le plugin ROSA CLIpour supprimer un cluster qui utilise AWS Security Token Service (AWS STS). Vous pouvez également utiliser ROSA CLIpour supprimer le IAM rôles et OIDC fournisseur créés par ROSA. Pour supprimer le IAM politiques créées par ROSA, vous pouvez utiliser IAM console.

Important

IAM rôles et politiques créés par ROSA pourrait être utilisé par d'autres ROSA clusters dans le même compte.

  1. Supprimez les photos ou les vidéos cluster et regardez 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 le cluster à supprimer complètement avant de supprimer le IAM rôles, politiques et OIDC fournisseur. Les IAM rôles de compte sont nécessaires pour supprimer les ressources créées par le programme d'installation. Les IAM rôles d'opérateur sont nécessaires pour nettoyer les ressources créées par les OpenShift opérateurs. Les opérateurs utilisent le OIDC fournisseur pour s'authentifier.

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

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

  3. Supprimer l'opérateur spécifique au cluster IAM rôles.

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

  4. Supprimez les IAM rôles du compte à l'aide de la commande suivante. Remplacez <PREFIX> par le préfixe des IAM rôles de compte à supprimer. Si vous avez spécifié un préfixe personnalisé lors de la création des IAM rôles de compte, spécifiez le ManagedOpenShift préfixe par défaut.

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

  5. Supprimez les photos ou les vidéos IAM politiques créées par ROSA.

    1. Connectez-vous au IAM console.

    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 IAM politiques du cluster.