Habilitar Workload Identity Federation para GKE

En este tema se explica cómo habilitar Workload Identity Federation for GKE en Apigee hybrid.

Si usas Apigee hybrid AKS o EKS, sigue las instrucciones de Habilitar la federación de Workload Identity en AKS y EKS.

Información general

Workload Identity Federation for GKE es una forma de que las aplicaciones que se ejecutan en GKE (Google Kubernetes Engine) accedan a los servicios. Google Cloud Para obtener información general sobre Workload Identity Federation para GKE, consulta los siguientes artículos:

Una cuenta de servicio de gestión de identidades y accesos (IAM) de Google Cloud es una identidad que una aplicación puede usar para enviar solicitudes a las APIs de Google. En el documento, estas cuentas de servicio se denominan "cuentas de servicio de Google" (GSA). Para obtener más información sobre las GSAs, consulta el artículo Cuentas de servicio.

Por otra parte, Kubernetes también tiene el concepto de cuentas de servicio. Una cuenta de servicio proporciona una identidad a los procesos que se ejecutan en un pod. Las cuentas de servicio de Kubernetes son recursos de Kubernetes, mientras que las cuentas de servicio de Google son específicas de Google Cloud. Para obtener información sobre las cuentas de servicio de Kubernetes, consulta el artículo Configurar cuentas de servicio para pods de la documentación de Kubernetes.

Apigee crea y usa una cuenta de servicio de Kubernetes para cada tipo de componente cuando instalas por primera vez los gráficos de Helm de esos componentes. Si habilitas Workload Identity Federation para GKE, los componentes híbridos podrán interactuar con las cuentas de servicio de Kubernetes.

Variables de entorno usadas en estos procedimientos

En estos procedimientos se usan las siguientes variables de entorno. Puedes definir estos valores en tu shell de comandos o sustituirlos por los valores reales en los ejemplos de código:

  • PROJECT_ID: el ID de tu proyecto de Google Cloud.
  • ORG_NAME: el nombre de tu organización de Apigee.
  • ENV_NAME: nombre del entorno de Apigee.
  • NAMESPACE: tu espacio de nombres de Apigee (normalmente, apigee).
  • CLUSTER_LOCATION: la región o la zona de tu clúster de Kubernetes. Por ejemplo, us-west1.
  • CLUSTER_NAME: el nombre del clúster.

Verifica las variables de entorno:

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

Inicializa las variables que necesites:

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 para GKE y archivos de claves de cuentas de servicio

Cuando se ejecuta Apigee hybrid en GKE, lo habitual es crear y descargar claves privadas (archivos .json) para cada una de las cuentas de servicio. Cuando usas Workload Identity Federation para GKE, no tienes que descargar las claves privadas de las cuentas de servicio ni añadirlas a los clústeres de GKE.

Si has descargado archivos de claves de cuentas de servicio como parte de tu instalación de Apigee hybrid, puedes eliminarlos después de habilitar Workload Identity Federation para GKE. En la mayoría de las instalaciones, se encuentran en el directorio del gráfico de cada componente.

Habilitar Workload Identity Federation para GKE en Apigee hybrid

Sigue estas instrucciones para configurar tu proyecto de forma que use Workload Identity Federation para GKE.

Preparar la configuración de Workload Identity Federation para GKE

  1. Verifica que Workload Identity Federation para GKE esté habilitado en tu archivo de anulaciones. Debe habilitarse en el archivo de anulaciones y debe tener valores para las siguientes propiedades de configuración:
  2. Comprueba que la configuración gcloud actual esté definida en el ID de tu proyecto de Google Cloud con el siguiente comando: 
    gcloud config get project

    3. Si es necesario, define la configuración actual de gcloud:

    gcloud config set project $PROJECT_ID
  3. Verifica que Workload Identity Federation para GKE esté habilitado en tu clúster de GKE. Cuando creaste el clúster en el paso 1: Crea un clúster, el paso 6 consistía en habilitar Workload Identity Federation for GKE. Confirma que Workload Identity Federation para GKE está habilitado con el siguiente comando:

    Clústeres regionales

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

    Clústeres zonales

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

    La salida debería tener este aspecto: 

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

    Si ves null en los resultados, ejecuta el siguiente comando para habilitar Workload Identity Federation for GKE en tu clúster:

    Clústeres regionales

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

    Clústeres zonales

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

  4. Habilita Workload Identity Federation para GKE en cada grupo de nodos con los siguientes comandos. Esta operación puede tardar hasta 30 minutos por cada nodo:

    Clústeres regionales

    gcloud container node-pools update NODE_POOL_NAME \
  --cluster=$CLUSTER_NAME \
  --region $CLUSTER_LOCATION \
  --project $PROJECT_ID \
  --workload-metadata=GKE_METADATA

    Clústeres zonales

    gcloud container node-pools update NODE_POOL_NAME \
  --cluster=$CLUSTER_NAME \
  --zone $CLUSTER_LOCATION \
  --project $PROJECT_ID \
  --workload-metadata=GKE_METADATA

    Donde NODE_POOL_NAME es el nombre de cada grupo de nodos. En la mayoría de las instalaciones de Apigee hybrid, los dos grupos de nodos predeterminados se llaman apigee-data y apigee-runtime.

  5. Verifica que Workload Identity Federation for GKE esté habilitado en tus grupos de nodos con los siguientes comandos:

    Clústeres regionales

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

    Clústeres zonales

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

    La salida debería tener un aspecto similar a este:

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

Configurar la instalación para usar Workload Identity Federation para GKE

Sigue este procedimiento para habilitar Workload Identity Federation for GKE en los siguientes componentes de Hybrid:

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

Cuando ejecutes helm upgrade con las marcas --dry-run o --dry-run=server para los gráficos apigee-datastore, apigee-env, apigee-org y apigee-telemetry, el resultado incluirá los comandos que necesitarás para configurar Workload Identity Federation para GKE con los nombres correctos de GSA y KSA.

Por ejemplo:

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

Se mostrará algo parecido a lo siguiente:

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

Donde:

  • apigee-cassandra es el nombre de la cuenta de servicio de Google (GSA) de Cassandra. Consulta Información sobre las cuentas de servicio.
  • PROJECT_ID se sustituye por el ID de tu proyecto de Google Cloud.
  • APIGEE_NAMESPACE se sustituye por tu espacio de nombres de Apigee, que es apigee de forma predeterminada.
  • apigee-cassandra-default es el nombre de la cuenta de servicio de Kubernetes de los pods de Cassandra creados por el gráfico apigee-datastore.
  1. Obtén el comando para configurar Workload Identity Federation para GKE en apigee-datastore y ejecuta los comandos de NOTES: en la salida. 
    helm upgrade datastore apigee-datastore/ \
  --namespace $NAMESPACE \
  -f OVERRIDES_FILE \
  --dry-run=server
  2. Obtén los comandos para configurar Workload Identity Federation para GKE en apigee-telemetry y ejecútalos en NOTES: en el resultado. 
    helm upgrade telemetry apigee-telemetry/ \
  --namespace $NAMESPACE \
  -f OVERRIDES_FILE \
  --dry-run
  3. Obtén los comandos para configurar Workload Identity Federation para GKE en apigee-org y ejecútalos en NOTES: en el resultado. 
    helm upgrade $ORG_NAME apigee-org/ \
  --namespace $NAMESPACE \
  -f OVERRIDES_FILE \
  --dry-run
  4. Obtén los comandos para configurar Workload Identity Federation para GKE en apigee-env y ejecútalos en NOTES: en el resultado. 
    helm upgrade $ENV_NAME apigee-env/ \
  --namespace $NAMESPACE \
  --set env=$ENV_NAME \
  -f OVERRIDES_FILE \
  --dry-run

    Repite este paso con cada entorno de tu instalación.

Verificar Workload Identity Federation para GKE

  1. Valida si los pasos han funcionado: 
    gcloud config set project $PROJECT_ID

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

    Si no ves el símbolo del sistema, prueba a pulsar Intro.

    Si has seguido los pasos correctamente, deberías ver una respuesta como la siguiente:

                       Credentialed Accounts
ACTIVE  ACCOUNT
*       GSA@PROJECT_ID.iam.gserviceaccount.com
  2. Si vas a actualizar una instalación anterior, elimina los secretos que contengan claves privadas de cuentas de servicio: 
    kubectl delete secrets -n $NAMESPACE $(k get secrets -n $NAMESPACE | grep svc-account | awk '{print $1}')
  3. Comprueba los registros: 
    kubectl logs -n $NAMESPACE -l app=apigee=synchronizer,env=$ENV_NAME,org=$ORG_NAME apigee-synchronizer
  4. (Opcional) Puedes ver el estado de tus cuentas de servicio de Kubernetes en la página Kubernetes: Información general de las cargas de trabajo de la Google Cloud console.

    Ir a Cargas de trabajo