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 une communication sécurisée avec les Google Cloud services. Choisissez une méthode d'authentification pour ces comptes de service qui correspond à vos exigences opérationnelles et de sécurité. Ce guide fournit un bref aperçu des options disponibles.

Comprendre l'authentification des comptes de service

Apigee hybrid utilise des Google Cloud comptes de service pour authentifier et autoriser les composants exécutés dans votre cluster Kubernetes. Ces comptes de service accèdent à des Google Cloud ressources, telles que des buckets Cloud Storage et Cloud Logging. Chaque compte de service nécessite des rôles Identity and Access Management (IAM) 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 la plate-forme Gestion des clés
Secrets Kubernetes Secrets du cluster Kubernetes N'importe quelle plate-forme Kubernetes Kubernetes gère les secrets, rotation manuelle
Fichiers de clé JSON de compte de service Système de fichiers local N'importe quelle plate-forme Kubernetes Rotation et distribution manuelles
Vault HashiCorp Vault N'importe quelle 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 d'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

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 offrir 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 serviceAccountRef et envs[].serviceAccountRefs propriétés dans le overrides.yaml fichier. 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 dans un système de fichiers. Cette approche est simple pour la configuration initiale. Toutefois, elle nécessite 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 Apigee hybrid. Référencez le chemin d'accès à ces fichiers dans votre overrides.yaml configuration à l'aide des serviceAccountPath et envs[].serviceAccountPaths propriétés.

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 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. Elle 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 de l'environnement. Vous référencez ces secrets dans votre overrides.yaml configuration à 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 les clés de compte de service dans Vault.

Workload Identity Federation for GKE

Workload Identity Federation for GKE permet aux comptes de service Kubernetes d'agir en tant que Google Cloud comptes de service. Cette méthode élimine complètement le besoin de fichiers de clé de compte de service. Au lieu de cela, votre cluster GKE authentifie directement les charges de travail à l'aide de 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 spécifique Google Cloud . 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, la sortie inclut les commandes permettant de lier les comptes de service Kubernetes aux Google Cloud comptes de service du 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 Workload Identity Federation for GKE.

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

Workload Identity Federation é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é de compte de service.

Vous pouvez utiliser la fédération d'identité de charge de travail avec les éléments suivants :

  • Fichiers de configuration des identifiants (au lieu des fichiers de clé de compte de service)
  • Secrets Kubernetes
  • Vault

Pour utiliser Workload Identity Federation, vous devez créer des fichiers de configuration des identifiants pour chaque Google Cloud compte de service. 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 Workload Identity Federation.

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. Elle élimine le besoin de gérer directement les fichiers de clé de compte de service.
  • Pour les déploiements Kubernetes non-GKE (AKS, EKS, OpenShift), Workload Identity Federation offre une expérience d'authentification sans clé similaire. Cette méthode est recommandée pour ces environnements.
  • Si Workload Identity Federation for GKE ou Workload Identity Federation ne sont pas des options, envisagez d'utiliser Vault pour la gestion et l'automatisation centralisées des clés.
  • Pour les 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 conviennent aux tests initiaux ou aux environnements dans lesquels d'autres méthodes ne sont pas réalisables. Toutefois, cette méthode nécessite une gestion et une rotation manuelles des clés.

Étape suivante