

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 con HCP utilizzando la CLI ROSA
<a name="getting-started-hcp"></a>

Le sezioni seguenti descrivono come iniziare a usare ROSA con piani di controllo ospitati (ROSA con HCP) utilizzando AWS STS e la ROSA CLI. Per i passaggi per creare un cluster ROSA con HCP utilizzando Terraform, consultate [la](https://docs.openshift.com/rosa/rosa_hcp/terraform/rosa-hcp-creating-a-cluster-quickly-terraform.html) documentazione di Red Hat. [Per saperne di più sul provider Terraform per la creazione di ROSA cluster, consulta la documentazione Terraform.](https://registry.terraform.io/providers/terraform-redhat/rhcs/latest/docs)

La ROSA CLI utilizza la `auto` modalità o la `manual` modalità per creare IAM le risorse e la configurazione OpenID Connect (OIDC) necessarie per creare un. ROSA cluster`auto`mode crea automaticamente i IAM ruoli e le politiche richiesti e il provider OIDC. `manual`mode emette i AWS CLI comandi necessari per creare le IAM risorse manualmente. Utilizzando `manual` mode, è possibile rivedere i AWS CLI comandi generati prima di eseguirli manualmente. Con `manual` la modalità, puoi anche passare i comandi a un altro amministratore o gruppo dell'organizzazione in modo che possa creare le risorse.

Le procedure descritte in questo documento utilizzano la `auto` modalità ROSA CLI per creare le IAM risorse richieste e la configurazione OIDC per ROSA con HCP. Per ulteriori opzioni per iniziare, consulta. [Inizia con ROSA](getting-started.md)

**Topics**
+ [Prerequisiti](#getting-started-hcp-prereqs)
+ [Creare un'architettura Amazon VPC](#create-vpc-hcp)
+ [Creare i IAM ruoli richiesti e la configurazione OpenID Connect](#create-iam-roles-oidc-hcp)
+ [Crea un cluster ROSA con HCP utilizzando la ROSA CLI e AWS STS](#create-hcp-cluster-cli)
+ [Configura un provider di identità e concedi l'accesso cluster](#configure-oidc-hcp-cli)
+ [Concedi all'utente l'accesso a un cluster](#grant-user-access-hcp-cli)
+ [Configurazione delle autorizzazioni `cluster-admin`](#configure-cluster-admin-hcp)
+ [Configurazione delle autorizzazioni `dedicated-admin`](#configure-dedicated-admin-hcp)
+ [Accedi a cluster tramite la Red Hat Hybrid Cloud Console](#console-access-hcp-cli)
+ [Distribuisci un'applicazione dal Developer Catalog](#deploy-app-hcp-cli)
+ [Revoca le `cluster-admin` autorizzazioni a un utente](#revoke-cluster-admin-hcp-cli)
+ [Revoca le `dedicated-admin` autorizzazioni a un utente](#revoke-dedicated-admin-hcp-cli)
+ [Revoca l'accesso utente a un cluster](#revoke-user-hcp-cli)
+ [Eliminare un cluster e AWS STS delle risorse](#delete-cluster-hcp-cli)

## Prerequisiti
<a name="getting-started-hcp-prereqs"></a>

Completa le azioni preliminari elencate in[Configurazione per l'uso ROSA](set-up.md).

## Creare un'architettura Amazon VPC
<a name="create-vpc-hcp"></a>

La procedura seguente crea un' Amazon VPC architettura che può essere utilizzata per ospitare un cluster. Tutte le cluster risorse sono ospitate nella sottorete privata. La sottorete pubblica indirizza il traffico in uscita dalla sottorete privata attraverso un gateway NAT verso la rete Internet pubblica. Questo esempio utilizza il blocco CIDR per. `10.0.0.0/16` Amazon VPC Tuttavia, puoi scegliere un blocco CIDR diverso. Per ulteriori informazioni, consulta [VPC Sizing (Dimensionamento del VPC)](https://docs.aws.amazon.com/vpc/latest/userguide/configure-your-vpc.html#vpc-sizing).

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

**Example**  

1. Installa la CLI Terraform. Per ulteriori informazioni, consulta le [istruzioni di installazione nella documentazione di Terraform](https://developer.hashicorp.com/terraform/tutorials/aws-get-started/install-cli).

1. Apri una sessione terminale e clona il repository VPC Terraform.

   ```
   git clone https://github.com/openshift-cs/terraform-vpc-example
   ```

1. Vai alla directory creata.

   ```
   cd terraform-vpc-example
   ```

1. Avvia il file Terraform.

   ```
   terraform init
   ```

   Una volta completata, la CLI restituisce un messaggio indicante che Terraform è stato inizializzato con successo.

1. Per creare un piano Terraform basato sul modello esistente, esegui il seguente comando. Regione AWS Deve essere specificato. Facoltativamente, è possibile scegliere di specificare un nome di cluster.

   ```
   terraform plan -out rosa.tfplan -var region=<region>
   ```

   Una volta eseguito il comando, viene aggiunto un `rosa.tfplan` file alla `hypershift-tf` directory. Per opzioni più dettagliate, consulta [il file README del repository VPC di Terraform](https://github.com/openshift-cs/terraform-vpc-example/blob/main/README.md).

1. Applica il file del piano per creare il VPC.

   ```
   terraform apply rosa.tfplan
   ```

   Una volta completata, la CLI ha restituito un messaggio di successo che verifica le risorse aggiunte.

   1. (Facoltativo) Crea variabili di ambiente per la sottorete IDs privata, pubblica e del pool di macchine fornita da Terraform da utilizzare durante la creazione del cluster ROSA con HCP.

      ```
      export SUBNET_IDS=$(terraform output -raw cluster-subnets-string)
      ```

   1. (Facoltativo) Verificate che le variabili di ambiente siano state impostate correttamente.

      ```
      echo $SUBNET_IDS
      ```

1. Apri la [Amazon VPC console](https://console.aws.amazon.com/vpc).

1. Nella scheda VPC, scegli **Create VPC (Crea modulo VPC)**.

1. Per **Risorse da creare**, scegli **VPC e altro**.

1. Per creare tag dei nomi per le risorse VPC, tieni selezionata **Generazione automatica dei tag dei nomi** altrimenti deselezionala per scegliere autonomamente tag dei nomi per le risorse VPC.

1. Per il **blocco IPv4 CIDR**, inserisci un intervallo di IPv4 indirizzi per il VPC. Un VPC deve avere un intervallo di IPv4 indirizzi.

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

1. **Lascia Tenancy come.** `Default`

1. Per **Numero di zone di disponibilità (AZs)**, scegli il numero che desideri. Per le implementazioni Multi-AZ, sono ROSA necessarie tre zone di disponibilità. **Per scegliere le AZs sottoreti, espandi Personalizza. AZs**
**Nota**  
Alcuni tipi di ROSA istanze sono disponibili solo in zone di disponibilità selezionate. È possibile utilizzare il `rosa list instance-types` comando ROSA CLI per elencare tutti i tipi di ROSA istanze disponibili. Per verificare se un tipo di istanza è disponibile per una determinata zona di disponibilità, usa il AWS CLI comando`aws ec2 describe-instance-type-offerings --location-type availability-zone --filters Name=location,Values=<availability_zone> --region <region> --output text | egrep "<instance_type>"`.

1. Per configurare le sottoreti, scegli i valori per **Numero di sottoreti pubbliche** e **Numero di sottoreti private**. Per scegliere gli intervalli di indirizzi IP delle sottoreti, espandi **Personalizza i blocchi CIDR delle sottoreti**.
**Nota**  
ROSA con HCP richiede che i clienti configurino almeno una sottorete pubblica e privata per ogni zona di disponibilità utilizzata per creare i cluster.

1. Per concedere alle risorse della sottorete privata l'accesso alla rete Internet pubblica IPv4, per i gateway **NAT, scegliete il numero di gateway NAT** AZs in cui creare i gateway NAT. In fase di produzione, è preferibile implementare un gateway NAT in ogni zona di disponibilità con risorse che richiedono l’accesso alla rete Internet pubblica.

1. (Facoltativo) Se devi accedere Amazon S3 direttamente dal tuo VPC, scegli gli **endpoint VPC, S3 Gateway**.

1. Lascia selezionate le opzioni DNS predefinite. ROSA richiede il supporto del nome host DNS sul VPC.

1. Espandi **Tag aggiuntivi**, scegli **Aggiungi nuovo tag** e aggiungi le seguenti chiavi di tag. ROSA utilizza controlli automatici di preflight che verificano l'utilizzo di questi tag.
   +  **Chiave**: `kubernetes.io/role/elb` 
   +  **Chiave**: `kubernetes.io/role/internal-elb` 

1. Seleziona **Crea VPC**.

1. Creare un VPC con un blocco CIDR `10.0.0.0/16`.

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

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

   ```
   vpc-1234567890abcdef0
   ```

1. Memorizza l'ID VPC in una variabile di ambiente.

   ```
   export VPC_ID=vpc-1234567890abcdef0
   ```

1. Crea un `Name` tag per il VPC, utilizzando la variabile di `VPC_ID` ambiente.

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

1. Abilita il supporto dei nomi host DNS sul VPC.

   ```
   aws ec2 modify-vpc-attribute \
       --vpc-id $VPC_ID \
       --enable-dns-hostnames
   ```

1. Crea una sottorete pubblica e privata nel VPC, specificando le zone di disponibilità in cui devono essere create le risorse.
**Importante**  
ROSA con HCP richiede che i clienti configurino almeno una sottorete pubblica e 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**  
Alcuni tipi di ROSA istanze sono disponibili solo in zone di disponibilità selezionate. È possibile utilizzare il `rosa list instance-types` comando ROSA CLI per elencare tutti i tipi di ROSA istanze disponibili. Per verificare se un tipo di istanza è disponibile per una determinata zona di disponibilità, usa il AWS CLI comando`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 \
       --cidr-block 10.0.1.0/24 \
       --availability-zone us-east-1a \
       --query Subnet.SubnetId \
       --output text
   aws ec2 create-subnet \
       --vpc-id $VPC_ID \
       --cidr-block 10.0.0.0/24 \
       --availability-zone us-east-1a \
       --query Subnet.SubnetId \
       --output text
   ```

1. Memorizza la sottorete pubblica e privata IDs in variabili di ambiente.

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

1. Crea i seguenti tag per le tue sottoreti VPC. ROSA utilizza controlli automatici di preflight che verificano l'utilizzo di questi tag.
**Nota**  
È necessario etichettare almeno una sottorete privata e, se applicabile, una sottorete pubblica.

   ```
   aws ec2 create-tags --resources $PUBLIC_SUB --tags Key=kubernetes.io/role/elb,Value=1
   aws ec2 create-tags --resources $PRIVATE_SUB --tags Key=kubernetes.io/role/internal-elb,Value=1
   ```

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

1.  IDs Memorizza le variabili di ambiente.

   ```
   export IGW=igw-1234567890abcdef0
   export PUBLIC_RT=rtb-0987654321fedcba0
   export EIP=eipalloc-0be6ecac95EXAMPLE
   export PRIVATE_RT=rtb-1234567890abcdef0
   ```

1. Collega il gateway Internet al VPC.

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

1. Associate la tabella delle rotte pubbliche alla sottorete pubblica e configurate il traffico da indirizzare 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
   ```

1. Crea il gateway NAT 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
   ```

1. Associa la tabella di routing privata alla sottorete privata e configura il traffico per l'instradamento verso il gateway NAT.

   ```
   aws ec2 associate-route-table \
       --subnet-id $PRIVATE_SUB \
       --route-table-id $PRIVATE_RT
   aws ec2 create-route \
       --route-table-id $PRIVATE_RT \
       --destination-cidr-block 0.0.0.0/0 \
       --gateway-id $NATGW
   ```

1. (Facoltativo) Per le implementazioni Multi-AZ, ripeti i passaggi precedenti per configurare altre due zone di disponibilità con sottoreti pubbliche e private.

## Creare i IAM ruoli richiesti e la configurazione OpenID Connect
<a name="create-iam-roles-oidc-hcp"></a>

Prima di creare un cluster ROSA con HCP, è necessario creare i IAM ruoli e le politiche necessari e la configurazione OpenID Connect (OIDC). Per ulteriori informazioni sui IAM ruoli e le politiche di ROSA con HCP, vedere. [AWS politiche gestite per ROSA](security-iam-awsmanpol.md)

Questa procedura utilizza la `auto` modalità ROSA CLI per creare automaticamente la configurazione OIDC necessaria per creare un cluster ROSA con HCP.

1. Crea i ruoli e le politiche dell' IAM account richiesti. Il `--force-policy-creation` parametro aggiorna tutti i ruoli e le politiche esistenti presenti. Se non sono presenti ruoli e politiche, il comando crea invece queste risorse.

   ```
   rosa create account-roles --force-policy-creation
   ```
**Nota**  
Se il token di accesso offline è scaduto, la ROSA CLI emette 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 accesso offline scaduti della ROSA CLI](troubleshooting-rosa.md#rosa-cli-expired-token)

1. Crea la configurazione OpenID Connect (OIDC) che abilita l'autenticazione degli utenti nel cluster. Questa configurazione è registrata per essere utilizzata con OpenShift Cluster Manager (OCM).

   ```
   rosa create oidc-config --mode=auto
   ```

1. Copia l'ID di configurazione OIDC fornito nell'output della ROSA CLI. L'ID di configurazione OIDC deve essere fornito in seguito per creare il cluster ROSA con HCP.

1. Per verificare le configurazioni OIDC disponibili per i cluster associati all'organizzazione degli utenti, esegui il comando seguente.

   ```
   rosa list oidc-config
   ```

1. Crea i ruoli IAM operatore richiesti, sostituendoli `<OIDC_CONFIG_ID>` con l'ID di configurazione OIDC copiato in precedenza.  
**Example**  
**Importante**  
È necessario fornire un prefisso in `<PREFIX_NAME>` quando si creano i ruoli Operator. In caso contrario si genera un errore.

   ```
   rosa create operator-roles --prefix <PREFIX_NAME> --oidc-config-id <OIDC_CONFIG_ID> --hosted-cp
   ```

1. Per verificare che i ruoli IAM dell'operatore siano stati creati, esegui il comando seguente:

   ```
   rosa list operator-roles
   ```

## Crea un cluster ROSA con HCP utilizzando la ROSA CLI e AWS STS
<a name="create-hcp-cluster-cli"></a>

È possibile creare un ROSA con HCP cluster utilizzando AWS Security Token Service (AWS STS) e la `auto` modalità fornita nella ROSA CLI. Hai la possibilità di creare un cluster con un'API pubblica e Ingress o un'API privata e Ingress.

È possibile creare una cluster con una singola zona di disponibilità (Single-AZ) o più zone di disponibilità (Multi-AZ). In entrambi i casi, il valore CIDR della macchina deve corrispondere al valore CIDR del VPC.

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

1. Crea un cluster ROSA con HCP con uno dei seguenti comandi.
   + Crea un cluster ROSA con HCP con un'API pubblica e Ingress, specificando il nome del cluster, il prefisso del ruolo dell'operatore, l'ID di configurazione OIDC e la sottorete pubblica e privata. IDs

     ```
     rosa create cluster --cluster-name=<CLUSTER_NAME> --sts --mode=auto --hosted-cp --operator-roles-prefix <OPERATOR_ROLE_PREFIX> --oidc-config-id <OIDC_CONFIG_ID> --subnet-ids=<PUBLIC_SUBNET_ID>,<PRIVATE_SUBNET_ID>
     ```
   + Crea un cluster ROSA con HCP con un'API privata e Ingress, specificando il nome del cluster, il prefisso del ruolo dell'operatore, l'ID di configurazione OIDC e la sottorete privata. IDs

     ```
     rosa create cluster --private --cluster-name=<CLUSTER_NAME> --sts --mode=auto --hosted-cp --subnet-ids=<PRIVATE_SUBNET_ID>
     ```

1.  cluster Controlla lo stato del tuo.

   ```
   rosa describe cluster -c <CLUSTER_NAME>
   ```
**Nota**  
Se il processo di creazione fallisce o il `State` campo non diventa pronto dopo 10 minuti, consulta[Risoluzione dei problemi](troubleshooting-rosa.md).  
Per contattare il Supporto nostro supporto Red Hat per ricevere assistenza, consulta[Ottenere ROSA assistenza](rosa-support.md).

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

   ```
   rosa logs install -c <CLUSTER_NAME> --watch
   ```

## Configura un provider di identità e concedi l'accesso cluster
<a name="configure-oidc-hcp-cli"></a>

 ROSA include un OAuth server integrato. Dopo la creazione, 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 ROSA cluster. I tipi supportati includono GitHub Enterprise GitHub, Google GitLab, LDAP, OpenID HTPasswd Connect e provider di identità.

**Importante**  
Il provider di HTPasswd identità è incluso solo per consentire la creazione di un singolo utente amministratore statico. HTPasswd non è 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à](https://access.redhat.com/documentation/en-us/red_hat_openshift_service_on_aws/4/html/install_rosa_classic_clusters/rosa-sts-config-identity-providers) per. AWS STS

1. Vai su [github.com](https://github.com/) e accedi al tuo account. GitHub 

1. Se non hai un' GitHub organizzazione da utilizzare per la fornitura di identità per la tua cluster azienda, creane una. Per ulteriori informazioni, consulta [i passaggi indicati nella GitHub documentazione](https://docs.github.com/en/organizations/collaborating-with-groups-in-organizations/creating-a-new-organization-from-scratch).

1. Utilizzando la modalità interattiva della ROSA CLI, configura un provider di identità per il tuo cluster.

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

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

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

1. Apri l'URL nell'output, sostituendolo `<GITHUB_ORG_NAME>` con il nome della tua GitHub organizzazione.

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

1. Utilizza le informazioni della GitHub OAuth pagina per compilare i prompt `rosa create idp` interattivi rimanenti eseguendo il comando seguente. Sostituisci `<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 correre `oc get pods -n openshift-authentication --watch` a guardare i OAuth pod ridistribuirsi con la configurazione aggiornata.

1. Verifica che il provider di identità sia configurato correttamente.

   ```
   rosa list idps --cluster=<CLUSTER_NAME>
   ```

## Concedi all'utente l'accesso a un cluster
<a name="grant-user-access-hcp-cli"></a>

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](https://github.com/) e accedi al tuo account. GitHub 

1. Invita gli utenti che richiedono cluster l'accesso alla tua organizzazione. GitHub Per ulteriori informazioni, consulta [Invitare gli utenti a unirsi alla propria organizzazione](https://docs.github.com/en/organizations/managing-membership-in-your-organization/inviting-users-to-join-your-organization) nella GitHub documentazione.

## Configurazione delle autorizzazioni `cluster-admin`
<a name="configure-cluster-admin-hcp"></a>

1. Concedi le `cluster-admin` autorizzazioni eseguendo il comando seguente. 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>
   ```

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

   ```
   rosa list users --cluster=<CLUSTER_NAME>
   ```

## Configurazione delle autorizzazioni `dedicated-admin`
<a name="configure-dedicated-admin-hcp"></a>

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

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

1. Verificate 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
<a name="console-access-hcp-cli"></a>

Accedi al tuo account cluster tramite la Red Hat Hybrid Cloud Console.

1. Ottieni l'URL della console cluster utilizzando il seguente comando. Sostituiscilo `<CLUSTER_NAME>` con il nome del tuo cluster.

   ```
   rosa describe cluster -c <CLUSTER_NAME> | grep Console
   ```

1. Vai all'URL della console nell'output e accedi.

   Nella finestra di dialogo **Accedi con...**, scegli il nome del provider di identità e completa tutte le richieste di autorizzazione presentate dal provider.

## Distribuisci un'applicazione dal Developer Catalog
<a name="deploy-app-hcp-cli"></a>

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](https://console.redhat.com/openshift) e scegli il cluster in cui vuoi implementare l'app.

1. Nella pagina del cluster, scegli **Open console**.

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

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

1. Scegli **Crea** per creare il progetto.

1. Passa alla prospettiva **dello sviluppatore** e scegli **\$1Aggiungi**. Assicurati che il progetto selezionato sia quello appena creato.

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

1. Nella pagina del **catalogo per sviluppatori**, scegliete **Lingue** > **JavaScript**dal menu.

1. Scegliete **Node.js**, quindi scegliete **Crea applicazione** per aprire la pagina **Crea Source-to-Image applicazione**.
**Nota**  
Potrebbe essere necessario scegliere **Cancella tutti i filtri** per visualizzare l'opzione **Node.js**.

1. Nella sezione **Git**, scegli **Try Sample**.

1. Nel campo **Nome**, aggiungi un nome univoco.

1. Scegli **Create** (Crea).
**Nota**  
La distribuzione della nuova applicazione richiede diversi minuti.

1. Una volta completata la distribuzione, scegli l'URL del percorso per l'applicazione.

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

   ```
   Welcome to your Node.js application on OpenShift
   ```

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

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

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

## Revoca le `cluster-admin` autorizzazioni a un utente
<a name="revoke-cluster-admin-hcp-cli"></a>

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

1. 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
<a name="revoke-dedicated-admin-hcp-cli"></a>

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

1. 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
<a name="revoke-user-hcp-cli"></a>

È 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](https://github.com/) e accedi al tuo account. GitHub 

1. Rimuovi l'utente dalla tua organizzazione. GitHub Per ulteriori informazioni, consulta [Rimuovere un membro dall'organizzazione](https://docs.github.com/en/organizations/managing-membership-in-your-organization/removing-a-member-from-your-organization) nella GitHub documentazione.

## Eliminare un cluster e AWS STS delle risorse
<a name="delete-cluster-hcp-cli"></a>

È possibile utilizzare la ROSA CLI per eliminare un messaggio cluster che utilizza AWS Security Token Service ()AWS STS. Puoi anche utilizzare la ROSA CLI per eliminare i IAM ruoli e il provider OIDC creati da. ROSA Per eliminare le IAM politiche create da ROSA, puoi utilizzare la console. IAM 

**Nota**  
 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 attendere l' cluster eliminazione completa prima di rimuovere i IAM ruoli, le politiche e il provider OIDC. I ruoli IAM dell'account sono necessari per eliminare le risorse create dal programma di installazione. I ruoli IAM dell'operatore sono necessari per ripulire le risorse create dagli OpenShift operatori. Gli operatori utilizzano il provider OIDC per l'autenticazione.

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

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

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

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

1. Eliminare i ruoli IAM dell'account utilizzando il seguente comando. Sostituiscili `<PREFIX>` con il prefisso dei ruoli IAM dell'account da eliminare. Se hai specificato un prefisso personalizzato durante la creazione dei ruoli IAM dell'account, specifica il prefisso predefinito`ManagedOpenShift`.

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

1. Elimina le IAM politiche create da. ROSA

   1. Accedi alla console di [IAM](https://console.aws.amazon.com/iamv2/home#/home).

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

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

   1. Inserisci il nome della politica e scegli **Elimina**.

   1. Ripeti questo passaggio per eliminare ciascuna delle policy IAM per cluster.