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 opérationnelles et de sécurité. 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 s'exécutant 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 niveau de sécurité et de votre infrastructure existante lorsque vous choisissez 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 du 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 les clés. 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 d'autres plates-formes Kubernetes Google Cloud gère les clés. Aucun fichier de clé n'est nécessaire.

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

Stockez 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 référencent ces secrets à l'aide des propriétés serviceAccountRef et envs[].serviceAccountRefs dans le 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 les 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 la simplicité pour la configuration initiale. Toutefois, il est nécessaire de garantir 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 hybrides Apigee. 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, avec des fonctionnalités telles que la génération de secrets dynamiques, l'audit et la rotation automatique des clés. Cela nécessite de configurer et de gérer 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 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é de compte de service. Votre cluster GKE authentifie plutôt directement les charges de travail à l'aide d'Google 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 graphiques Helm Apigee hybrid. Lorsque vous exécutez la commande helm install ou helm upgrade avec l'indicateur --dry-run pour chaque graphique, le résultat inclut les commandes permettant d'associer les comptes de service Kubernetes aux comptes de service Google Cloud pour le composant Apigee hybrid spécifique de ce graphique.

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 la fédération d'identité de charge de travail pour 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 à l'aide du 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 (au lieu 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 pouvez activer la fédération d'identité de charge de travail dans votre fichier overrides.yaml à l'aide des 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é 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 Workload Identity Federation pour GKE ou la fédération d'identité de charge de travail ne sont pas disponibles, 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 les 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 direct conviennent aux tests initiaux ou aux environnements dans lesquels d'autres méthodes ne sont pas possibles. Toutefois, cette méthode nécessite une gestion et une rotation manuelles des clés minutieuses.

Étapes suivantes