Paso 11 (opcional): Configura Workload Identity

Apigee Hybrid v.1.13 admite Workload Identity en GKE y la federación de Workload Identity en AKS y EKS. Los procedimientos de esta guía solo abarcan la configuración de Workload Identity en GKE. Para AKS y AKS, sigue los procedimientos en Habilita la federación de Workload Identity en AKS y EKS.

Configura Workload Identity en GKE

Cuentas de servicio de Google Cloud y cuentas de servicio de Kubernetes

Una cuenta de servicio de Google Cloud es un tipo especial de cuenta que se puede usar para realizar llamadas autorizadas a APIs a través de la autenticación como la cuenta de servicio. Las cuentas de servicio de Google Cloud pueden tener roles y permisos similares a los de un usuario individual. Cuando una aplicación se autentica como una cuenta de servicio, tiene acceso a todos los recursos a los que tiene acceso la cuenta de servicio. Si deseas obtener más información sobre las cuentas de servicio de Google Cloud, consulta Descripción general de las cuentas de servicio.

Creaste cuentas de servicio de Google Cloud para tu instalación de Apigee hybrid en el Paso 4: Crea cuentas de servicio. Apigee usa estas cuentas de servicio para autenticar los componentes híbridos.

Las cuentas de servicio de Kubernetes son similares a las cuentas de servicio de Google Cloud. Una cuenta de servicio de Kubernetes proporciona una identidad para los procesos que se ejecutan en un Pod y le permite autenticarse en el servidor de la API de manera similar a un usuario. Si deseas obtener más información sobre las cuentas de servicio de Kubernetes, consulta Configura cuentas de servicio para Pods.

Si tienes gcp.workloadIdentity.enabled configurado como true en tu archivo de anulación, cuando los gráficos de Helm para cada componente híbrido crearán las cuentas de servicio de Kubernetes para los componentes cuando los instales o actualices como lo hiciste en el Paso 11: Instala Apigee Hybrid con gráficos de Helm.

Cuando configuras Workload Identity en GKE, asocia las cuentas de servicio de Google Cloud con las cuentas de servicio de Kubernetes en el clúster de Kubernetes. De esta manera, las cuentas de servicio de Kubernetes pueden usar la identidad de las cuentas de servicio de Google Cloud y usar sus roles y permisos asignados para autenticarse con los componentes híbridos.

Sigue estas instrucciones para configurar Workload Identity para tu proyecto.

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 en las siguientes propiedades.
- El campo namespace es obligatorio. Por ejemplo:
```
instanceID: "hybrid-instance-1"
namespace: "apigee"
```
- Si usas una sola cuenta de servicio (que no es de producción) para todos los componentes, especifícala con gcp.workloadIdentity.gsa. Por ejemplo:
```
  gcp:
    workloadIdentity:
      enabled: true
      gsa: "apigee-non-prod@my-hybrid-project.iam.gserviceaccount.com"
  
```
- Si usas una cuenta de servicio independiente para cada componente (instalaciones de producción), especifica la cuenta de servicio con la propiedad gsa del componente. Por ejemplo:
```
  logger:
    gsa: "apigee-logger@my-hybrid-project.iam.gserviceaccount.com"
  
```
Consulta: gcp.workloadIdentity.enabled.
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á 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'

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 híbridas de Apigee, 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-datastore
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=server

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=server
```
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=server
```
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=server
```
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=server
```
Repite este paso para cada entorno en tu instalación.
(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.

Próximos pasos

En el siguiente paso, configurarás la puerta de enlace de entrada de Apigee y, además, implementarás un proxy para probar tu instalación.

Próximo paso

(SIGUIENTE) Paso 1: Expón la entrada de Apigee 2