En este tema, se explica cómo habilitar Workload Identity para las instalaciones híbridas de Apigee en las plataformas AKS y AKS.
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:
-
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
-
No es necesario que realices los pasos que se indican en Crea un par de cuentas de servicio, porque las cuentas de servicio que necesitarás ya deberían haberse creado:
-
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
ohelm 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
-
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
-
Detente después del paso 1 en Implementa una carga de trabajo de Kubernetes. Guarda el 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
-
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/
-
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 comandocreate-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"
-
AUDIENCE es el público permitido del proveedor de Workload Identity, el valor en
-
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
-
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"
-
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"
-
Crea un nuevo secreto de Kubernetes para el archivo fuente de la credencial.
-
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_NAMESPACE \ --atomic \ -f overrides.yaml
Actualiza el resto de los gráficos afectados en el siguiente orden:
helm upgrade datastore apigee-datastore/ \ --namespace APIGEE_NAMESPACE \ --atomic \ -f overrides.yaml
helm upgrade telemetry apigee-telemetry/ \ --namespace APIGEE_NAMESPACE \ --atomic \ -f overrides.yaml
helm upgrade $ORG_NAME apigee-org/ \ --namespace APIGEE_NAMESPACE \ --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_NAMESPACE \ --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.