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

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

Información general

La federación de identidades de carga de trabajo permite que las aplicaciones que se ejecutan fuera de Google Cloud suplanten la identidad de una cuenta de servicio de Google Cloud Platform mediante credenciales de un proveedor de identidades externo.

Usar la federación de identidades de carga de trabajo 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 ayudarte a sustituir las claves de cuentas de servicio.

Para obtener una descripción general, consulta las prácticas recomendadas para usar la federación de identidades de cargas de trabajo.

Configurar la federación de identidades de cargas de trabajo

Para usar la federación de identidades de carga de trabajo con Apigee hybrid, primero debes configurar tu clúster y, a continuación, aplicar la función a tu instalación de Apigee hybrid.

Configura tu clúster para que use la federación de identidades de cargas de trabajo.

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

• Lista tus cuentas de servicio de gestión de identidades y accesos y tus 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 la lista de cuentas de servicio de gestión de identidades y accesos que necesita Apigee hybrid en el artículo Acerca de las cuentas de servicio.

    Puedes ver una lista de las cuentas de servicio de gestión de identidades y accesos de 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 de tu clúster con los comandos kubectl get sa:

    kubectl get sa -n APIGEE_NAMESPACE
    kubectl get sa -n apigee-system

• En el paso Configurar federación de identidades de cargas de trabajo, la audiencia predeterminada de los grupos y proveedores de identidades de cargas de trabajo creados es la siguiente. Usa este valor predeterminado o define una audiencia esperada personalizada 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 de la sección Desplegar 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 la ruta introducida para el parámetro --credential-source-file, por ejemplo: /var/run/service-account/token.

Configurar Apigee hybrid para usar la federación de identidades de cargas de trabajo

1. Copia el archivo de origen de las credenciales y el archivo de salida (credential-configuration.json) en los siguientes directorios de gráficos. Estos son los valores que has proporcionado en el paso 1 de la sección Implementar una carga de trabajo de Kubernetes.
   • apigee-datastore/
   • apigee-env
   • apigee-org/
   • apigee-telemetry/
2. Haz los siguientes cambios globales en el archivo de anulaciones de tu 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"
   

   Donde:

   • AUDIENCE es la audiencia permitida del proveedor de identidades de carga de trabajo, el valor de .audience en el archivo JSON de configuración de credenciales que has configurado en el paso 1 de Implementar 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 Workload Identity Federation para obtener las credenciales de las cuentas de servicio. Este es el valor que proporcionas para credential-source-file cuando configuras la federación de identidades de cargas de trabajo con el comando create-cred-config en el paso 1 de Implementar 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 de cada componente mediante la federación de identidades de cargas de trabajo. Selecciona las instrucciones para archivos de certificado, secretos de Kubernetes o Vault según corresponda a tu instalación.

   Archivo de certificado

   Sustituye el valor de serviceAccountPath por el archivo de origen de las credenciales. Debe ser la ruta relativa al directorio del gráfico. Por ejemplo:

   udca:
     serviceAccountPath: fwi/credential-configuration.json
   

   Secreto de K8s

   1. Crea un secreto de Kubernetes con el archivo de origen de las credenciales.

      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. Sustituye el valor de serviceAccountRef por el nuevo secreto. Por ejemplo:

      udca:
        serviceAccountRef: udca-fwi-secret
      

   Vault

   Actualiza la clave de cuenta de servicio, SAKEY, en Vault con el archivo de origen de las credenciales. Por ejemplo, en el caso de 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 es la primera vez que usas Vault 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 de cada entorno y sustituye 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 ver una lista de componentes y sus gráficos correspondientes.

Para obtener más información sobre la federación de identidades de cargas de trabajo y las prácticas recomendadas, consulta el artículo Prácticas recomendadas para usar la federación de identidades de cargas de trabajo.