Habilitar Workload Identity con gráficos de Helm

En este tema se explica cómo habilitar Workload Identity para Apigee hybrid mediante gráficos de Helm.

Si utilizas apigeectl para instalar y gestionar Apigee hybrid, consulta Habilitar Workload Identity con apigeectl.

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:

• Presentamos Workload Identity: una mejor autenticación para tus aplicaciones de GKE
• Usar Workload Identity

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:

• 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.
• ENV_NAME: nombre del entorno de Apigee.
• ORG_NAME: el nombre de tu organización de Apigee.
• PROJECT_ID: el ID de tu proyecto de Google Cloud.
• NAMESPACE: tu espacio de nombres de Apigee (normalmente, "apigee").

Verifica las variables de entorno:

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

Inicializa las variables que necesites:

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=hybrid-base-directory/apigeectl

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 de cada carácter del componente.

Habilitar Workload Identity en Apigee hybrid

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

Instalación migrada y Workload Identity

Si has migrado tu clúster desde la gestión de apigeectl con la herramienta de migración de Helm de Apigee hybrid, la sintaxis de las anulaciones de Workload Identity habrá cambiado. Deberá comprobar las siguientes propiedades en su archivo de anulaciones:

• Es obligatorio rellenar el campo "namespace". Por ejemplo:

  instanceID: "hybrid-instance-1"
  namespace: "apigee"
  

• La propiedad gcp.workloadIdentity.enabled sustituye a la propiedad gcp.workloadIdentityEnabled. Por ejemplo:

  gcp:
    workloadIdentity:
      enabled: true

• En las instalaciones de producción, cada componente tiene una propiedad gsa. El valor de estas propiedades es la dirección de correo de la cuenta de servicio de gestión de identidades y accesos de Google del componente correspondiente. Por ejemplo:

  watcher
    gsa: apigee-watcher@my-hybrid-project.iam.gserviceaccount.com
  

• En el caso de las instalaciones que no sean de producción, puedes proporcionar un único GSA en la propiedad gcp.workloadIdentity.gsa.

  gcp
    workloadIdentity
      gsa: apigee-watcher@my-hybrid-project.iam.gserviceaccount.com
  

• Con los gráficos de Helm de Apigee hybrid, combina las cuentas de servicio de Google de producción y no producción para Workload Identity. Puedes especificar un único valor para la propiedad gcp.workloadIdentity.gsa y especificar GSAs individuales para componentes concretos. Los valores que proporcione para los componentes individuales tendrán prioridad sobre el valor que proporcione para gcp.workloadIdentity.gsa solo en ese componente.

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:
   • En todas las instalaciones: gcp.workloadIdentityEnabled debe ser true. Por ejemplo:

     gcp:
       workloadIdentity:
         enabled: true

   • Para las instalaciones de producción:
     • connectAgent.gsa
     • envs.gsa.runtime
     • envs.gsa.synchronizer
     • envs.gsa.udca
     • logger.gsa
     • mart.gsa
     • metrics.gsa
     • udca.gsa
     • watcher.gsa
   • En las instalaciones que no sean de producción, indique la dirección del GSA que no sea de producción (con todos los roles de gestión de identidades y accesos necesarios) en la propiedad gcp.workloadIdentity.gsa.
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

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

gcloud config set project $PROJECT_ID

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

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

5. 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-telemetry
• apigee-org
• apigee-env

Cuando ejecutes helm upgrade con la marca --dry-run 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.yaml \
  --dry-run

NAME: datastore
...
For C* 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  \
      --role roles/iam.workloadIdentityUser \
      --member "serviceAccount:my-project.svc.id.goog[apigee/apigee-cassandra-backup-sa]" \
      --project :my-project

1. Obtén el comando para configurar Workload Identity para apigee-datastore y ejecútalo en NOTES: en el resultado.

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

2. Obtén los comandos para configurar Workload Identity para apigee-telemetry y ejecuta el comando en NOTES: en el resultado.

   helm upgrade telemetry apigee-telemetry/ \
     --namespace $NAMESPACE \
     -f overrides.yaml \
     --dry-run

3. Obtén los comandos para configurar Workload Identity para apigee-org y ejecuta el comando en NOTES: en el resultado.

   helm upgrade $ORG_NAME apigee-org/ \
     --namespace $NAMESPACE \
     -f overrides.yaml \
     --dry-run

4. Obtén los comandos para configurar Workload Identity para apigee-env y ejecuta el comando en NOTES: en el resultado.

   helm upgrade $ENV_NAME apigee-env/ \
     --namespace $NAMESPACE \
     --set env=ENV_NAME \
     -f overrides.yaml \
     --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.