Activer Workload Identity sur GKE

Cet article explique comment activer Workload Identity pour Apigee hybrid sur GKE.

Si vous utilisez Apigee hybrid sur AKS ou AKS, suivez les instructions de la page Activer la fédération d'identité de charge de travail sur AKS et EKS.

Présentation

Workload Identity permet aux applications s'exécutant dans GKE (Google Kubernetes Engine) d'accéder aux services Google Cloud. Pour en savoir plus sur Workload Identity, consultez les sections suivantes :

Un compte de service Google Cloud IAM est une identité qu'une application peut utiliser pour envoyer des requêtes à Google APIs. Ces comptes de service sont appelés GSA ("Google Service Accounts" ou comptes de service Google) dans ce document. Pour en savoir plus sur les GSA, consultez la section Comptes de service.

De son côté, Kubernetes utilise également le concept de comptes de service. Un compte de service fournit une identité pour les processus exécutés dans un pod. Les comptes de service Kubernetes sont des ressources Kubernetes, tandis que les comptes de service Google sont spécifiques à Google Cloud. Pour plus d'informations sur les comptes de service Kubernetes, consultez la section Configurer des comptes de service pour les pods dans la documentation de Kubernetes.

Apigee crée et utilise un compte de service Kubernetes pour chaque type de composant lorsque vous installez pour la première fois les graphiques Helm pour ces composants. L'activation de Workload Identity permet aux composants hybrides d'interagir avec les comptes de service Kubernetes.

Variables d'environnement utilisées dans ces procédures

Cette procédure utilise les variables d'environnement suivantes. Définissez ces valeurs dans votre interface système ou remplacez-les dans les exemples de code par les valeurs réelles :

PROJECT_ID : ID de votre projet Google Cloud.
ORG_NAME : nom de votre organisation Apigee.
ENV_NAME : nom de l'environnement Apigee.
NAMESPACE : votre espace de noms Apigee (généralement apigee).
CLUSTER_LOCATION : région ou zone de votre cluster Kubernetes (par exemple, us-west1).
CLUSTER_NAME : nom de votre cluster.

Vérifiez les variables d'environnement :

echo $PROJECT_ID
echo $ORG_NAME
echo $ENV_NAME
echo $NAMESPACE
echo $CLUSTER_LOCATION
echo $CLUSTER_NAME

Initialisez l'une des variables dont vous avez besoin :

export PROJECT_ID=my-project-id
export ORG_NAME=$PROJECT_ID
export ENV_NAME=my-environment-name
export NAMESPACE=apigee
export CLUSTER_LOCATION=my-cluster-location
export CLUSTER_NAME=my-cluster-name

Workload Identity et fichiers de clé de compte de service

Lorsque vous exécutez Apigee hybrid sur GKE, il est recommandé de créer et de télécharger des clés privées (fichiers .json) pour chacun des comptes de service. Si vous utilisez Workload Identity, vous n'avez pas besoin de télécharger les clés privées des comptes de service et de les ajouter aux clusters GKE.

Si vous avez téléchargé des fichiers de clé de compte de service dans le cadre de votre installation Apigee hybrid, vous pouvez les supprimer après avoir activé Workload Identity. Dans la plupart des installations, elles se trouvent dans le répertoire pour le caractère de chaque composant.

Activer Workload Identity pour Apigee hybrid

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 et avoir des valeurs pour les propriétés de configuration suivantes :
- Pour toutes les installations : gcp.workloadIdentity.enabled doit être true. Exemple :
```
gcp:
  workloadIdentity:
    enabled: true
```
- Pour les installations en production :
- Pour les installations hors production, indiquez l'adresse du GSA hors production (avec tous les rôles IAM nécessaires) dans la propriété gcp.workloadIdentity.gsa.
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 ou --dry-run=server pour les charts 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.

Exemple :

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

NAME: datastore
...
For Cassandra 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 my-gsa@my-project-id.iam.gserviceaccount.com \
      --role roles/iam.workloadIdentityUser \
      --member "serviceAccount:my-project-id.svc.id.goog[apigee/apigee-cassandra-default]" \
      --project my-project-id

kubectl annotate serviceaccount apigee-cassandra-default \
      iam.gke.io/gcp-service-account=my-gsa@my-project-id.iam.gserviceaccount.com \
      --namespace apigee

Obtenez la commande pour configurer Workload Identity pour apigee-datastore et exécutez les commandes sous NOTES: dans le résultat.
```
helm upgrade datastore apigee-datastore/ \
  --namespace $NAMESPACE \
  -f overrides.yaml \
  --dry-run=server
```
Obtenez les commandes pour configurer Workload Identity pour apigee-telemetry et exécutez les commandes sous NOTES: dans le résultat.
```
helm upgrade telemetry apigee-telemetry/ \
  --namespace $NAMESPACE \
  -f overrides.yaml \
  --dry-run=server
```
Obtenez les commandes pour configurer Workload Identity pour apigee-org et exécutez les commandes sous NOTES: dans le résultat.
```
helm upgrade $ORG_NAME apigee-org/ \
  --namespace $NAMESPACE \
  -f overrides.yaml \
  --dry-run=server
```
Obtenez les commandes pour configurer Workload Identity pour apigee-env et exécutez les commandes sous NOTES: dans le résultat.
```
helm upgrade $ENV_NAME apigee-env/ \
  --namespace $NAMESPACE \
  --set env=$ENV_NAME \
  -f overrides.yaml \
  --dry-run=server
```
Répétez cette étape pour chaque environnement de votre installation.

Vérifier Workload Identity

Vérifiez si les étapes ont fonctionné :

gcloud config set project $PROJECT_ID

kubectl run --rm -it --image google/cloud-sdk:slim \
  --namespace $NAMESPACE workload-identity-test\
  -- gcloud auth list

Si l'invite de commande ne s'affiche pas, essayez d'appuyer sur la touche Entrée.

Si les étapes ont été correctement exécutées, vous devriez obtenir une réponse semblable à celle-ci :

                   Credentialed Accounts
ACTIVE  ACCOUNT
*       GSA@PROJECT_ID.iam.gserviceaccount.com

Si vous effectuez une mise à niveau à partir d'une installation précédente, nettoyez les secrets contenant des clés privées de compte de service :
```
kubectl delete secrets -n $NAMESPACE $(k get secrets -n $NAMESPACE | grep svc-account | awk '{print $1}')
```

Vérifiez les journaux :

kubectl logs -n $NAMESPACE -l app=apigee=synchronizer,env=$ENV_NAME,org=$ORG_NAME apigee-synchronizer

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