Activer Workload Identity Federation for GKE

Cet article explique comment activer la fédération d'identité de charge de travail pour GKE pour Apigee hybrid.

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

La fédération d'identité de charge de travail pour GKE permet aux applications s'exécutant dans GKE (Google Kubernetes Engine) d'accéder aux services Google Cloud . Pour en savoir plus sur la fédération d'identité de charge de travail pour GKE, consultez les pages 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 la fédération d'identité de charge de travail pour GKE 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=MY_ORG_NAME
export ENV_NAME=MY_ENV_NAME
export NAMESPACE=APIGEE_NAMESPACE
export CLUSTER_LOCATION=MY_CLUSTER_LOCATION
export CLUSTER_NAME=MY_CLUSTER_NAME

Fédération d'identité de charge de travail pour GKE 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 Federation for GKE, 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é la fédération d'identité de charge de travail pour GKE. Dans la plupart des installations, elles se trouvent dans le répertoire pour le graphique de chaque composant.

Activer la fédération d'identité de charge de travail pour GKE pour Apigee hybrid

Suivez ces instructions pour configurer votre projet afin qu'il utilise la fédération d'identité de charge de travail pour GKE.

Préparer la configuration de la fédération d'identité de charge de travail pour GKE

  1. Vérifiez que la fédération d'identité de charge de travail pour GKE est activée 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 :
  2. 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
  3. Si nécessaire, définissez la configuration gcloud actuelle :

    gcloud config set project $PROJECT_ID
  4. Vérifiez que Workload Identity Federation for GKE est activé dans votre cluster GKE. Lorsque vous avez créé le cluster à l'étape 1 : Créer un cluster, l'étape 6 consistait à activer la fédération d'identité de charge de travail pour GKE. Vérifiez que la fédération d'identité de charge de travail pour GKE est activée à l'aide de 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 Federation pour GKE 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
  5. Activez la fédération d'identité de charge de travail pour GKE 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

    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.

  6. Vérifiez que la fédération d'identité de charge de travail pour GKE est activée 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 votre installation pour utiliser la fédération d'identité de charge de travail pour GKE

Procédez comme suit pour activer la fédération d'identité de charge de travail pour GKE 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 graphiques apigee-datastore, apigee-env, apigee-org et apigee-telemetry, la sortie inclut les commandes nécessaires à la configuration de la fédération d'identité de charge de travail pour GKE avec les noms GSA et KSA appropriés.

Exemple :

helm upgrade datastore apigee-datastore/ \
  --namespace $NAMESPACE \
  -f OVERRIDES_FILE \
  --dry-run=server

Le résultat sera semblable à ce qui suit :

NAME: datastore
...
For Cassandra backup, please make sure to add the following membership to the IAM policy binding using the respective kubernetes SA (KSA).
gcloud iam service-accounts add-iam-policy-binding apigee-cassandra@PROJECT_ID.iam.gserviceaccount.com \
      --role roles/iam.workloadIdentityUser \
      --member "serviceAccount:PROJECT_ID.svc.id.goog[APIGEE_NAMESPACE/apigee-cassandra-default]" \
      --project PROJECT_ID

kubectl annotate serviceaccount apigee-cassandra-default \
      iam.gke.io/gcp-service-account=apigee-cassandra@PROJECT_ID.iam.gserviceaccount.com \
      --namespace APIGEE_NAMESPACE

Où :

  • apigee-cassandra est le nom du compte de service Google (GSA) pour Cassandra. Consultez À propos des comptes de service.
  • PROJECT_ID est remplacé par l'ID de votre projet Google Cloud.
  • APIGEE_NAMESPACE est remplacé par votre espace de noms Apigee, apigee par défaut.
  • apigee-cassandra-default est le nom du compte de service Kubernetes pour les pods Cassandra créés par le graphique apigee-datastore.
  1. Obtenez la commande pour configurer la fédération d'identité de charge de travail pour GKE pour apigee-datastore et exécutez les commandes sous NOTES: dans le résultat.
    helm upgrade datastore apigee-datastore/ \
      --namespace $NAMESPACE \
      -f OVERRIDES_FILE \
      --dry-run=server
  2. Obtenez les commandes pour configurer la fédération d'identité de charge de travail pour GKE pour apigee-telemetry et exécutez les commandes sous NOTES: dans le résultat.
    helm upgrade telemetry apigee-telemetry/ \
      --namespace $NAMESPACE \
      -f OVERRIDES_FILE \
      --dry-run
  3. Obtenez les commandes pour configurer la fédération d'identité de charge de travail pour GKE pour apigee-org et exécutez les commandes sous NOTES: dans le résultat.
    helm upgrade $ORG_NAME apigee-org/ \
      --namespace $NAMESPACE \
      -f OVERRIDES_FILE \
      --dry-run
  4. Obtenez les commandes pour configurer la fédération d'identité de charge de travail pour GKE 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_FILE \
      --dry-run

    Répétez cette étape pour chaque environnement de votre installation.

Vérifier la fédération d'identité de charge de travail pour GKE

  1. 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
  2. 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}')
    
  3. Vérifiez les journaux :
    kubectl logs -n $NAMESPACE -l app=apigee=synchronizer,env=$ENV_NAME,org=$ORG_NAME apigee-synchronizer
    
  4. (Facultatif) Vous pouvez consulter l'état de vos comptes de service Kubernetes sur la page Kubernetes : présentation des charges de travail de Google Cloud console.

    Accéder à la page Charges de travail