Activer Workload Identity Federation for GKE

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

Si vous utilisez Apigee hybrid sur AKS ou EKS, 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 Federation for GKE permet aux applications s'exécutant dans GKE (Google Kubernetes Engine) d'accéder aux services Google Cloud . Pour obtenir une présentation de Workload Identity Federation for 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 Workload Identity Federation for 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

Workload Identity Federation for 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 (.json fichiers) 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é Workload Identity Federation for GKE. Dans la plupart des installations, ils se trouvent dans le répertoire du graphique de chaque composant.

Activer Workload Identity Federation for GKE pour Apigee hybrid

Suivez ces instructions pour configurer votre projet afin qu'il utilise Workload Identity Federation for GKE.

Préparer la configuration de Workload Identity Federation for GKE

  1. Vérifiez que Workload Identity Federation for GKE 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 :
  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
  3. Vérifiez que Workload Identity Federation for GKE est activé dans votre cluster GKE. Lorsque vous avez créé le cluster dans Étape 1 : Créer un cluster, l'étape 6 consistait à activer Workload Identity Federation for GKE. Confirmez que Workload Identity Federation for GKE est activé à 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 for 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

  4. Activez Workload Identity Federation for 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

    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.

  5. Vérifiez que Workload Identity Federation for GKE 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 votre installation pour utiliser Workload Identity Federation for GKE

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

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

Lorsque vous exécutez le helm upgrade avec les --dry-run ou --dry-run=server flags pour les charts apigee-datastore, apigee-env, apigee-org et apigee-telemetry, le résultat inclut les commandes nécessaires à la configuration de Workload Identity Federation for 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 doit se présenter sous la forme suivante :

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 correspond au 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 correspond au nom du compte de service Kubernetes pour les pods Cassandra créés par le graphique apigee-datastore.
  1. Obtenez la commande pour configurer Workload Identity Federation for 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 Workload Identity Federation for 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 Workload Identity Federation for 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 Workload Identity Federation for 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 Workload Identity Federation for 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 la console Google Cloud Google Cloud console.

    Accéder à la page Charges de travail

Configurer des garde-fous avec Workload Identity Federation for GKE

Vous pouvez utiliser des garde-fous lors de l'installation initiale du graphique apigee-operator pour vérifier si les API appropriées sont activées pour votre projet. Pour configurer votre installation avec Workload Identity Federation for GKE afin d'utiliser des garde-fous lors de l'installation, vous devez configurer manuellement la liaison avant d'exécuter la commande helm upgrade.

  1. Récupérez l'adresse e-mail du GSA de garde-fou à l'aide de la commande suivante : 
    gcloud iam service-accounts list --project ${PROJECT_ID} --filter "apigee"

    Les adresses e-mail GSA ont généralement le format suivant :

    GSA_NAME@PROJECT_ID.iam.gserviceaccount.com

    Exemple :

    DISPLAY NAME       EMAIL                                                DISABLED
apigee-guardrails  apigee-guardrails@myproject.iam.gserviceaccount.com  False

    Utilisez cette adresse e-mail pour la variable GSA_EMAIL lors des deux prochaines étapes.

  2. Assurez-vous que la strophe guardrails se trouve dans votre fichier overrides.yaml : 
    guardrails:
  gsa: GSA_EMAIL
  3. Le KSA pour les garde-fous est nommé apigee-operator-guardrails-sa. Créez la liaison pour le GSA de garde-fou à l'aide de la commande suivante : 
    gcloud iam service-accounts add-iam-policy-binding GSA_EMAIL \
  --role roles/iam.workloadIdentityUser \
  --member "serviceAccount:PROJECT_ID.svc.id.goog[APIGEE_NAMESPACE/apigee-operator-guardrails-sa]" \
  --project PROJECT_ID

Lorsque vous exécutez la commande helm upgrade pour le graphique apigee-operator, le graphique crée un pod de garde-fou pour tester si les API requises sont activées pour votre projet. Si des API requises ne sont pas activées, le pod échoue et l'installation s'arrête. Vous pouvez inspecter les journaux du pod de garde-fou pour voir quelles API sont requises, mais pas activées. Pour en savoir plus, consultez Diagnostiquer les problèmes liés aux garde-fous.