Habilita Workload Identity en GKE

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

Si usas AKS o AKS de Apigee hybrid, sigue las instrucciones en Habilita la federación de identidades para cargas de trabajo en AKS y EKS.

Descripción general

Workload Identity es una manera con la que las aplicaciones que se ejecutan dentro de GKE (Google Kubernetes Engine) pueden acceder a los servicios de Google Cloud. Para obtener descripciones generales de Workload Identity, consulta la siguiente documentación:

Una cuenta de servicio de Google Cloud IAM es una identidad que una aplicación puede usar para realizar solicitudes a las API de Google. Estas cuentas de servicio se denominan GSA (Cuentas de servicio de Google) en el documento. Para obtener más información sobre las GSA, consulta Cuentas de servicio.

De manera independiente, Kubernetes también tiene el concepto de cuentas de servicio. Una cuenta de servicio proporciona una identidad para 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 Configura cuentas de servicio para pods en la documentación de Kubernetes.

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

Variables de entorno que se usan en estos procedimientos

Estos procedimientos usan las siguientes variables de entorno: Configúralos en el shell de comandos o reemplázalos en las muestras de código por los valores reales:

CLUSTER_LOCATION: la región o la zona de tu clúster de Kubernetes, por ejemplo: us-west1.
CLUSTER_NAME: El nombre de tu clúster.
ENV_NAME: el nombre del entorno de Apigee.
ORG_NAME: el nombre de tu organización de Apigee.
PROJECT_ID: el ID del proyecto de Google Cloud.
NAMESPACE: tu espacio de nombres de Apigee (por lo general, “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 cualquiera de las variables que necesitas:

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 cuenta de servicio

Cuando se ejecuta Apigee Hybrid en GKE, la práctica estándar es crear y descargar claves privadas (archivos .json) para cada una de las cuentas de servicio. Cuando usas Workload Identity, no necesitas descargar claves privadas de cuentas de servicio ni agregarlas a los clústeres de GKE.

Si descargaste archivos de claves de cuenta de servicio como parte de la instalación de Apigee Hybrid, puedes borrarlos después de habilitar Workload Identity. En la mayoría de las instalaciones, residen en el directorio de los caracteres de cada componente.

Habilita Workload Identity para Apigee Hybrid

Sigue estas instrucciones para configurar Workload Identity para tu proyecto.

Instalación migrada y Workload Identity

Si migraste tu clúster desde la administración de apigeectl con la herramienta de migración de Helm de Apigee Hybrid, la sintaxis de anulación para Workload Identity habrá cambiado. Deberás verificar las siguientes propiedades en tu archivo de anulación:

El campo namespace es obligatorio. Por ejemplo:

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

La propiedad gcp.workloadIdentity.enabled reemplaza la propiedad gcp.workloadIdentityEnabled. Por ejemplo:
```
gcp:
  workloadIdentity:
    enabled: true
```
.
En el caso de las instalaciones de producción, cada componente tiene una propiedad gsa. El valor de estas propiedades es la dirección de correo electrónico de la cuenta de servicio de Google IAM del componente correspondiente. Por ejemplo:
```
watcher
  gsa: apigee-watcher@my-hybrid-project.iam.gserviceaccount.com
```
Para las instalaciones que no son de producción, puedes proporcionar una sola GSA en la propiedad gcp.workloadIdentity.gsa.
```
gcp
  workloadIdentity
    gsa: apigee-watcher@my-hybrid-project.iam.gserviceaccount.com
```
Con los gráficos de Helm para Apigee Hybrid, combina las GSA de producción y que no son de producción para Workload Identity. Puedes especificar una sola para la propiedad gcp.workloadIdentity.gsa y especificar GSA individuales para componentes específicos. Los valores que proporciones para los componentes individuales anularán el valor que proporciones para gcp.workloadIdentity.gsa solo para ese componente.

Prepárate para configurar Workload Identity

Verifica que Workload Identity esté habilitada en el archivo de anulación. Debe habilitarse en el archivo de anulación y deberías tener valores para las siguientes propiedades de configuración:
- Para todas las instalaciones: gcp.workloadIdentity.enabled debe ser true. Por ejemplo:
```
gcp:
  workloadIdentity:
    enabled: true
```
- Para las instalaciones de producción:
- Para las instalaciones que no son de producción, proporciona la dirección de la GSA que no sea de producción (con todos los roles de IAM necesarios) en la propiedad gcp.workloadIdentity.gsa.
Verifica que la configuración actual de gcloud sea el ID de tu proyecto de Google Cloud con el siguiente comando:
```
gcloud config get project
```

Si es necesario, establece la configuración actual gcloud:

gcloud config set project $PROJECT_ID

Verifica que Workload Identity esté habilitada para el clúster de GKE. Cuando creaste el clúster en el Paso 1: Crea un clúster, el paso 6 fue Habilitar Workload Identity. Para confirmar si Workload Identity está habilitada, puedes ejecutar 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'

El resultado debe tener el siguiente aspecto:

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

Si, en cambio, 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

Habilita Workload Identity para cada grupo de nodos con los siguientes comandos. Esta operación puede demorar 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
```
En el ejemplo anterior, 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.

Verifica que Workload Identity esté habilitada 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:"

Deberías obtener un resultado similar al siguiente:

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

Configura Workload Identity

Usa el siguiente procedimiento para habilitar Workload Identity para los siguientes componentes híbridos:

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

Obtén el comando para configurar Workload Identity para apigee-datastore y ejecuta el comando en NOTES: en el resultado.
```
helm upgrade datastore apigee-datastore/ \
  --namespace $NAMESPACE \
  -f overrides.yaml \
  --dry-run
```
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
```
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
```
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 para cada entorno en tu instalación.

Verifica Workload Identity

Verifica si funcionaron los pasos:

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, presiona Intro.

Si los pasos se ejecutaron correctamente, deberías ver una respuesta como la siguiente:

                   Credentialed Accounts
ACTIVE  ACCOUNT
*       GSA@PROJECT_ID.iam.gserviceaccount.com

Si actualizas desde una instalación anterior, limpia los secrets que contenían claves privadas de cuentas de servicio:
```
kubectl delete secrets -n $NAMESPACE $(k get secrets -n $NAMESPACE | grep svc-account | awk '{print $1}')
```

Verifica los registros

kubectl logs -n $NAMESPACE -l app=apigee=synchronizer,env=$ENV_NAME,org=$ORG_NAME apigee-synchronizer

(Opcional) Puedes ver el estado de tus cuentas de servicio de Kubernetes en la página Descripción general de las cargas de trabajo de Kubernetes en la consola de Google Cloud.
Ir a Cargas de trabajo

Nota: Es posible que veas un estado de error para las cuentas de servicio apigee-cassandra-backup y apigee-cassandra-restore. Esto se debe a que actualmente no ejecutas la copia de seguridad ni el restablecimiento, y estos procesos aún no están configurados por completo. Para obtener más información sobre la copia de seguridad y el restablecimiento de Cassandra, consulta Descripción general de la copia de seguridad de Cassandra.