Étape 12 (facultatif) : Configurer Workload Identity sur GKE

GKE avec Workload Identity uniquement : configurer Workload Identity

Suivez ces étapes si vous configurez votre fichier de remplacement pour Workload Identity sur GKE à l'Étape 6 : Créer les remplacements.

Si vous n'utilisez pas Workload Identity sur GKE, passez à la partie 3, étape 1 : Exposer la passerelle d'entrée Apigee.

Comptes de service Google Cloud et comptes de service Kubernetes

Un compte de service Google Cloud est un type particulier de compte qui peut être utilisé pour effectuer des appels d'API autorisés en s'authentifiant en tant que compte de service. Les comptes de service Google Cloud peuvent disposer de rôles et d'autorisations semblables à ceux d'un utilisateur individuel. Lorsqu'une application s'authentifie en tant que compte de service, elle a accès à toutes les ressources auxquelles le compte de service est autorisé à accéder. Pour en savoir plus sur les comptes de service Google Cloud, consultez la présentation des comptes de service.

Vous avez créé des comptes de service Google Cloud pour votre installation Apigee hybrid à l'Étape 4 : Créer des comptes de service. Apigee utilise ces comptes de service pour authentifier les composants hybrides.

Les comptes de service Kubernetes sont semblables aux comptes de service Google Cloud. Un compte de service Kubernetes fournit une identité pour les processus exécutés dans un pod et lui permet de s'authentifier auprès du serveur d'API de la même manière qu'un utilisateur. Si vous souhaitez en savoir plus sur les comptes de service Kubernetes, consultez la section Configurer les comptes de service pour les pods.

Si gcp.workloadIdentity.enabled est défini sur true dans votre fichier de remplacement, les graphiques Helm de chaque composant hybride créent les comptes de service Kubernetes pour les composants lorsque vous les installez ou les mettez à niveau comme vous l'avez fait dans l'Étape 11 : Installez Apigee hybrid à l'aide de graphiques Helm

Lorsque vous configurez Workload Identity sur GKE, vous associez les comptes de service Google Cloud aux comptes de service Kubernetes dans le cluster Kubernetes. De cette manière, les comptes de service Kubernetes peuvent emprunter l'identité des comptes de service Google Cloud et utiliser les rôles et autorisations qui leur ont été attribués pour s'authentifier auprès des composants hybrides.

Suivez ces instructions pour configurer Workload Identity pour votre projet.

Préparer la configuration de Workload Identity

Vérifiez que Workload Identity est activé dans votre fichier de remplacement. Il doit être activé dans le fichier de remplacement dans les propriétés suivantes.
Remarque : Si vous avez migré votre cluster depuis la gestion apigeectl avec l'outil de migration Helm Apigee hybrid, la syntaxe de remplacement pour Workload Identity a changé. La syntaxe permettant d'activer Workload Identity est différente: gcp.workloadIdentity.enabled remplace gcp.workloadIdentityEnabled.Vous devez vérifier les éléments suivants.
- Veuillez renseigner l'élément namespace. Exemple :
```
instanceID: "hybrid-instance-1"
namespace: "apigee"
```
- Si vous utilisez un seul compte de service (hors production) pour tous les composants, spécifiez-le avec le code suivant : gcp.workloadIdentity.gsa. Par exemple :
```
  gcp:
    workloadIdentity:
      enabled: true
      gsa: "apigee-non-prod@my-hybrid-project.iam.gserviceaccount.com"
  
```
- Si vous utilisez un compte de service distinct pour chaque composant (installations de production), spécifiez le compte de service avec la propriété gsa du composant. Par exemple :
```
  logger:
    gsa: "apigee-logger@my-hybrid-project.iam.gserviceaccount.com"
  
```
Consultez : gcp.workloadIdentity.enabled
Vérifiez que la configuration gcloud actuelle est définie sur l'ID de votre projet Google Cloud à l'aide de la commande suivante :
```
gcloud config get project
```

Si nécessaire, définissez la configuration gcloud actuelle :

gcloud config set project $PROJECT_ID

Vérifiez que Workload Identity est activé dans votre cluster GKE. Lorsque vous avez créé le cluster à l'étape 1 : Créer un cluster, l'étape 6 consistait à activer Workload Identity. Vous pouvez vérifier si Workload Identity est activé en exécutant la commande suivante :

Clusters régionaux

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

Cluster zonal

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

Le résultat doit se présenter sous la forme suivante :

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

Si null s'affiche dans vos résultats, exécutez la commande suivante pour activer Workload Identity dans votre cluster :

Clusters régionaux

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

Cluster zonal

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

Activez Workload Identity pour chaque pool de nœuds à l'aide des commandes suivantes. Cette opération peut prendre jusqu'à 30 minutes pour chaque nœud :
Clusters régionaux
```
gcloud container node-pools update NODE_POOL_NAME \
  --cluster=$CLUSTER_NAME \
  --region $CLUSTER_LOCATION \
  --project $PROJECT_ID \
  --workload-metadata=GKE_METADATA
```
Cluster zonal
```
gcloud container node-pools update NODE_POOL_NAME \
  --cluster=$CLUSTER_NAME \
  --zone $CLUSTER_LOCATION \
  --project $PROJECT_ID \
  --workload-metadata=GKE_METADATA
```
Où NODE_POOL_NAME est le nom de chaque pool de nœuds. Dans la plupart des installations Apigee hybrid, les deux pools de nœuds par défaut sont nommés apigee-data et apigee-runtime.

Vérifiez que Workload Identity est activé sur vos pools de nœuds à l'aide des commandes suivantes :

Clusters régionaux

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 zonal

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:"

Le résultat doit se présenter sous la forme suivante :

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

Configurer Workload Identity

Procédez comme suit pour activer Workload Identity pour les composants hybrides suivants :

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

Lorsque vous exécutez helm upgrade avec l'option --dry-run pour les graphiques apigee-datastore, apigee-env, apigee-org et apigee-telemetry, la sortie inclut les commandes nécessaires à la configuration de Workload Identity avec les noms GSA et KSA appropriés.

Par exemple :

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

Obtenez la commande pour configurer Workload Identity pour apigee-datastore et exécutez la commande sous NOTES: dans le résultat.
```
helm upgrade datastore apigee-datastore/ \
  --namespace $NAMESPACE \
  -f overrides.yaml \
  --dry-run
```
Obtenez les commandes pour configurer Workload Identity pour apigee-telemetry et exécutez la commande sous NOTES: dans le résultat.
```
helm upgrade telemetry apigee-telemetry/ \
  --namespace $NAMESPACE \
  -f overrides.yaml \
  --dry-run
```
Obtenez les commandes pour configurer Workload Identity pour apigee-org et exécutez la commande sous NOTES: dans le résultat.
```
helm upgrade $ORG_NAME apigee-org/ \
  --namespace $NAMESPACE \
  -f overrides.yaml \
  --dry-run
```
Obtenez les commandes pour configurer Workload Identity pour apigee-env et exécutez la commande sous NOTES: dans le résultat.
```
helm upgrade $ENV_NAME apigee-env/ \
  --namespace $NAMESPACE \
  --set env=ENV_NAME \
  -f overrides.yaml \
  --dry-run
```
Répétez cette étape pour chaque environnement de votre installation.
(Facultatif) Vous pouvez consulter l'état de vos comptes de service Kubernetes sur la page Kubernetes : présentation des charges de travail de la console Google Cloud.
Accéder à la page Charges de travail

Remarque : Il est possible qu'un état d'erreur s'affiche pour les comptes de service apigee-cassandra-backup et apigee-cassandra-restore. En effet, vous n'effectuez pas de sauvegarde ni de restauration, et ces processus n'ont pas encore été entièrement configurés. Pour en savoir plus sur la sauvegarde et la restauration Cassandra, consultez la page Présentation de la sauvegarde feedbackCassandra.

Étapes suivantes

À l'étape suivante, vous allez configurer la passerelle d'entrée Apigee et déployer un proxy pour tester votre installation.

Étape suivante

(SUITE) Étape 1 : Exposer Apigee Ingress 2