Paso 11 (opcional): Configurar Workload Identity

Apigee hybrid v.1.14 admite Workload Identity en GKE y Workload Identity Federation en AKS y EKS. Los procedimientos de esta guía solo cubren la configuración de Workload Identity en GKE. En AKS y EKS, sigue los procedimientos que se indican en Habilitar Workload Identity Federation en AKS y EKS.

Configurar 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 hacer llamadas a la API autorizadas autenticándose como la propia cuenta de servicio. A las cuentas de servicio de Google Cloud se les pueden asignar roles y permisos similares a los de un usuario concreto. Cuando una aplicación se autentica como una cuenta de servicio, tiene acceso a todos los recursos a los que la cuenta de servicio tiene permiso para acceder. Si quieres obtener más información sobre las cuentas de servicio de Google Cloud, consulta el artículo Resumen de las cuentas de servicio.

Has creado cuentas de servicio de Google Cloud para tu instalación híbrida de Apigee 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 a los procesos que se ejecutan en un pod y le permite autenticarse en el servidor de la API de forma similar a un usuario. Si quieres obtener más información sobre las cuentas de servicio de Kubernetes, consulta el artículo sobre cómo configurar cuentas de servicio para pods.

Si ha definido gcp.workloadIdentity.enabled como true en su archivo de anulaciones, cuando los gráficos de Helm de cada componente híbrido creen las cuentas de servicio de Kubernetes para los componentes, podrá instalarlos o actualizarlos como hizo en el paso 10: Instalar Apigee hybrid con Helm.

Cuando configuras Workload Identity en GKE, asocias las cuentas de servicio de Google Cloud con las cuentas de servicio de Kubernetes del clúster de Kubernetes. De esta forma, las cuentas de servicio de Kubernetes pueden suplantar a las cuentas de servicio de Google Cloud y usar los roles y permisos que tienen asignados para autenticarse en los componentes híbridos.

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 en las siguientes propiedades.
    • Es obligatorio rellenar el campo "namespace". Por ejemplo: 
      instanceID: "hybrid-instance-1"
namespace: "apigee"
    • Si usas una sola cuenta de servicio (entorno de no 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.

  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
  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, el paso 6 consistía en 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'

    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 grupo de nodos:

    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-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 APIGEE_NAMESPACE \
  -f overrides.yaml \
  --dry-run=server
 
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 my-service-account@my-project.iam.gserviceaccount.com \
      --role roles/iam.workloadIdentityUser \
      --member "serviceAccount:my-project.svc.id.goog[apigee/apigee-cassandra-default]" \
      --project my-project

kubectl annotate serviceaccount apigee-cassandra-default \
      iam.gke.io/gcp-service-account=my-service-account@my-project.iam.gserviceaccount.com \
      --namespace apigee
  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 APIGEE_NAMESPACE \
  -f overrides.yaml \
  --dry-run=server
  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 APIGEE_NAMESPACE \
  -f overrides.yaml \
  --dry-run=server
  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 APIGEE_NAMESPACE \
  -f overrides.yaml \
  --dry-run=server
  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 APIGEE_NAMESPACE \
  --set env=ENV_NAME \
  -f overrides.yaml \
  --dry-run=server

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

  5. (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.

Pasos siguientes

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

Paso siguiente

(SIGUIENTE) Paso 1: Exponer el ingreso de Apigee 2