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

Cómo elegir 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 operativos y de seguridad. 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 roles específicos de Identity and Access Management (IAM) para realizar sus funciones.

Opciones de método 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 tu 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 la llave 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 y la rotación manual
Archivos de claves JSON de la cuenta 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 y la rotación manual
Federación de identidades para cargas de trabajo para 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 las claves de la cuenta de servicio como secretos de Kubernetes dentro de 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 correspondientes.

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 la cuenta 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 clave privada de cada cuenta de servicio en un directorio al que puedan acceder los componentes híbridos de Apigee. 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 las claves de tu cuenta de servicio. Vault proporciona una solución sólida para la administración de secretos, con funciones como la generación dinámica de secretos, la auditoría y la rotación automática de claves. Requiere configurar y mantener una instancia de Vault.

Deberás crear políticas, roles y secretos de Vault separados para los componentes a nivel de la organización y del entorno. Puedes hacer 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.

Federación de identidades para cargas de trabajo para GKE

La federación de identidades para cargas de trabajo para 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 conGoogle 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 los clústeres de GKE.

Este método requiere que se vincule 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 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 cuentas de servicio de Google Cloud para el componente híbrido específico de Apigee 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 la federación de identidades para cargas de trabajo para GKE a los clústeres de Kubernetes que se ejecutan fuera de 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 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 los siguientes servicios:

  • 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 Google Cloud cuenta de servicio. Usarás estos archivos en lugar de los archivos de claves de la cuenta de servicio o para configurar los objetos Secret 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 archivos de claves de cuentas de servicio directamente.
  • 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 Workload Identity Federation 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 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 otros métodos no son factibles. Sin embargo, este método requiere una administración y rotación manuales cuidadosas de las claves.

¿Qué sigue?