Crea un cluster ROSA classico che utilizza AWS PrivateLink - Servizio Red Hat OpenShift su AWS

Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.

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, consultaROSA architettura. Sia per uso pubblico che privato cluster configurazioni, il OpenShift cluster ha accesso a Internet e la privacy è impostata sui carichi di lavoro delle applicazioni a livello di applicazione.

Se hai bisogno di entrambi cluster e che i carichi di lavoro delle applicazioni siano privati, puoi configurare AWS PrivateLink con ROSA classic. AWS PrivateLink è una tecnologia scalabile e altamente disponibile che ROSA utilizza per creare una connessione privata tra ROSA servizio e risorse del cluster in AWS account 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 al cluster AWS PrivateLink endpoint.

Per ulteriori informazioni sull' AWS PrivateLink, vedi Cos'è AWS PrivateLink?

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

Crea Amazon VPC architecture

La procedura seguente crea Amazon VPC architettura che può essere utilizzata per ospitare un cluster. Tutti cluster le risorse sono ospitate nella sottorete privata. La sottorete pubblica indirizza il traffico in uscita dalla sottorete privata attraverso un NAT gateway verso la rete Internet pubblica. Questo esempio utilizza il blocco per CIDR 10.0.0.0/16 Amazon VPC. Tuttavia, puoi scegliere un CIDR blocco diverso. Per ulteriori informazioni, vedi VPCdimensionamento.

Importante

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

Amazon VPC console
  1. Aprire Amazon VPC console.

  2. Nella VPC dashboard, scegli Crea VPC.

  3. Per Risorse da creare, scegli VPCe altro ancora.

  4. Mantieni selezionata la generazione automatica dei tag nome per creare i tag Nome per VPC le risorse o deselezionala per fornire i tuoi tag Nome per le VPC risorse.

  5. Per IPv4CIDRblocco, inserisci un intervallo di IPv4 indirizzi per. VPC Un VPC deve avere un intervallo di IPv4 indirizzi.

  6. (Facoltativo) Per supportare IPv6 il traffico, scegli IPv6CIDRblock, blocco fornito da Amazon IPv6 CIDR.

  7. Lascia Tenancy come. Default

  8. Per Numero di zone di disponibilità (AZs), scegli il numero che desideri. Per le implementazioni Multi-AZ, ROSA richiede tre zone di disponibilità. Per scegliere le AZs sottoreti, espandi Personalizza. AZs

    Nota

    Medio ROSA i tipi di istanza sono disponibili solo in zone di disponibilità selezionate. Puoi utilizzare il plugin ROSA CLIrosa list instance-typescomando per elencare tutto ROSA tipi di istanze disponibili. Per verificare se un tipo di istanza è disponibile per una determinata zona di disponibilità, usa AWS CLI comandoaws ec2 describe-instance-type-offerings --location-type availability-zone --filters Name=location,Values=<availability_zone> --region <region> --output text | egrep "<instance_type>".

  9. Per configurare le sottoreti, scegli i valori per Numero di sottoreti pubbliche e Numero di sottoreti private. Per scegliere gli intervalli di indirizzi IP per le sottoreti, espandi Personalizza i blocchi di CIDR sottoreti.

    Nota

    ROSA richiede che i clienti configurino almeno una sottorete privata per zona di disponibilità utilizzata per creare i cluster.

  10. Per concedere alle risorse della sottorete privata l'accesso alla rete Internet pubblicaIPv4, per i NATgateway, scegli il numero di gateway AZs in cui creare i gateway. NAT In produzione, consigliamo di implementare un NAT gateway in ogni AZ con risorse che richiedono l'accesso alla rete Internet pubblica.

  11. (Facoltativo) Se è necessario accedere Amazon S3 direttamente dal tuoVPC, scegli VPCendpoint, S3 Gateway.

  12. Lascia selezionate le DNS opzioni predefinite. ROSA richiede DNS il supporto del nome host su. VPC

  13. Scegli Crea VPC.

AWS CLI
  1. 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'VPCID. Di seguito è riportato un esempio di output.

    vpc-1234567890abcdef0
  2. Memorizza l'VPCID in una variabile di ambiente.

    export VPC_ID=vpc-1234567890abcdef0
  3. Crea un Name tag perVPC, utilizzando la variabile di VPC_ID ambiente.

    aws ec2 create-tags --resources $VPC_ID --tags Key=Name,Value=MyVPC
  4. Abilita DNS il supporto del nome host su. VPC

    aws ec2 modify-vpc-attribute \ --vpc-id $VPC_ID \ --enable-dns-hostnames
  5. Crea una sottorete pubblica e privata inVPC, specificando le zone di disponibilità in cui devono essere create le risorse.

    Importante

    ROSA richiede che i clienti configurino almeno una sottorete privata per ogni zona di disponibilità utilizzata per creare i cluster. Per le implementazioni Multi-AZ, sono necessarie tre zone di disponibilità. Se questi requisiti non vengono soddisfatti, la creazione del cluster non riesce.

    Nota

    Medio ROSA i tipi di istanza sono disponibili solo in zone di disponibilità selezionate. Puoi utilizzare il plugin ROSA CLIrosa list instance-typescomando per elencare tutto ROSA tipi di istanze disponibili. Per verificare se un tipo di istanza è disponibile per una determinata zona di disponibilità, usa AWS CLI comandoaws 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. Memorizza la sottorete pubblica e privata IDs in variabili di ambiente.

    export PUBLIC_SUB=subnet-1234567890abcdef0 export PRIVATE_SUB=subnet-0987654321fedcba0
  7. Crea un gateway Internet e una tabella di routing per il traffico in uscita. Crea una tabella di routing e un indirizzo IP elastico per il traffico privato.

    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. IDsMemorizza le variabili di ambiente.

    export IGW=igw-1234567890abcdef0 export PUBLIC_RT=rtb-0987654321fedcba0 export EIP=eipalloc-0be6ecac95EXAMPLE export PRIVATE_RT=rtb-1234567890abcdef0
  9. Collega il gateway Internet aVPC.

    aws ec2 attach-internet-gateway \ --vpc-id $VPC_ID \ --internet-gateway-id $IGW
  10. Associa la tabella delle rotte pubbliche alla sottorete pubblica e configura il traffico da instradare verso il gateway 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. Crea il NAT gateway e associalo all'indirizzo IP elastico per abilitare il traffico verso la sottorete privata.

    aws ec2 create-nat-gateway \ --subnet-id $PUBLIC_SUB \ --allocation-id $EIP \ --query NatGateway.NatGatewayId \ --output text
  12. Associa la tabella di routing privata alla sottorete privata e configura il traffico per l'instradamento verso il NAT gateway.

    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. (Facoltativo) Per le implementazioni Multi-AZ, ripeti i passaggi precedenti per configurare altre due zone di disponibilità con sottoreti pubbliche e private.

Puoi utilizzare il plugin ROSA CLIe AWS PrivateLink per creare un 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 VPC del CIDR tuo.

La procedura seguente utilizza il rosa create cluster comando per creare un ROSA classico cluster. Per creare un Multi-AZ cluster, specificate --multi-az nel comando, quindi selezionate la sottorete privata IDs che desiderate utilizzare quando richiesto.

Nota

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

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

  1. Crea il file richiesto IAM ruoli e politiche dell'account che utilizzano --mode auto o--mode manual.

    • rosa create account-roles --classic --mode auto
    • rosa create account-roles --classic --mode manual
      Nota

      Se il token di accesso offline è scaduto, ROSA CLIemette un messaggio di errore che indica che il token di autorizzazione deve essere aggiornato. Per la procedura di risoluzione dei problemi, consulta. Risolvi i problemi relativi ai token di ROSA CLI accesso offline scaduti

  2. Crea un cluster eseguendo uno dei seguenti comandi.

    • Single-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
      Nota

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

  3. Crea il cluster operatore IAM ruoli seguendo le istruzioni interattive.

    rosa create operator-roles --interactive -c <CLUSTER_NAME>
  4. Creare il provider OpenID Connect (OIDC) il cluster gli operatori utilizzano per autenticarsi.

    rosa create oidc-provider --interactive -c <CLUSTER_NAME>
  5. Controlla lo stato del tuo cluster.

    rosa describe cluster -c <CLUSTER_NAME>
    Nota

    Potrebbero essere necessari fino a 40 minuti per cluster Statecampo per mostrare lo ready stato. Se il provisioning fallisce o non viene visualizzato ready dopo 40 minuti, vediRisoluzione dei problemi. Per contattare AWS Support o il supporto Red Hat per ricevere assistenza, consultaOttenere ROSA assistenza.

  6. Monitora lo stato di avanzamento del cluster creazione guardando i log dell' OpenShift installatore.

    rosa logs install -c <CLUSTER_NAME> --watch

Cluster che utilizzano AWS PrivateLink crea una zona ospitata pubblica e una zona ospitata privata in Route 53. Record all'interno del Route 53 la zona ospitata privata è risolvibile solo all'interno della zona a VPC cui è assegnata.

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 sull' AWS zone private ospitate, vedi Lavorare con le zone private. Per ulteriori informazioni sulle zone ospitate pubbliche, consulta Lavorare con le zone ospitate pubbliche.

  1. Per consentire la memorizzazione api.<cluster_domain> e la risoluzione di record *.apps.<cluster_domain> al di fuori diVPC, configura un Route 53 Resolver endpoint in entrata.

    Nota

    Quando si configura un endpoint in entrata, è necessario specificare un minimo di due indirizzi IP per la ridondanza. Consigliamo di specificare indirizzi IP in almeno due zone di disponibilità. È anche possibile specificare facoltativamente ulteriori indirizzi IP in quelle o in altre zone di disponibilità.

  2. Quando configuri l'endpoint in entrata, seleziona le sottoreti private VPC utilizzate durante la creazione del cluster.

Dopo il Route 53 Resolver un endpoint interno è associato e operativo, configurate l'DNSinoltro in modo che DNS le interrogazioni 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.

ROSA include un OAuth server integrato. Dopo il tuo ROSA cluster è stato creato, è necessario configurarlo OAuth per utilizzare un provider di identità. Puoi quindi aggiungere utenti al tuo provider di identità configurato per concedere loro l'accesso al cluster. È possibile concedere tali utenti cluster-admin o dedicated-admin autorizzazioni in base alle esigenze.

Puoi configurare diversi tipi di provider di identità per 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 disponi di un' GitHub organizzazione da utilizzare per la fornitura di identità per ROSA cluster, creane uno. Per ulteriori informazioni, consulta i passaggi indicati nella GitHub documentazione.

  3. Utilizzo di ROSA CLI, configura un provider di identità per il tuo cluster eseguendo il comando seguente.

    rosa create idp --cluster=<CLUSTER_NAME> --interactive
  4. Segui le istruzioni di configurazione nell'output per limitare 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. Apri il file URL nell'output, sostituendolo <GITHUB_ORG_NAME> con il nome della tua 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>

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

La procedura seguente aggiunge un utente a un' GitHub organizzazione configurata per il provisioning delle identità al cluster.

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

  2. Invita gli utenti che lo richiedono cluster accesso alla tua GitHub organizzazione. Per ulteriori informazioni, vedi Invitare gli utenti a entrare a far parte della tua organizzazione nella GitHub documentazione.

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

    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>

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

  1. Procurati la console URL per 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 provider.

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

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

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

    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>

Puoi revocare cluster accedere a un utente del provider di identità rimuovendolo dal provider di identità configurato.

Puoi configurare diversi tipi di provider di identità per cluster. La seguente procedura revoca cluster accesso per 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.

Puoi utilizzare il plugin ROSA CLIeliminare un cluster che usa AWS Security Token Service (AWS STS). Puoi anche usare il ROSA CLIper eliminare il IAM ruoli e OIDC provider creati da ROSA. Per eliminare il IAM politiche create da ROSA, è possibile utilizzare il IAM console.

Importante

IAM ruoli e politiche creati da ROSA potrebbe essere usato da altri ROSA cluster nello stesso account.

  1. Elimina le foto o i video 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

    Devi aspettare il cluster da eliminare completamente prima di rimuovere il IAM ruoli, politiche e 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 che cluster gli operatori utilizzano per autenticarsi eseguendo il comando seguente.

    rosa delete oidc-provider -c <CLUSTER_ID> --mode auto
  3. Eliminare l'operatore specifico del cluster IAM ruoli.

    rosa delete operator-roles -c <CLUSTER_ID> --mode auto
  4. Eliminare i IAM ruoli dell'account utilizzando il seguente comando. 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 foto o i video IAM politiche create da ROSA.

    1. Effettua il login a IAM console.

    2. Nel menu a sinistra in 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.