Habilitar Workload Identity en GKE

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

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 es una forma de que las aplicaciones que se ejecutan en GKE (Google Kubernetes Engine) accedan a los servicios de Google Cloud. Para ver información general sobre Workload Identity, consulta los siguientes artículos:

Una cuenta de servicio de gestión de identidades y accesos (IAM) de Google Cloud es una identidad que puede usar una aplicación 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 cuentas de servicio, 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. Al habilitar Workload Identity, los componentes híbridos pueden 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 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 se usa Workload Identity, no es necesario descargar claves privadas de 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 la instalación de Apigee hybrid, puedes eliminarlos después de habilitar Workload Identity. En la mayoría de las instalaciones, se encuentran en el directorio del gráfico de cada componente.

Habilitar Workload Identity en Apigee hybrid

Sigue estas instrucciones para configurar la identidad de carga de trabajo en tu proyecto.

Prepararse para configurar Workload Identity

  1. Verifica que la identidad de carga de trabajo esté habilitada en el 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 se ha definido 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
  4. Verifica que Workload Identity esté habilitado en tu clúster de GKE. Cuando creaste el clúster en el paso 1: Crea un clúster, en el paso 6 se habilitó Workload Identity. Para confirmar si Workload Identity está habilitado, ejecuta 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 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
  5. Habilita Workload Identity 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 denominan apigee-data y apigee-runtime.

  6. Verifica que Workload Identity 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 Workload Identity

Sigue este procedimiento para habilitar Workload Identity 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 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 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 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 para apigee-datastore y ejecuta los comandos de NOTES: en el resultado.
    helm upgrade datastore apigee-datastore/ \
      --namespace $NAMESPACE \
      -f OVERRIDES_FILE \
      --dry-run=server
  2. Obtén los comandos para configurar Workload Identity para 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 para 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 para 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

  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.

    Ve a Cargas de trabajo.