Habilita la federación de identidades para cargas de trabajo en AKS y EKS

En este tema, se explica cómo habilitar Workload Identity para las instalaciones híbridas de Apigee en las plataformas AKS y EKS.

Descripción general

La federación de identidades de cargas de trabajo permite que las aplicaciones que se ejecutan fuera de Google Cloud actúen en nombre de una cuenta de servicio de Google Cloud Platform mediante credenciales de un proveedor de identidad externo.

El uso de la federación de Workload Identity puede ayudarte a mejorar la seguridad, ya que permite que las aplicaciones usen los mecanismos de autenticación que proporciona el entorno externo y puede reemplazar las claves de la cuenta de servicio.

Si quieres obtener una descripción general, consulta Prácticas recomendadas para usar la federación de identidades para cargas de trabajo.

Configura la federación de identidades para cargas de trabajo

Para usar la federación de identidades para cargas de trabajo con Apigee hybrid, primero configura tu clúster y, luego, aplica la función a la instalación de Apigee hybrid.

Configura el clúster para usar la federación de identidades para cargas de trabajo.

Sigue las instrucciones de Google Cloud para configurar la federación de identidades para cargas de trabajo para Kubernetes con las siguientes modificaciones:

  • Muestra una lista de tus cuentas de servicio de IAM y cuentas de servicio de Kubernetes con los siguientes comandos:
    • Cuentas de servicio de IAM: Lo más probable es que ya hayas creado las cuentas de servicio de IAM (también llamadas “cuentas de servicio de Google”) durante la instalación inicial de Apigee hybrid con la herramienta create-service-account. Consulta Acerca de las cuentas de servicio para obtener una lista de las cuentas de servicio de IAM que necesita Apigee hybrid.

      Puedes ver una lista de las cuentas de servicio de IAM en tu proyecto con el siguiente comando: 

      gcloud iam service-accounts list --project PROJECT_ID
    • Cuentas de servicio de Kubernetes: Los gráficos de Apigee Hybrid crean las cuentas de servicio de Kubernetes necesarias para cada componente cuando ejecutas el comando helm install o helm update.

      Puedes ver las cuentas de servicio de Kubernetes en tu clúster con los comandos kubectl get sa: 

      kubectl get sa -n APIGEE_NAMESPACE
kubectl get sa -n apigee-system
  • En el paso Configura la federación de identidades para cargas de trabajo, el público predeterminado para los grupos y proveedores de Workload Identity creados es el siguiente. Usa este valor predeterminado o establece un público esperado personalizado, y guarda este valor para usarlo más adelante. 
    https://iam.googleapis.com/projects/PROJECT_NUM/locations/global/workloadIdentityPools/POOL_ID/providers/PROVIDER_ID
  • Detente después del paso 1 en Implementa una carga de trabajo de Kubernetes. Habrá un archivo de configuración de credenciales para cada cuenta de servicio de Google. Guarda cada archivo de configuración de credenciales y guarda la ruta de acceso que ingresaste para el parámetro --credential-source-file, por ejemplo: /var/run/service-account/token.

Configura Apigee Hybrid para usar la federación de identidades para cargas de trabajo

  1. Copia el archivo fuente de la credencial y el archivo de salida (credential-configuration.json) en los siguientes directorios del gráfico. Estos son los valores que proporcionaste en el paso 1 en Implementa una carga de trabajo de Kubernetes.
    • apigee-datastore/
    • apigee-env
    • apigee-org/
    • apigee-telemetry/
  2. Realiza los siguientes cambios globales en el archivo de anulaciones del clúster: 
    gcp:
  workloadIdentity:
    enabled: false # must be set to false to use Workload Identity Federation
  federatedWorkloadIdentity:
    enabled: true
    audience: "AUDIENCE"
    credentialSourceFile: "CREDENTIAL_SOURCE_FILE"

    Aquí:

    • AUDIENCE es el público permitido del proveedor de Workload Identity, el valor en .audience en el archivo json de configuración de credenciales que configuraste en el paso 1 en Implementa una carga de trabajo de Kubernetes.
    • CREDENTIAL_SOURCE_FILE es el nombre de archivo y la ruta al archivo de origen de las credenciales que usa la federación de identidades para cargas de trabajo a fin de obtener las credenciales para las cuentas de servicio. Este es el valor que proporcionas para credential-source-file cuando configuras la federación de identidades para cargas de trabajo con el comando create-cred-config en el paso 1 en Implementa una carga de trabajo de Kubernetes. Por ejemplo:

      • Por ejemplo:

      gcp:
  workloadIdentity:
    enabled: false
  federatedWorkloadIdentity:
    enabled: true
    audience: "//iam.googleapis.com/projects/123456789012/locations/global/workloadIdentityPools/aws-pool/providers/aws-provider"
    credentialSourceFile: "/var/run/service-account/token"
  3. Configura las anulaciones para cada componente mediante la federación de identidades para cargas de trabajo. Selecciona las instrucciones para los archivos de certificación, los secrets de Kubernetes o Vault según corresponda para tu instalación.

    Archivo de certificación

    Reemplaza el valor de serviceAccountPath por el archivo fuente de la credencial. Esta debe ser la ruta de acceso relacionada con el directorio del gráfico. Por ejemplo:

    udca:
  serviceAccountPath: fwi/credential-configuration.json

    Secreto de K8s

    1. Crea un nuevo secreto de Kubernetes para el archivo fuente de la credencial. 
      kubectl create secret -n apigee generic SECRET_NAME --from-file="client_secret.json=CREDENTIAL_CONFIGURATION_FILE"

      Por ejemplo:

      kubectl create secret -n apigee generic udca-fwi-secret --from-file="client_secret.json=./fwi/credential-configuration.json"
    2. Reemplaza el valor de serviceAccountRef por el secreto nuevo. Por ejemplo: 
      udca:
  serviceAccountRef: udca-fwi-secret

    Vault

    Actualiza la clave de la cuenta de servicio, SAKEY en Vault con el archivo fuente de la credencial. Por ejemplo, para el UDCA (el procedimiento es similar para todos los componentes): 

    SAKEY=$(cat ./fwi/credential-configuration.json); kubectl -n apigee exec vault-0 -- vault kv patch secret/apigee/orgsakeys udca="$SAKEY"
  4. Aplica los cambios a cada componente afectado con el comando helm update:

    Si usas Vault por primera vez con este clúster, actualiza el gráfico apigee-operator: 

    helm upgrade operator apigee-operator/ \
  --namespace apigee-system \
  --atomic \
  -f overrides.yaml

    Actualiza el resto de los gráficos afectados en el siguiente orden: 

    helm upgrade datastore apigee-datastore/ \
  --namespace apigee \
  --atomic \
  -f overrides.yaml

    helm upgrade telemetry apigee-telemetry/ \
  --namespace apigee \
  --atomic \
  -f overrides.yaml

    helm upgrade $ORG_NAME apigee-org/ \
  --namespace apigee \
  --atomic \
  -f overrides.yaml

    Actualiza el gráfico apigee-env para cada entorno y reemplaza ENV_NAME cada vez: 

    helm upgrade $ENV_NAME apigee-env/ \
  --namespace apigee \
  --atomic \
  --set env=$ENV_NAME \
  -f overrides.yaml

    Consulta la referencia de Helm de Apigee hybrid para obtener una lista de componentes y sus gráficos correspondientes.

Si deseas obtener más información sobre la federación de identidades para cargas de trabajo y las prácticas recomendadas, consulta Prácticas recomendadas para usar la federación de identidades para cargas de trabajo.