Métodos de autenticación de cuentas de servicio en Apigee Hybrid

Elige métodos de autenticación de cuentas de servicio en Apigee Hybrid

Apigee Hybrid requiere cuentas de servicio para la comunicación segura con los servicios de Google Cloud . Elige un método de autenticación para estas cuentas de servicio que se alinee con tus requisitos de seguridad y operativos. En esta guía, se proporciona una breve descripción general de las opciones disponibles.

Comprende la autenticación de cuentas de servicio

Apigee Hybrid usa cuentas de servicio de Google Cloud para autenticar y autorizar los componentes que se ejecutan en tu clúster de Kubernetes. Estas cuentas de servicio acceden a los recursos de Google Cloud , como los buckets de Cloud Storage y Cloud Logging. Cada cuenta de servicio requiere roles específicos de Identity and Access Management (IAM) para realizar sus funciones.

Opciones de métodos de autenticación

Apigee Hybrid admite varios métodos para autenticar cuentas de servicio. Cada método administra las claves de cuenta de servicio de manera diferente, lo que ofrece varios niveles de seguridad y complejidad operativa. Ten en cuenta tu plataforma, postura de seguridad y la infraestructura existente cuando selecciones un método.

En la siguiente tabla, se resumen los métodos de autenticación disponibles:

Método Ubicación de almacenamiento de claves Compatibilidad con plataformas Administración de claves
Secretos de Kubernetes Secretos del clúster de Kubernetes Cualquier plataforma de Kubernetes Kubernetes administra los Secrets, rotación manual
Archivos de claves JSON de cuentas de servicio Sistema de archivos local Cualquier plataforma de Kubernetes Rotación y distribución manuales
Vault HashiCorp Vault Cualquier plataforma de Kubernetes Vault administra secretos, rotación manual
Workload Identity Federation for GKE Google Cloud IAM Google Kubernetes Engine (GKE) Google Cloud administra, no se necesitan archivos de claves
Federación de identidades para cargas de trabajo en otras plataformas Google Cloud IAM AKS, EKS, OpenShift o alguna otra plataforma de Kubernetes Google Cloud administra, no se necesitan archivos de claves

Almacena claves de cuentas de servicio en Secrets de Kubernetes

Almacena las claves de la cuenta de servicio como Secrets de Kubernetes dentro de tu clúster. Este método aprovecha las capacidades integradas de administración de Secrets en Kubernetes. Los Secrets de Kubernetes pueden proporcionar una forma más segura de administrar claves que el almacenamiento directo de archivos. Aún debes administrar la rotación de claves de forma manual.

Los componentes híbridos hacen referencia a estos secretos con las propiedades serviceAccountRef y envs[].serviceAccountRefs en el archivo overrides.yaml. Kubernetes administra la distribución de estos Secrets a los Pods adecuados.

Por ejemplo:

logger:
  serviceAccountRef: "my-project-apigee-logger-key"

Para usar este método, consulta Almacena claves de cuentas de servicio en Secrets de Kubernetes.

Archivos de claves JSON de cuentas de servicio

Este método implica crear un archivo de claves JSON para cada cuenta de servicio y almacenar estos archivos directamente en un sistema de archivos. Este enfoque ofrece simplicidad para la configuración inicial. Sin embargo, requiere garantizar la seguridad del sistema de archivos. La rotación de claves es manual.

Coloca el archivo JSON de la clave privada de cada cuenta de servicio en un directorio al que puedan acceder los componentes de Apigee Hybrid. Haz referencia a la ruta de acceso a estos archivos en tu configuración de overrides.yaml con las propiedades serviceAccountPath y envs[].serviceAccountPaths.

Por ejemplo:

logger:
  serviceAccountPath: "my-project-apigee-logger.json"

Puedes generar y descargar los archivos de claves de la cuenta de servicio con la herramienta create-service-account que se proporciona con Apigee Hybrid. Para obtener más información, consulta create-service-account.

Almacena claves de cuentas de servicio en Vault

Integra HashiCorp Vault para administrar tus claves de cuentas de servicio. Vault proporciona una solución sólida para la administración de secretos, ya que ofrece funciones como la generación dinámica de secretos, la auditoría y la rotación automatizada de claves. Requiere configurar y mantener una instancia de Vault.

Deberás crear secretos, políticas y roles de Vault independientes para los componentes a nivel de organización y de entorno. Haz referencia a estos secretos en tu configuración de overrides.yaml con las propiedades serviceAccountSecretProviderClass y envs[].serviceAccountSecretProviderClass.

Por ejemplo:

serviceAccountSecretProviderClass: apigee-orgsakeys-spc

envs:
- name: my-env
  serviceAccountSecretProviderClass: apigee-envsakeys-my-env-spc

Consulta Almacena claves de cuentas de servicio en Vault.

Workload Identity Federation for GKE

Workload Identity Federation for GKE permite que las cuentas de servicio de Kubernetes actúen como cuentas de servicio de Google Cloud. Este método elimina por completo la necesidad de archivos de claves de cuentas de servicio. En su lugar, tu clúster de GKE autentica directamente las cargas de trabajo con IAM deGoogle Cloud . Workload Identity Federation for GKE proporciona un mecanismo de autenticación altamente seguro y automatizado, lo que simplifica la administración de claves. Este método es específico de los clústeres de GKE.

Este método requiere vincular cada cuenta de servicio de Kubernetes a una cuenta de servicio de Google Cloud específica. El proceso de instalación de Apigee Hybrid crea las cuentas de servicio de Kubernetes específicas para tu instalación cuando instalas los gráficos de Helm de Apigee Hybrid. Cuando ejecutes el comando helm install o helm upgrade con la marca --dry-run para cada gráfico, el resultado incluirá los comandos para vincular las cuentas de servicio de Kubernetes a las cuentas de servicio de Google Cloud para el componente de Apigee Hybrid específico en ese gráfico.

Habilita la federación de identidades para cargas de trabajo para GKE en tu archivo overrides.yaml con la propiedad gcp.workloadIdentity.enabled.

Por ejemplo:

gcp:
  projectID: my-project
  region: us-west1
  workloadIdentity:
    enabled: true

Consulta Habilita la federación de identidades para cargas de trabajo para GKE.

Federación de identidades para cargas de trabajo en plataformas que no sean GKE

La federación de identidades para cargas de trabajo extiende los beneficios de Workload Identity Federation for GKE a los clústeres de Kubernetes que se ejecutan fuera de Google Cloud, como Azure Kubernetes Service (AKS), Amazon Elastic Kubernetes Service (EKS) u OpenShift. Este método permite que tu clúster que no es de GKE se autentique en Google Cloud con el proveedor de OIDC de tu clúster para configurar una relación de confianza entre el proveedor de identidad de tu clúster y Google Cloud. Después de la configuración inicial, este método elimina la necesidad de archivos de claves de cuentas de servicio.

Puedes usar la federación de identidades para cargas de trabajo con lo siguiente:

  • Archivos de configuración de credenciales (en lugar de archivos de claves de cuentas de servicio)
  • Secretos de Kubernetes
  • Vault

Para usar la federación de identidades para cargas de trabajo, debes crear archivos de configuración de credenciales para cada cuenta de servicio de Google Cloud . Usa estos archivos en lugar de los archivos de claves de la cuenta de servicio o para configurar los Secrets de Kubernetes o Vault si usas esos métodos.

Habilita la federación de identidades para cargas de trabajo en tu archivo overrides.yaml con las propiedades gcp.federatedWorkloadIdentity.enabled, gcp.federatedWorkloadIdentity.audience y gcp.federatedWorkloadIdentity.credentialSourceFile.

Por ejemplo:

gcp:
  projectID: my-project
  region: us-west1
  federatedWorkloadIdentity:
    enabled: true
    audience: "//iam.googleapis.com/projects/123123123123/locations/global/workloadIdentityPools/my-wi-pool/providers/my-wi-provider"
    credentialSourceFile: "/var/run/service-account/token"

Consulta Habilita la federación de identidades para cargas de trabajo.

Elige un método de autenticación

Selecciona un método de autenticación según tu entorno de implementación y los requisitos de seguridad.

  • Para las implementaciones de GKE, Workload Identity Federation for GKE ofrece un enfoque seguro y simplificado. Elimina la necesidad de administrar directamente los archivos de claves de la cuenta de servicio.
  • Para las implementaciones de Kubernetes que no son de GKE (AKS, EKS, OpenShift), la federación de identidades para cargas de trabajo proporciona una experiencia de autenticación sin clave similar. Este método es la opción recomendada para estos entornos.
  • Si Workload Identity Federation for GKE o la federación de identidades para cargas de trabajo no son opciones, considera usar Vault para la administración y automatización centralizadas de claves.
  • Para implementaciones más sencillas o si no tienes una configuración de Vault, almacenar claves en Secrets de Kubernetes proporciona una solución nativa de Kubernetes. Este método ofrece una mejor seguridad que el almacenamiento directo de archivos.
  • Los archivos de claves de cuentas de servicio directas son adecuados para las pruebas iniciales o los entornos en los que no se pueden usar otros métodos. Sin embargo, este método requiere una administración y rotación manuales y cuidadosas de las claves.

¿Qué sigue?