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

Elegir métodos de autenticación con cuenta de servicio en Apigee Hybrid

Apigee Hybrid requiere cuentas de servicio para comunicarse de forma segura con los servicios de Google Cloud . Elige un método de autenticación para estas cuentas de servicio que se ajuste a tus requisitos de seguridad y operativos. En esta guía se ofrece un breve resumen de las opciones disponibles.

Información sobre la autenticación con cuentas de servicio

Apigee hybrid usa Google Cloud cuentas de servicio para autenticar y autorizar componentes que se ejecutan en tu clúster de Kubernetes. Estas cuentas de servicio acceden a Google Cloud recursos, como segmentos de Cloud Storage y Cloud Logging. Cada cuenta de servicio requiere roles de Gestión de Identidades y Accesos (IAM) específicos para llevar a cabo sus funciones.

Opciones de método de autenticación

Apigee hybrid admite varios métodos para autenticar cuentas de servicio. Cada método gestiona las claves de cuenta de servicio de forma diferente, lo que ofrece varios niveles de seguridad y complejidad operativa. Ten en cuenta tu plataforma, tu postura de seguridad y tu infraestructura actual al seleccionar 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 con plataformas Administración de claves
Secretos de Kubernetes Secretos de clúster de Kubernetes Cualquier plataforma de Kubernetes Kubernetes gestiona los secretos y la 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 gestiona los secretos y la rotación manual.
Workload Identity Federation para GKE Google Cloud YO SOY Google Kubernetes Engine (GKE) Google Cloud gestiona, no se necesitan archivos de claves
Federación de identidades de cargas de trabajo en otras plataformas Google Cloud YO SOY AKS, EKS, OpenShift u otras plataformas de Kubernetes Google Cloud gestiona, no se necesitan archivos de claves

Almacenar claves de cuentas de servicio en secretos de Kubernetes

Almacena las claves de cuentas de servicio como secretos de Kubernetes en tu clúster. Este método aprovecha las funciones de gestión de secretos integradas en Kubernetes. Los secretos de Kubernetes pueden proporcionar una forma más segura de gestionar las claves que el almacenamiento directo de archivos. Seguirás gestionando la rotación de claves manualmente.

Los componentes híbridos hacen referencia a estos secretos mediante las propiedades serviceAccountRef y envs[].serviceAccountRefs del archivo overrides.yaml. Kubernetes gestiona 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 Almacenar claves de cuentas de servicio en secretos de Kubernetes.

Archivos de claves JSON de cuentas de servicio

Este método consiste en crear un archivo de clave 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 asegurar el 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 estos archivos en tu configuración de overrides.yaml mediante las propiedades serviceAccountPath y envs[].serviceAccountPaths.

Por ejemplo:

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

Puedes generar y descargar los archivos de claves de 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.

Almacenar claves de cuentas de servicio en Vault

Integra HashiCorp Vault para gestionar las claves de tus cuentas de servicio. Vault ofrece una solución sólida para la gestió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á crear secretos, políticas y roles de Vault independientes para los componentes a nivel de organización y de entorno. Puedes hacer referencia a estos secretos en la configuración de overrides.yaml mediante las propiedades serviceAccountSecretProviderClass y envs[].serviceAccountSecretProviderClass.

Por ejemplo:

serviceAccountSecretProviderClass: apigee-orgsakeys-spc

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

Consulta Almacenar claves de cuentas de servicio en Vault.

Workload Identity Federation para GKE

Workload Identity Federation para GKE permite que las cuentas de servicio de Kubernetes actúen como Google Cloudcuentas de servicio. Con este método, no es necesario usar archivos de claves de cuentas de servicio. En su lugar, tu clúster de GKE autentica directamente las cargas de trabajo medianteGoogle Cloud IAM. Workload Identity Federation para GKE proporciona un mecanismo de autenticación altamente seguro y automatizado que simplifica la gestión de claves. Este método es específico de 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 de 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 Google Cloud cuentas de servicio del componente híbrido de Apigee específico de ese gráfico.

Para habilitar Workload Identity Federation for GKE, usa la propiedad gcp.workloadIdentity.enabled en el archivo overrides.yaml.

Por ejemplo:

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

Consulta Habilitar Workload Identity Federation para GKE.

Federación de identidades de cargas de trabajo en plataformas distintas de GKE

Workload Identity Federation amplía las ventajas de Workload Identity 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) u OpenShift. Este método permite que tu clúster que no es de GKE se autentique en Google Cloud mediante el proveedor de OIDC de tu clúster para configurar una relación de confianza entre el proveedor de identidades de tu clúster y Google Cloud. Tras la configuración inicial, este método elimina la necesidad de usar archivos de claves de cuentas de servicio.

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

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

Para usar la federación de identidades de cargas de trabajo, debes crear archivos de configuración de credenciales para cada cuenta de servicio. Google Cloud Estos archivos se usan en lugar de los archivos de claves de cuentas de servicio o para configurar los secretos de Kubernetes o Vault si utilizas esos métodos.

Para habilitar la federación de identidades de cargas de trabajo en el archivo overrides.yaml, usa 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 Habilitar la federación de identidades de cargas de trabajo.

Elegir un método de autenticación

Selecciona un método de autenticación en función de tu entorno de implementación y tus requisitos de seguridad.

  • En las implementaciones de GKE, Workload Identity Federation for GKE ofrece un enfoque seguro y optimizado. De esta forma, no es necesario gestionar los archivos de claves de cuentas de servicio directamente.
  • En las implementaciones de Kubernetes que no sean de GKE (AKS, EKS y OpenShift), Workload Identity Federation ofrece una experiencia de autenticación sin llaves similar. Este método es la opción recomendada para estos entornos.
  • Si Workload Identity Federation para GKE o Workload Identity Federation no son opciones, considera usar Vault para la gestión y la automatización centralizadas de claves.
  • Si quieres simplificar las implementaciones o no tienes una configuración de Vault, puedes almacenar las claves en secretos de Kubernetes, que es una solución nativa de Kubernetes. Este método ofrece más 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 gestión y una rotación manuales de las claves.

Siguientes pasos