Crea un cluster ROSA classico che utilizza AWS PrivateLink

ROSAi cluster classici possono essere implementati in diversi modi: pubblici, privati o privati con. AWS PrivateLink Per ulteriori informazioni sulla ROSA versione classica, consulta. Modelli di architettura Sia per cluster le configurazioni pubbliche che private, OpenShift cluster ha accesso a Internet e la privacy è impostata sui carichi di lavoro dell'applicazione a livello di applicazione.

Se desideri che sia il cluster carico di lavoro che quello dell'applicazione siano privati, puoi eseguire la configurazione AWS PrivateLink con classic. ROSA AWS PrivateLink è una tecnologia scalabile e altamente disponibile che ROSA consente di creare una connessione privata tra il ROSA servizio e le risorse del cluster nell'account del AWS cliente. Con AWS PrivateLink, il team di Red Hat Site Reliability Engineering (SRE) può accedere al cluster per scopi di supporto e riparazione utilizzando una sottorete privata connessa all'endpoint del cluster. AWS PrivateLink

Per ulteriori informazioni su AWS PrivateLink, consulta What is? AWS PrivateLink

Prerequisiti

Completa le azioni prerequisite elencate inConfigurazione per l'uso ROSA.

Crea Amazon VPC l'architettura per il cluster

Per creare un'architettura ROSA cluster che utilizzi AWS PrivateLink, devi prima configurare la tua Amazon VPC architettura in cui implementare la soluzione. La procedura seguente utilizza la AWS CLI per creare una sottorete pubblica e privata in un'unica zona di disponibilità per un cluster Single-AZ. Tutte le cluster risorse si trovano nella sottorete privata. La sottorete pubblica indirizza il traffico in uscita utilizzando un NAT gateway verso Internet.

Questo esempio utilizza il CIDR blocco 10.0.0.0/16 per. Amazon VPC Tuttavia, puoi scegliere un CIDR blocco diverso. Per ulteriori informazioni, vedi VPCdimensionamento.

Importante

Se Amazon VPC i requisiti non vengono soddisfatti, la creazione del cluster non riesce.

1. Imposta una variabile di ambiente per il cluster nome eseguendo il comando seguente.

    ROSA_CLUSTER_NAME=rosa-hcp

2. Crea un VPC con un 10.0.0.0/16 CIDR blocco.

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

   Il comando precedente restituisce l'ID del nuovoVPC. Di seguito è riportato un esempio di output.

   vpc-0410832ee325aafea

3. Utilizzando l'VPCID del passaggio precedente, contrassegnate la variabile VPC utilizzando la ROSA_CLUSTER_NAME variabile.

   aws ec2 create-tags --resources <VPC_ID_VALUE> --tags Key=Name,Value=$ROSA_CLUSTER_NAME

4. Abilita DNS il supporto del nome host su. VPC

   aws ec2 modify-vpc-attribute --vpc-id <VPC_ID_VALUE> --enable-dns-hostnames

5. Crea una sottorete pubblica nel 10.0.1.0/24 CIDR blocco VPC with a, specificando la zona di disponibilità in cui deve essere creata la risorsa.

   Importante

   ROSAwith HCP richiede che i clienti configurino almeno una sottorete pubblica e privata per ogni zona di disponibilità utilizzata per creare i cluster. Per i cluster Single-AZ, è necessaria una sola zona di disponibilità. Per i cluster Multi-AZ, sono necessarie tre zone di disponibilità. Se questi requisiti non vengono soddisfatti, la creazione del cluster non riesce.

   Nota

   Durante la creazione di sottoreti, assicurati che le sottoreti vengano create in una zona di disponibilità con tipi di istanze disponibili. ROSA Se non scegli una zona di disponibilità specifica, la sottorete viene creata in una qualsiasi delle zone di disponibilità specificate. Regione AWS

   Per specificare una zona di disponibilità specifica, utilizzate l'--availability zoneargomento nel create-subnet comando. È possibile utilizzare il rosa list instance-types comando per elencare tutti i tipi di ROSA istanze disponibili. Per verificare se un tipo di istanza è disponibile per una determinata zona di disponibilità, utilizzate il comando seguente.

   aws 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_VALUE> --cidr-block 10.0.1.0/24 --availability-zone <AZ_NAME> --query Subnet.SubnetId --output text

   Il comando precedente restituisce l'ID della nuova sottorete. Di seguito è riportato un esempio di output.

   subnet-0b6a7e8cbc8b75920

6. Utilizzando l'ID di sottorete del passaggio precedente, etichettate la sottorete utilizzando la variabile. ROSA_CLUSTER_NAME-public

   aws ec2 create-tags --resources <PUBLIC_SUBNET_ID> --tags Key=Name,Value=$ROSA_CLUSTER_NAME-public

7. Crea una sottorete privata nel blocco VPC con un 10.0.0.0/24 CIDR blocco, specificando la stessa zona di disponibilità in cui è stata distribuita la sottorete pubblica.

   aws ec2 create-subnet --vpc-id <VPC_ID_VALUE> --cidr-block 10.0.0.0/24 --availability-zone <AZ_NAME> --query Subnet.SubnetId --output text

   Il comando precedente restituisce l'ID della nuova sottorete. Di seguito è riportato un esempio di output.

   subnet-0b6a7e8cbc8b75920

8. Utilizzando l'ID di sottorete del passaggio precedente, etichettate la sottorete utilizzando la variabile. ROSA_CLUSTER_NAME-private

   aws ec2 create-tags --resources <PRIVATE_SUBNET_ID> --tags Key=Name,Value=$ROSA_CLUSTER_NAME-private

9. Crea un gateway Internet per il traffico in uscita e collegalo a. VPC

   aws ec2 create-internet-gateway --query InternetGateway.InternetGatewayId --output text
   
   aws ec2 attach-internet-gateway --vpc-id <VPC_ID_VALUE> --internet-gateway-id <IG_ID_VALUE>

10. Etichetta il gateway Internet con la ROSA_CLUSTER_NAME variabile.

    aws ec2 create-tags --resources <IG_ID_VALUE> --tags Key=Name,Value=$ROSA_CLUSTER_NAME

11. Crea una tabella di routing per il traffico in uscita, associala alla sottorete pubblica e configura il traffico da indirizzare verso il gateway Internet.

    aws ec2 create-route-table --vpc-id <VPC_ID_VALUE> --query RouteTable.RouteTableId --output text
    
    aws ec2 associate-route-table --subnet-id <PUBLIC_SUBNET_ID> --route-table-id <PUBLIC_RT_ID>
    
    aws ec2 create-route --route-table-id <PUBLIC_RT_ID> --destination-cidr-block 0.0.0.0/0 --gateway-id <IG_ID_VALUE>

12. Etichetta la tabella delle rotte pubbliche con la ROSA_CLUSTER_NAME variabile e verifica che la tabella delle rotte sia stata configurata correttamente.

    aws ec2 create-tags --resources <PUBLIC_RT_ID> --tags Key=Name,Value=$ROSA_CLUSTER_NAME
    
    aws ec2 describe-route-tables --route-table-id <PUBLIC_RT_ID>

13. Crea un NAT gateway nella sottorete pubblica con un indirizzo IP elastico per abilitare il traffico verso la sottorete privata.

    aws ec2 allocate-address --domain vpc --query AllocationId --output text
    
    aws ec2 create-nat-gateway --subnet-id <PUBLIC_SUBNET_ID> --allocation-id <EIP_ADDRESS>  --query NatGateway.NatGatewayId --output text

14. Etichetta il NAT gateway e l'indirizzo IP elastico con la $ROSA_CLUSTER_NAME variabile.

    aws ec2 create-tags --resources <EIP_ADDRESS>  --resources <NAT_GATEWAY_ID> --tags Key=Name,Value=$ROSA_CLUSTER_NAME

15. Crea una tabella di routing per il traffico di sottorete privato, associala alla sottorete privata e configura il traffico per il routing verso il NAT gateway.

    aws ec2 create-route-table --vpc-id <VPC_ID_VALUE> --query RouteTable.RouteTableId --output text
    
    aws ec2 associate-route-table --subnet-id <PRIVATE_SUBNET_ID> --route-table-id <PRIVATE_RT_ID>
    
    aws ec2 create-route --route-table-id <PRIVATE_RT_ID> --destination-cidr-block 0.0.0.0/0 --gateway-id <NAT_GATEWAY_ID>

16. Assegna un tag alla tabella di routing privata e all'indirizzo IP elastico con la $ROSA_CLUSTER_NAME-private variabile.

    aws ec2 create-tags --resources <PRIVATE_RT_ID> <EIP_ADDRESS> --tags Key=Name,Value=$ROSA_CLUSTER_NAME-private

Crea un cluster ROSA classico usando ROSA CLI e AWS PrivateLink

È possibile utilizzare ROSA CLI e {privatelinkg} per creare un ambiente cluster con una singola zona di disponibilità (Single-AZ) o più zone di disponibilità (Multi-AZ). In entrambi i casi, il CIDR valore della macchina deve corrispondere al valore del tuo. VPC CIDR

La procedura seguente utilizza il rosa create cluster comando per creare un Single-AZ ROSA cluster. Per creare una Multi-AZ cluster, specificate multi-az nel comando e nella sottorete privata IDs per ogni sottorete privata in cui desiderate effettuare la distribuzione.

Nota

Se si utilizza un firewall, è necessario configurarlo in modo che ROSA possa accedere ai siti necessari per funzionare.

Per ulteriori informazioni, consultate i prerequisiti del AWS firewall nella OpenShift documentazione di Red Hat.

1. Create un Single-AZ cluster eseguendo il seguente comando.

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

   Nota

   Per creare un cluster che utilizza credenziali AWS PrivateLink with AWS Security Token Service (AWS STS) di breve durata, aggiungi --sts --mode auto o --sts --mode manual alla fine del comando. rosa create cluster

2. Crea i IAM ruoli dell' cluster operatore seguendo le istruzioni interattive.

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

3. Crea il provider OpenID Connect (OIDC) utilizzato cluster dagli operatori per l'autenticazione.

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

4. Controlla lo stato del tuo. cluster

   rosa describe cluster -c <CLUSTER_NAME>

   Nota

   Potrebbero essere necessari fino a 40 minuti prima che il cluster State campo mostri ready lo stato. Se il provisioning fallisce o non viene visualizzato ready dopo 40 minuti, consultaRisoluzione dei problemi.

   Per contattare il AWS Support nostro supporto Red Hat per ricevere assistenza, consultaOttenere ROSA assistenza.

5. Tieni traccia dello stato di avanzamento della cluster creazione guardando i log dell' OpenShift installatore.

   rosa logs install -c <CLUSTER_NAME> --watch

Configura l'inoltro AWS PrivateLink DNS

I cluster che utilizzano AWS PrivateLink creano una zona ospitata pubblica e una zona ospitata privata in. Route 53 I record all'interno della zona ospitata Route 53 privata sono risolvibili solo all'interno della zona a VPC cui sono assegnati.

La convalida Let's Encrypt DNS -01 richiede una zona pubblica in modo che possano essere emessi certificati validi e pubblicamente attendibili per il dominio. I record di convalida vengono eliminati dopo il completamento della convalida di Let's Encrypt. La zona è ancora necessaria per l'emissione e il rinnovo di questi certificati, che in genere sono richiesti ogni 60 giorni. Sebbene queste zone appaiano generalmente vuote, un'area pubblica svolge un ruolo fondamentale nel processo di convalida.

Per ulteriori informazioni sulle zone ospitate AWS private, consulta Lavorare con le zone private. Per ulteriori informazioni sulle zone ospitate pubbliche, consulta Lavorare con le zone ospitate pubbliche.

Configura un Route 53 Resolver endpoint in entrata

Per consentire la risoluzione di record come quelli api.<cluster_domain> esterni *.apps.<cluster_domain> aVPC, configura un endpoint Route 53 Resolver in entrata.

1. Apri la console. Route 53

2. Nel riquadro di navigazione sotto Resolver, scegli Endpoints in entrata.

3. Scegli Configura endpoint.

4. In alto a destra, usa il Regione AWS selettore per scegliere Regione AWS quello che contiene l'VPCusato per il cluster.

5. In Configurazione di base, scegli Solo in entrata, quindi scegli Avanti.

6. Nella pagina Configura l'endpoint in entrata, completa la sezione Impostazioni generali per l'endpoint in entrata. In Gruppo di sicurezza per questo endpoint, scegli un gruppo di sicurezza che consenta il TCP traffico in entrata UDP e dalla rete remota sulla porta di destinazione 53.

7. Nella sezione Indirizzo IP, scegli le zone di disponibilità e le sottoreti private utilizzate durante la creazione del cluster e scegli Avanti.

8. (Facoltativo) Completa la sezione Tag.

9. Scegli Invia.

Configura DNS l'inoltro per il cluster

Dopo che l'endpoint Route 53 Resolver interno è stato associato e reso operativo, configurate l'DNSinoltro in modo che DNS le query possano essere gestite dai server designati sulla rete.

1. Configurate la rete aziendale per inoltrare DNS le query a quegli indirizzi IP per il dominio di primo livello, ad esempio. drow-pl-01.htno.p1.openshiftapps.com

2. Se stai inoltrando DNS le richieste da uno VPC all'altroVPC, segui le istruzioni in Gestione delle regole di inoltro.

3. Se stai configurando il server di rete remoto, consulta la documentazione specifica DNS del server per configurare l'inoltro selettivo DNS per il dominio DNS del cluster installato.

Configura un provider di identità e concedi l'accesso cluster

ROSA include un OAuth server integrato. Dopo la creazione, ROSA cluster è necessario configurare l'utilizzo OAuth di un provider di identità. Puoi quindi aggiungere utenti al tuo provider di identità configurato per concedere loro l'accesso al tuo cluster. Puoi concedere a questi utenti cluster-admin o dedicated-admin autorizzazioni come richiesto.

Puoi configurare diversi tipi di provider di identità per il tuo cluster. I tipi supportati includono GitHub Enterprise GitHub GitLab, GoogleLDAP, OpenID Connect e provider di HTPasswd identità.

Importante

Il provider di HTPasswd identità è incluso solo per consentire la creazione di un singolo utente amministratore statico. HTPasswdnon è supportato come provider di identità di uso generico per. ROSA

La procedura seguente configura un provider di GitHub identità come esempio. Per istruzioni su come configurare ciascuno dei tipi di provider di identità supportati, vedere Configurazione dei provider di identità per. AWS STS

1. Vai su github.com e accedi al tuo account. GitHub

2. Se non hai un' GitHub organizzazione da utilizzare per la fornitura di identità per la tua ROSA cluster azienda, creane una. Per ulteriori informazioni, consulta i passaggi indicati nella GitHub documentazione.

3. Utilizzando ROSA CLI la modalità interattiva, configura un provider di identità per il cluster eseguendo il comando seguente.

   rosa create idp --cluster=<CLUSTER_NAME> --interactive

4. Segui le istruzioni di configurazione nell'output per limitare l' cluster accesso ai membri della tua GitHub organizzazione.

   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. Apritelo URL nell'output, sostituendolo <GITHUB_ORG_NAME> con il nome della vostra GitHub organizzazione.

6. Nella pagina GitHub web, scegli Registra applicazione per registrare una nuova OAuth applicazione nella tua GitHub organizzazione.

7. Utilizza le informazioni contenute nella GitHub OAuth pagina per compilare i prompt rosa create idp interattivi rimanenti, sostituendo <GITHUB_CLIENT_ID> e <GITHUB_CLIENT_SECRET> con le credenziali dell'applicazione. GitHub OAuth

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

   Nota

   Potrebbero essere necessari circa due minuti prima che la configurazione del provider di identità diventi attiva. Se hai configurato un cluster-admin utente, puoi eseguire il oc get pods -n openshift-authentication --watch comando per guardare i OAuth pod ridistribuirsi con la configurazione aggiornata.

8. Verifica che il provider di identità sia stato configurato correttamente.

   rosa list idps --cluster=<CLUSTER_NAME>

Concedi all'utente l'accesso a un cluster

Puoi concedere a un utente l'accesso al tuo cluster aggiungendolo al provider di identità configurato.

La procedura seguente aggiunge un utente a un' GitHub organizzazione configurata per la fornitura di identità al cluster.

1. Vai su github.com e accedi al tuo account. GitHub

2. Invita gli utenti che richiedono cluster l'accesso alla tua organizzazione. GitHub Per ulteriori informazioni, consulta Invitare gli utenti a unirsi alla propria organizzazione nella GitHub documentazione.

Configura le cluster-admin autorizzazioni

1. Concedi le cluster-admin autorizzazioni utilizzando il seguente comando. Sostituisci <IDP_USER_NAME> e <CLUSTER_NAME> con il nome utente e del cluster.

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

2. Verifica che l'utente sia elencato come membro del cluster-admins gruppo.

   rosa list users --cluster=<CLUSTER_NAME>

Configura le dedicated-admin autorizzazioni

1. Concedi le dedicated-admin autorizzazioni con il seguente comando. Sostituisci <IDP_USER_NAME> e <CLUSTER_NAME> con il tuo cluster nome utente.

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

2. Verifica che l'utente sia elencato come membro del cluster-admins gruppo.

   rosa list users --cluster=<CLUSTER_NAME>

Accedi a cluster tramite la Red Hat Hybrid Cloud Console

Dopo aver creato un utente cluster amministratore o aggiunto un utente al provider di identità configurato, puoi accedere al tuo cluster tramite la Red Hat Hybrid Cloud Console.

1. Ottieni la console URL adatta a te cluster usando il seguente comando. Sostituisci <CLUSTER_NAME> con il nome del tuo cluster.

   rosa describe cluster -c <CLUSTER_NAME> | grep Console

2. Vai alla console URL nell'output e accedi.

   • Se hai creato un cluster-admin utente, accedi utilizzando le credenziali fornite.

   • Se hai configurato un provider di identità per il tuo cluster, scegli il nome del provider di identità nella finestra di dialogo Accedi con... e completa tutte le richieste di autorizzazione presentate dal tuo provider.

Distribuisci un'applicazione dal Developer Catalog

Dalla Red Hat Hybrid Cloud Console, puoi implementare un'applicazione di test del Developer Catalog ed esporla con un percorso.

1. Accedi a Red Hat Hybrid Cloud Console e scegli il cluster in cui vuoi implementare l'app.

2. Nella pagina del cluster, scegli Open console.

3. Nella prospettiva dell'amministratore, scegli Home > Progetti > Crea progetto.

4. Immettete un nome per il progetto e, facoltativamente, aggiungete un nome visualizzato e una descrizione.

5. Scegli Crea per creare il progetto.

6. Passa alla prospettiva dello sviluppatore e scegli +Aggiungi. Assicurati che il progetto selezionato sia quello appena creato.

7. Nella finestra di dialogo Developer Catalog, scegli Tutti i servizi.

8. Nella pagina del catalogo per sviluppatori, scegliete Lingue > JavaScriptdal menu.

9. Scegliete Node.js, quindi scegliete Crea applicazione per aprire la pagina Crea applicazione Source-to-Image.

   Nota

   Potrebbe essere necessario scegliere Cancella tutti i filtri per visualizzare l'opzione Node.js.

10. Nella sezione Git, scegli Try Sample.

11. Nel campo Nome, aggiungi un nome univoco.

12. Scegli Crea.

    Nota

    La distribuzione della nuova applicazione richiede diversi minuti.

13. Una volta completata la distribuzione, scegli il percorso URL per l'applicazione.

    Si apre una nuova scheda nel browser con un messaggio simile al seguente.

    Welcome to your Node.js application on OpenShift

14. (Facoltativo) Eliminare l'applicazione e ripulire le risorse.

    1. Nella prospettiva dell'amministratore, scegliete Home > Progetti.

    2. Apri il menu delle azioni per il tuo progetto e scegli Elimina progetto.

Revoca le cluster-admin autorizzazioni a un utente

1. Revoca le cluster-admin autorizzazioni utilizzando il seguente comando. Sostituisci <IDP_USER_NAME> e <CLUSTER_NAME> con il tuo nome utente. cluster

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

2. Verifica che l'utente non sia elencato come membro del cluster-admins gruppo.

   rosa list users --cluster=<CLUSTER_NAME>

Revoca le dedicated-admin autorizzazioni a un utente

1. Revoca le dedicated-admin autorizzazioni utilizzando il seguente comando. Sostituisci <IDP_USER_NAME> e <CLUSTER_NAME> con il tuo nome utente. cluster

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

2. Verifica che l'utente non sia elencato come membro del dedicated-admins gruppo.

   rosa list users --cluster=<CLUSTER_NAME>

Revoca l'accesso utente a un cluster

È possibile revocare cluster l'accesso a un utente del provider di identità rimuovendolo dal provider di identità configurato.

Puoi configurare diversi tipi di provider di identità per il tuo. cluster La procedura seguente revoca cluster l'accesso a un membro di un' GitHub organizzazione.

1. Vai su github.com e accedi al tuo account. GitHub

2. Rimuovi l'utente dalla tua organizzazione. GitHub Per ulteriori informazioni, consulta Rimuovere un membro dall'organizzazione nella GitHub documentazione.

Eliminare un cluster e AWS STS delle risorse

Puoi usare il ROSA CLI per eliminare un file cluster che usa AWS Security Token Service (AWS STS). È inoltre possibile utilizzare il ROSA CLI per eliminare i IAM ruoli e il OIDC provider creati da ROSA. Per eliminare le IAM politiche create da ROSA, è possibile utilizzare la IAM console.

Importante

IAM i ruoli e le politiche creati da ROSA potrebbero essere utilizzati da altri ROSA cluster nello stesso account.

1. Elimina cluster e guarda i log. Sostituisci <CLUSTER_NAME> con il nome o l'ID del tuo cluster.

   rosa delete cluster --cluster=<CLUSTER_NAME> --watch

   Importante

   È necessario cluster attendere l'eliminazione completa prima di rimuovere i IAM ruoli, le politiche e il OIDC provider. I IAM ruoli dell'account sono necessari per eliminare le risorse create dal programma di installazione. I IAM ruoli degli operatori sono necessari per ripulire le risorse create dagli OpenShift operatori. Gli operatori utilizzano il OIDC provider per l'autenticazione.

2. Eliminare il OIDC provider utilizzato cluster dagli operatori per l'autenticazione eseguendo il comando seguente.

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

3. Eliminare i ruoli degli operatori specifici del cluster. IAM

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

4. Eliminare i IAM ruoli dell'account utilizzando il comando seguente. Sostituisci <PREFIX> con il prefisso dei IAM ruoli dell'account da eliminare. Se hai specificato un prefisso personalizzato durante la creazione dei IAM ruoli dell'account, specifica il prefisso predefinitoManagedOpenShift.

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

5. Elimina le IAM politiche create da. ROSA

   1. Accedi alla console di IAM.

   2. Nel menu a sinistra, sotto Gestione degli accessi, scegli Politiche.

   3. Seleziona la politica che desideri eliminare e scegli Azioni > Elimina.

   4. Inserisci il nome della politica e scegli Elimina.

   5. Ripeti questo passaggio per eliminare ciascuna delle IAM politiche per cluster.