Questa pagina è stata tradotta dall'API Cloud Translation.

(Facoltativo) Passaggio 12: configura Workload Identity su GKE

GKE solo con Workload Identity: configura Workload Identity

Segui questi passaggi se hai configurato il file delle sostituzioni per Workload Identity su GKE nel passaggio 6: crea le sostituzioni.

Se non utilizzi Workload Identity su GKE, vai alla Parte 3, Passaggio 1: esponi il gateway di ingresso Apigee.

Account di servizio Google Cloud e account di servizio Kubernetes

Un account di servizio Google Cloud è un tipo speciale di account che può essere utilizzato per effettuare chiamate API autorizzate autenticandosi come l'account di servizio stesso. Agli account di servizio Google Cloud possono essere assegnati ruoli e autorizzazioni simili a quelli di un singolo utente. Quando un'applicazione si autentica come account di servizio, ha accesso a tutte le risorse a cui l'account di servizio ha l'autorizzazione di accesso. Per saperne di più sugli account di servizio Google Cloud, consulta Panoramica degli account di servizio.

Hai creato account di servizio Google Cloud per la tua installazione ibrida di Apigee nel Passaggio 4: crea gli account di servizio. Apigee utilizza questi account di servizio per autenticare i componenti ibride.

Gli account di servizio Kubernetes sono simili agli account di servizio Google Cloud. Un account di servizio Kubernetes fornisce un'identità per i processi in esecuzione in un pod e consente di autenticarsi sul server API in modo simile a un utente. Per scoprire di più sugli account di servizio Kubernetes, consulta Configurare gli account di servizio per i pod.

Se nel file delle sostituzioni hai impostato gcp.workloadIdentity.enabled su true, quando i grafici Helm per ogni componente ibrido creeranno gli account di servizio Kubernetes per i componenti quando li installi o esegui l'upgrade, come hai fatto nel passaggio 11: installa Apigee Hybrid utilizzando i grafici Helm.

Quando configuri Workload Identity su GKE, associ gli account di servizio Google Cloud agli account di servizio Kubernetes nel cluster Kubernetes. In questo modo, gli account di servizio Kubernetes possono rubare l'identità degli account di servizio Google Cloud e utilizzare i relativi ruoli e le relative autorizzazioni assegnate per autenticarsi con i componenti ibride.

Segui queste istruzioni per configurare Workload Identity per il tuo progetto.

Preparativi per la configurazione di Workload Identity

Verifica che Workload Identity sia abilitato nel file delle sostituzioni. Deve essere attivato nel file delle sostituzioni nelle seguenti proprietà.
Nota: se hai eseguito la migrazione del cluster dalla gestione apigeectl con lo strumento di migrazione Helm di Apigee hybrid, la sintassi delle sostituzioni per Workload Identity sarà cambiata. Dovrai controllare quanto segue.
- namespace è obbligatorio. Ad esempio:
```
instanceID: "hybrid-instance-1"
namespace: "apigee"
```
- La sintassi per abilitare Workload Identity è diversa per Helm rispetto a apigeectl. Per Helm, gcp.workloadIdentity.enabled sostituisce gcp.workloadIdentityEnabled.
- Se utilizzi un singolo account di servizio (non di produzione) per tutti i componenti, specificalo con: gcp.workloadIdentity.gsa. Ad esempio:
```
  gcp:
    workloadIdentity:
      enabled: true
      gsa: "apigee-non-prod@my-hybrid-project.iam.gserviceaccount.com"
  
```
- Se utilizzi un account di servizio separato per ogni componente (installazioni di produzione), specifica l'account di servizio con la proprietà gsa del componente. Ad esempio:
```
  logger:
    gsa: "apigee-logger@my-hybrid-project.iam.gserviceaccount.com"
  
```
Consulta: gcp.workloadIdentity.enabled.
Verifica che la configurazione gcloud corrente sia impostata sull'ID progetto Google Cloud con il seguente comando:
```
gcloud config get project
```

Se necessario, imposta la configurazione attuale di gcloud:

gcloud config set project $PROJECT_ID

Verifica che Workload Identity sia abilitato per il tuo cluster GKE. Quando hai creato il cluster nel passaggio 1: creazione di un cluster, il passaggio 6 era Abilita Workload Identity. Puoi verificare se Workload Identity è abilitato eseguendo il seguente comando:

Cluster a livello di regione

gcloud container clusters describe $CLUSTER_NAME \
  --region $CLUSTER_LOCATION \
  --project $PROJECT_ID \
  --flatten 'workloadIdentityConfig'

Cluster zonali

gcloud container clusters describe $CLUSTER_NAME \
  --zone $CLUSTER_LOCATION \
  --project $PROJECT_ID \
  --flatten 'workloadIdentityConfig'

L'output dovrebbe avere l'aspetto seguente:

  ---
  workloadPool: PROJECT_ID.svc.id.goog

Se nei risultati viene visualizzato null, esegui il seguente comando per abilitare Workload Identity per il cluster:

Cluster a livello di regione

gcloud container clusters update $CLUSTER_NAME \
  --workload-pool=$PROJECT_ID.svc.id.goog \
  --project $PROJECT_ID \
  --region $CLUSTER_LOCATION

Cluster zonali

gcloud container clusters update  $CLUSTER_NAME \
  --workload-pool=$PROJECT_ID.svc.id.goog \
  --zone $CLUSTER_LOCATION \
  --project $PROJECT_ID

Abilita Workload Identity per ogni pool di nodi con i seguenti comandi. Questa operazione può richiedere fino a 30 minuti per ogni nodo:
Cluster a livello di regione
```
gcloud container node-pools update NODE_POOL_NAME \
  --cluster=$CLUSTER_NAME \
  --region $CLUSTER_LOCATION \
  --project $PROJECT_ID \
  --workload-metadata=GKE_METADATA
```
Cluster zonali
```
gcloud container node-pools update NODE_POOL_NAME \
  --cluster=$CLUSTER_NAME \
  --zone $CLUSTER_LOCATION \
  --project $PROJECT_ID \
  --workload-metadata=GKE_METADATA
```
dove NODE_POOL_NAME è il nome di ogni pool di nodi. Nella maggior parte delle installazioni di Apigee hybrid, i due pool di nodi predefiniti sono denominati apigee-data e apigee-runtime.

Verifica che Workload Identity sia abilitato nei pool di nodi con i seguenti comandi:

Cluster a livello di regione

gcloud container node-pools describe apigee-data \
  --cluster $CLUSTER_NAME \
  --region $CLUSTER_LOCATION \
  --project $PROJECT_ID \
  --flatten "config:"

gcloud container node-pools describe apigee-runtime \
  --cluster $CLUSTER_NAME \
  --region $CLUSTER_LOCATION \
  --project $PROJECT_ID \
  --flatten "config:"

Cluster zonali

gcloud container node-pools describe apigee-data \
  --cluster $CLUSTER_NAME \
  --zone $CLUSTER_LOCATION \
  --project $PROJECT_ID \
  --flatten "config:"

gcloud container node-pools describe apigee-runtime \
  --cluster $CLUSTER_NAME \
  --zone $CLUSTER_LOCATION \
  --project $PROJECT_ID \
  --flatten "config:"

L'output dovrebbe avere il seguente aspetto:

---
diskSizeGb: 100
diskType: pd-standard
...
workloadMetadataConfig:
  mode: GKE_METADATA

Configurazione di Workload Identity

Utilizza la procedura seguente per abilitare Workload Identity per i seguenti componenti di Apigee Hybrid:

apigee-datastore
apigee-telemetry
apigee-org
apigee-env

Quando esegui helm upgrade con il flag --dry-run per i grafici apigee-datastore, apigee-env, apigee-org e apigee-telemetry, l'output includerà i comandi necessari per configurare Workload Identity con i nomi GSA e KSA corretti.

Ad esempio:

helm upgrade datastore apigee-datastore/ \
  --namespace $NAMESPACE \
  -f overrides.yaml \
  --dry-run

NAME: datastore
  ...
For C* backup GKE Workload Identity, please make sure to add the below membership to the IAM policy binding using the respective kubernetes SA (KSA).
  gcloud iam service-accounts add-iam-policy-binding  \
        --role roles/iam.workloadIdentityUser \
        --member "serviceAccount:my-project.svc.id.goog[apigee/apigee-cassandra-backup-sa]" \
        --project :my-project

Recupera il comando per configurare Workload Identity per apigee-datastore ed esegui il comando in NOTES: nell'output.
```
helm upgrade datastore apigee-datastore/ \
  --namespace $NAMESPACE \
  -f overrides.yaml \
  --dry-run
```
Recupera i comandi per configurare Workload Identity per apigee-telemetry ed esegui il comando in NOTES: nell'output.
```
helm upgrade telemetry apigee-telemetry/ \
  --namespace $NAMESPACE \
  -f overrides.yaml \
  --dry-run
```
Recupera i comandi per configurare Workload Identity per apigee-org ed esegui il comando in NOTES: nell'output.
```
helm upgrade $ORG_NAME apigee-org/ \
  --namespace $NAMESPACE \
  -f overrides.yaml \
  --dry-run
```
Recupera i comandi per configurare Workload Identity per apigee-env ed esegui il comando in NOTES: nell'output.
```
helm upgrade $ENV_NAME apigee-env/ \
  --namespace $NAMESPACE \
  --set env=ENV_NAME \
  -f overrides.yaml \
  --dry-run
```
Ripeti questo passaggio per ogni ambiente dell'installazione.
(Facoltativo) Puoi visualizzare lo stato dei tuoi account di servizio Kubernetes nella pagina Kubernetes: Panoramica dei carichi di lavoro nella Google Cloud Console.
Vai a Carichi di lavoro

Nota: potresti visualizzare uno stato di errore per gli account di servizio apigee-cassandra-backup e apigee-cassandra-restore. Questo perché al momento non stai eseguendo il backup o il ripristino e queste procedure non sono ancora state completamente configurate. Per ulteriori informazioni sul backup e sul ripristino di Cassandra, consulta feedbackCassandra backup overview.

Passaggi successivi

Nel passaggio successivo, configurerai il gateway di ingresso Apigee e eseguirai il deployment di un proxy per testare l'installazione.

(PASSAGGIO SUCCESSIVO) Passaggio 1: esponi l'ingresso Apigee 2