Méthodes d'authentification des comptes de service dans Apigee hybrid

Choisir des méthodes d'authentification de compte de service dans Apigee hybrid

Apigee hybrid nécessite des comptes de service pour communiquer de manière sécurisée avec les services Google Cloud . Choisissez une méthode d'authentification pour ces comptes de service qui correspond à vos exigences de sécurité et d'exploitation. Ce guide présente brièvement les options disponibles.

Comprendre l'authentification par compte de service

Apigee hybrid utilise des comptes de service Google Cloud pour authentifier et autoriser les composants exécutés dans votre cluster Kubernetes. Ces comptes de service accèdent aux ressources Google Cloud , telles que les buckets Cloud Storage et Cloud Logging. Chaque compte de service nécessite des rôles IAM (Identity and Access Management) spécifiques pour exécuter ses fonctions.

Options de méthode d'authentification

Apigee hybrid accepte plusieurs méthodes d'authentification des comptes de service. Chaque méthode gère les clés de compte de service différemment, offrant différents niveaux de sécurité et de complexité opérationnelle. Tenez compte de votre plate-forme, de votre stratégie de sécurité et de votre infrastructure existante lorsque vous sélectionnez une méthode.

Le tableau suivant récapitule les méthodes d'authentification disponibles :

Méthode Emplacement de stockage des clés Compatibilité avec les plates-formes Gestion des clés
Secrets Kubernetes Secrets de cluster Kubernetes Toute plate-forme Kubernetes Kubernetes gère les secrets, rotation manuelle
Fichiers de clé JSON de compte de service Système de fichiers local Toute plate-forme Kubernetes Rotation et distribution manuelles
Vault HashiCorp Vault Toute plate-forme Kubernetes Vault gère les secrets, rotation manuelle
Workload Identity Federation for GKE Google Cloud IAM Google Kubernetes Engine (GKE) Google Cloud gère, aucun fichier de clé n'est nécessaire
Fédération d'identité de charge de travail sur d'autres plates-formes Google Cloud IAM AKS, EKS, OpenShift ou autres plates-formes Kubernetes Google Cloud gère, aucun fichier de clé n'est nécessaire

Stocker les clés de compte de service dans des secrets Kubernetes

Stocker les clés de compte de service en tant que secrets Kubernetes dans votre cluster. Cette méthode exploite les fonctionnalités de gestion des secrets intégrées à Kubernetes. Les secrets Kubernetes peuvent fournir un moyen plus sécurisé de gérer les clés que le stockage direct de fichiers. Vous gérez toujours la rotation des clés manuellement.

Les composants hybrides font référence à ces secrets à l'aide des propriétés serviceAccountRef et envs[].serviceAccountRefs du fichier overrides.yaml. Kubernetes gère la distribution de ces secrets aux pods appropriés.

Exemple :

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

Pour utiliser cette méthode, consultez Stocker des clés de compte de service dans des secrets Kubernetes.

Fichiers de clé JSON de compte de service

Cette méthode consiste à créer un fichier de clé JSON pour chaque compte de service et à stocker ces fichiers directement sur un système de fichiers. Cette approche offre une configuration initiale simple. Toutefois, cela nécessite d'assurer la sécurité du système de fichiers. La rotation des clés est manuelle.

Placez le fichier JSON de clé privée de chaque compte de service dans un répertoire accessible par les composants Apigee hybrid. Référencez le chemin d'accès à ces fichiers dans votre configuration overrides.yaml à l'aide des propriétés serviceAccountPath et envs[].serviceAccountPaths.

Exemple :

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

Vous pouvez générer et télécharger les fichiers de clé de compte de service à l'aide de l'outil create-service-account fourni avec Apigee hybrid. Pour en savoir plus, consultez la page sur la méthode create-service-account.

Stocker les clés de compte de service dans Vault

Intégrez HashiCorp Vault pour gérer vos clés de compte de service. Vault fournit une solution robuste pour la gestion des secrets, offrant des fonctionnalités telles que la génération dynamique de secrets, l'audit et la rotation automatisée des clés. Il nécessite la configuration et la maintenance d'une instance Vault.

Vous devrez créer des secrets, des règles et des rôles Vault distincts pour les composants au niveau de l'organisation et au niveau de l'environnement. Vous référencez ces secrets dans votre configuration overrides.yaml à l'aide des propriétés serviceAccountSecretProviderClass et envs[].serviceAccountSecretProviderClass.

Exemple :

serviceAccountSecretProviderClass: apigee-orgsakeys-spc

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

Consultez Stocker des clés de compte de service dans Vault.

Workload Identity Federation for GKE

La fédération d'identité de charge de travail pour GKE permet aux comptes de service Kubernetes d'agir en tant que comptes de service Google Cloud. Cette méthode élimine complètement le besoin de fichiers de clés de compte de service. À la place, votre cluster GKE authentifie directement les charges de travail à l'aide deGoogle Cloud IAM. Workload Identity Federation for GKE fournit un mécanisme d'authentification hautement sécurisé et automatisé, ce qui simplifie la gestion des clés. Cette méthode est spécifique aux clusters GKE.

Cette méthode nécessite de lier chaque compte de service Kubernetes à un compte de service Google Cloud spécifique. Le processus d'installation d'Apigee hybrid crée les comptes de service Kubernetes spécifiques à votre installation lorsque vous installez les charts Helm Apigee hybrid. Lorsque vous exécutez la commande helm install ou helm upgrade avec l'option --dry-run pour chaque chart, le résultat inclut les commandes permettant de lier les comptes de service Kubernetes aux comptes de service Google Cloud pour le composant Apigee hybrid spécifique de ce chart.

Vous activez Workload Identity Federation for GKE dans votre fichier overrides.yaml avec la propriété gcp.workloadIdentity.enabled.

Exemple :

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

Consultez Activer la fédération d'identité de charge de travail pour GKE.

Fédération d'identité de charge de travail sur des plates-formes autres que GKE

La fédération d'identité de charge de travail étend les avantages de Workload Identity Federation for GKE aux clusters Kubernetes exécutés en dehors de Google Cloud, tels qu'Azure Kubernetes Service (AKS), Amazon Elastic Kubernetes Service (EKS) ou OpenShift. Cette méthode permet à votre cluster non GKE de s'authentifier auprès de Google Cloud en utilisant le fournisseur OIDC de votre cluster pour configurer une relation de confiance entre le fournisseur d'identité de votre cluster et Google Cloud. Après la configuration initiale, cette méthode élimine le besoin de fichiers de clés de compte de service.

Vous pouvez utiliser la fédération d'identité de charge de travail avec :

  • Fichiers de configuration des identifiants (à la place des fichiers de clé de compte de service)
  • Secrets Kubernetes
  • Vault

Pour utiliser la fédération d'identité de charge de travail, vous devez créer des fichiers de configuration des identifiants pour chaque compte de service Google Cloud . Vous utilisez ces fichiers à la place des fichiers de clé de compte de service ou pour configurer les secrets Kubernetes ou Vault si vous utilisez ces méthodes.

Vous activez la fédération d'identité de charge de travail dans votre fichier overrides.yaml avec les propriétés gcp.federatedWorkloadIdentity.enabled, gcp.federatedWorkloadIdentity.audience et gcp.federatedWorkloadIdentity.credentialSourceFile.

Exemple :

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"

Consultez Activer la fédération d'identité de charge de travail.

Choisir une méthode d'authentification

Sélectionnez une méthode d'authentification en fonction de votre environnement de déploiement et de vos exigences de sécurité.

  • Pour les déploiements GKE, Workload Identity Federation for GKE offre une approche sécurisée et simplifiée. Vous n'avez ainsi plus besoin de gérer directement les fichiers de clés de compte de service.
  • Pour les déploiements Kubernetes non-GKE (AKS, EKS, OpenShift), la fédération d'identité de charge de travail offre une expérience d'authentification sans clé similaire. Cette méthode est recommandée pour ces environnements.
  • Si la fédération d'identité de charge de travail pour GKE ou la fédération d'identité de charge de travail ne sont pas des options, envisagez d'utiliser Vault pour la gestion et l'automatisation centralisées des clés.
  • Pour des déploiements plus simples ou si vous ne disposez pas d'une configuration Vault, le stockage des clés dans des secrets Kubernetes fournit une solution Kubernetes native. Cette méthode offre une meilleure sécurité que le stockage direct de fichiers.
  • Les fichiers de clé de compte de service directs sont adaptés aux tests initiaux ou aux environnements dans lesquels les autres méthodes ne sont pas réalisables. Toutefois, cette méthode nécessite une gestion et une rotation manuelles minutieuses des clés.

Étapes suivantes