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 Google Cloud los servicios. Elige un método de autenticación para estas cuentas de servicio que se alinee con tus requisitos de seguridad y operacionales. 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 Google Cloud cuentas de servicio para autenticar y autorizar los componentes que se ejecutan en tu clúster de Kubernetes. Estas cuentas de servicio acceden a Google Cloud recursos, como buckets de Cloud Storage y Cloud Logging. Cada cuenta de servicio requiere funciones específicas de Identity and Access Management (IAM) roles 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 cuentas de servicio de manera diferente, lo que ofrece varios niveles de seguridad y complejidad operativa. Ten en cuenta tu plataforma, tu 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 del almacenamiento de claves Compatibilidad de la plataforma Administración de claves
Secretos de Kubernetes Secretos del clúster de Kubernetes Cualquier plataforma de Kubernetes Kubernetes administra los secretos, rotación manual
Archivos de claves JSON de cuentas de servicio Sistema de archivos local Cualquier plataforma de Kubernetes Rotación y distribución manual
Vault HashiCorp Vault Cualquier plataforma de Kubernetes Vault administra los 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 cualquier otra plataforma de Kubernetes Google Cloud administra, no se necesitan archivos de claves

Almacena claves de cuentas de servicio en secretos de Kubernetes

Almacena claves de cuentas de servicio como secretos de Kubernetes en tu clúster. Este método aprovecha las capacidades integradas de administración de secretos en Kubernetes. Los secretos de Kubernetes pueden proporcionar una forma más segura de administrar claves que el almacenamiento directo de archivos. Aún administras 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 secretos 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 secretos 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 claves privadas 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 overrides.yaml configuración 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 cuentas 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 las claves de tus cuentas de servicio. Vault proporciona una solución sólida para la administración de secretos, que ofrece funciones como la generación de secretos dinámicos, la auditoría y la rotación automática de claves. Requiere configurar y mantener una instancia de Vault.

Deberás crear secretos, políticas y funciones de Vault separados para los componentes a nivel de la organización y del entorno. Haces referencia a estos secretos en tu overrides.yaml configuración 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

La federación de identidades para cargas de trabajo para GKE permite que las cuentas de servicio de Kubernetes actúen como Google Cloud cuentas de servicio. 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 Google Cloud IAM. La federación de identidades para cargas de trabajo para 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 para clústeres de GKE.

Este método requiere vincular cada cuenta de servicio de Kubernetes a una cuenta de servicio específica Google Cloud . 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 ejecutas 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 Google Cloud cuentas de servicio para el componente específico de Apigee Hybrid 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 son de 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 Google Cloud, como Azure Kubernetes Service (AKS), Amazon Elastic Kubernetes Service (EKS) o OpenShift. Este método permite que tu clúster que no es de GKE se autentique en Google Cloud con Google Cloud 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 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, crea archivos de configuración de credenciales para cada Google Cloud cuenta de servicio. Usa estos archivos en lugar de archivos de claves de cuentas de servicio o para configurar los secretos 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 tus requisitos de seguridad.

  • Para las implementaciones de GKE, Workload Identity Federation for GKE ofrece un enfoque seguro y optimizado. Elimina la necesidad de administrar directamente los archivos de claves de cuentas 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 claves 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 simples o si no tienes una configuración de Vault, almacenar claves en secretos de Kubernetes proporciona una solución nativa de Kubernetes. Este método ofrece mejor seguridad que el almacenamiento directo de archivos.
  • Los archivos de claves de cuentas de servicio directos son adecuados para pruebas iniciales o entornos en los que no son factibles otros métodos. Sin embargo, este método requiere una administración y rotación de claves manuales cuidadosas.

¿Qué sigue?