Methoden zur Dienstkontoauthentifizierung in Apigee Hybrid

Authentifizierungsmethoden für Dienstkonten in Apigee Hybrid auswählen

Apigee Hybrid benötigt Dienstkonten für die sichere Kommunikation mit Google Cloud -Diensten. Wählen Sie für diese Dienstkonten eine Authentifizierungsmethode aus, die Ihren Sicherheits- und Betriebsanforderungen entspricht. Dieser Leitfaden bietet einen kurzen Überblick über die verfügbaren Optionen.

Informationen zur Dienstkontoauthentifizierung

Apigee Hybrid verwendet Google Cloud Dienstkonten, um Komponenten zu authentifizieren und zu autorisieren, die in Ihrem Kubernetes-Cluster ausgeführt werden. Diese Dienstkonten greifen auf Google Cloud -Ressourcen wie Cloud Storage-Buckets und Cloud Logging zu. Jedes Dienstkonto erfordert bestimmte IAM-Rollen (Identity and Access Management), um seine Funktionen auszuführen.

Optionen für Authentifizierungsmethoden

Apigee Hybrid unterstützt mehrere Methoden zur Authentifizierung von Dienstkonten. Bei jeder Methode werden Dienstkontoschlüssel unterschiedlich verwaltet, was zu unterschiedlichen Sicherheitsstufen und unterschiedlicher operativer Komplexität führt. Berücksichtigen Sie bei der Auswahl einer Methode Ihre Plattform, Ihren Sicherheitsstatus und Ihre vorhandene Infrastruktur.

In der folgenden Tabelle sind die verfügbaren Authentifizierungsmethoden zusammengefasst:

Methode Speicherort für Schlüssel Plattformkompatibilität Schlüsselverwaltung
Kubernetes-Secrets Kubernetes-Cluster-Secrets Beliebige Kubernetes-Plattform Kubernetes verwaltet Secrets, manuelle Rotation
JSON-Schlüsseldateien für Dienstkonten Lokales Dateisystem Beliebige Kubernetes-Plattform Manuelle Rotation und Verteilung
Vault HashiCorp Vault Beliebige Kubernetes-Plattform Vault verwaltet Secrets, manuelle Rotation
Workload Identity Federation for GKE Google Cloud IAM Google Kubernetes Engine (GKE) Google Cloud verwaltet, keine Schlüsseldateien erforderlich
Identitätsföderation von Arbeitslasten auf anderen Plattformen Google Cloud IAM AKS, EKS, OpenShift oder andere Kubernetes-Plattformen Google Cloud verwaltet, keine Schlüsseldateien erforderlich

Dienstkontoschlüssel in Kubernetes-Secrets speichern

Speichern Sie Dienstkontoschlüssel als Kubernetes-Secrets in Ihrem Cluster. Diese Methode nutzt die integrierten Funktionen zur Secret-Verwaltung in Kubernetes. Kubernetes-Secrets bieten eine sicherere Möglichkeit, Schlüssel zu verwalten, als die direkte Dateispeicherung. Sie verwalten die Schlüsselrotation weiterhin manuell.

Hybridkomponenten verweisen auf diese Secrets mit den Attributen serviceAccountRef und envs[].serviceAccountRefs in der Datei overrides.yaml. Kubernetes verwaltet die Verteilung dieser Secrets an die entsprechenden Pods.

Beispiel:

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

Informationen zur Verwendung dieser Methode finden Sie unter Dienstkontoschlüssel in Kubernetes-Secrets speichern.

JSON-Schlüsseldateien für Dienstkonten

Bei dieser Methode wird für jedes Dienstkonto eine JSON-Schlüsseldatei erstellt und diese Dateien werden direkt in einem Dateisystem gespeichert. Dieser Ansatz ist für die Ersteinrichtung einfach. Allerdings muss die Sicherheit des Dateisystems gewährleistet sein. Die Schlüsselrotation erfolgt manuell.

Legen Sie die JSON-Datei mit dem privaten Schlüssel jedes Dienstkontos in einem Verzeichnis ab, auf das die Apigee Hybrid-Komponenten zugreifen können. Verweisen Sie in Ihrer overrides.yaml-Konfiguration mit den Attributen serviceAccountPath und envs[].serviceAccountPaths auf den Pfad zu diesen Dateien.

Beispiel:

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

Sie können die Dienstkontoschlüsseldateien mit dem Tool create-service-account generieren und herunterladen, das mit Apigee Hybrid bereitgestellt wird. Weitere Informationen finden Sie unter create-service-account.

Dienstkontoschlüssel in Vault speichern

HashiCorp Vault einbinden, um Ihre Dienstkontoschlüssel zu verwalten. Vault bietet eine robuste Lösung für die Secret-Verwaltung mit Funktionen wie dynamischer Secret-Generierung, Auditing und automatisierter Schlüsselrotation. Dazu muss eine Vault-Instanz eingerichtet und verwaltet werden.

Sie müssen separate Vault-Secrets, -Richtlinien und -Rollen für die Komponenten auf Organisations- und Umgebungsebene erstellen. Sie verweisen in Ihrer overrides.yaml-Konfiguration mit den Attributen serviceAccountSecretProviderClass und envs[].serviceAccountSecretProviderClass auf diese Secrets.

Beispiel:

serviceAccountSecretProviderClass: apigee-orgsakeys-spc

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

Weitere Informationen finden Sie unter Dienstkontoschlüssel in Vault speichern.

Workload Identity Federation for GKE

Mit der Workload Identity-Föderation für GKE können Kubernetes-Dienstkonten als Google Cloud-Dienstkonten fungieren. Bei dieser Methode sind keine Dienstkontoschlüsseldateien mehr erforderlich. Stattdessen authentifiziert Ihr GKE-Cluster Arbeitslasten direkt mitGoogle Cloud IAM. Die Workload Identity-Föderation für GKE bietet einen hochsicheren und automatisierten Authentifizierungsmechanismus, der die Schlüsselverwaltung vereinfacht. Diese Methode ist spezifisch für GKE-Cluster.

Bei dieser Methode muss jedes Kubernetes-Dienstkonto an ein bestimmtes Google Cloud -Dienstkonto gebunden werden. Bei der Installation von Apigee Hybrid werden die Kubernetes-Dienstkonten für Ihre Installation erstellt, wenn Sie die Apigee Hybrid-Helm-Diagramme installieren. Wenn Sie den Befehl helm install oder helm upgrade mit dem Flag --dry-run für jedes Diagramm ausführen, enthält die Ausgabe die Befehle zum Binden der Kubernetes-Dienstkonten an die Google Cloud Dienstkonten für die jeweilige Apigee Hybrid-Komponente in diesem Diagramm.

Sie aktivieren die Workload Identity-Föderation für GKE in Ihrer overrides.yaml-Datei mit dem Attribut gcp.workloadIdentity.enabled.

Beispiel:

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

Weitere Informationen finden Sie unter Workload Identity Federation for GKE aktivieren.

Workload Identity Federation auf anderen Plattformen als GKE

Die Workload Identity-Föderation erweitert die Vorteile der Workload Identity-Föderation für GKE auf Kubernetes-Cluster, die außerhalb von Google Cloudausgeführt werden, z. B. Azure Kubernetes Service (AKS), Amazon Elastic Kubernetes Service (EKS) oder OpenShift. Mit dieser Methode kann sich Ihr GKE-fremder Cluster bei Google Cloud authentifizieren. Dazu wird der OIDC-Anbieter Ihres Clusters verwendet, um eine Vertrauensstellung zwischen dem Identitätsanbieter Ihres Clusters und Google Cloudzu konfigurieren. Nach der Ersteinrichtung sind bei dieser Methode keine Dienstkontoschlüsseldateien mehr erforderlich.

Sie können die Workload Identity-Föderation mit folgenden Diensten verwenden:

  • Konfigurationsdateien für Anmeldedaten (anstelle von Dienstkontoschlüsseldateien)
  • Kubernetes-Secrets
  • Vault

Wenn Sie die Workload Identity-Föderation verwenden möchten, müssen Sie für jedes Google Cloud -Dienstkonto Konfigurationsdateien für Anmeldedaten erstellen. Sie verwenden diese Dateien anstelle von Dienstkontoschlüsseldateien oder zum Einrichten der Kubernetes-Secrets oder von Vault, wenn Sie diese Methoden verwenden.

Sie aktivieren die Workload Identity-Föderation in Ihrer overrides.yaml-Datei mit den Attributen gcp.federatedWorkloadIdentity.enabled, gcp.federatedWorkloadIdentity.audience und gcp.federatedWorkloadIdentity.credentialSourceFile.

Beispiel:

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"

Weitere Informationen finden Sie unter Workload Identity-Föderation aktivieren.

Authentifizierungsmethode auswählen

Wählen Sie eine Authentifizierungsmethode basierend auf Ihrer Bereitstellungsumgebung und Ihren Sicherheitsanforderungen aus.

  • Für GKE-Bereitstellungen bietet die Workload Identity-Föderation für GKE einen sicheren und optimierten Ansatz. Dadurch müssen Dienstkontoschlüsseldateien nicht mehr direkt verwaltet werden.
  • Für Kubernetes-Bereitstellungen, die nicht auf GKE basieren (AKS, EKS, OpenShift), bietet die Identitätsföderation von Arbeitslasten eine ähnliche schlüssellose Authentifizierung. Diese Methode ist die empfohlene Wahl für diese Umgebungen.
  • Wenn die Workload Identity-Föderation für GKE oder die Workload Identity-Föderation keine Optionen sind, sollten Sie Vault für die zentrale Schlüsselverwaltung und Automatisierung verwenden.
  • Für einfachere Bereitstellungen oder wenn Sie keine Vault-Einrichtung haben, bietet das Speichern von Schlüsseln in Kubernetes-Secrets eine native Kubernetes-Lösung. Diese Methode bietet mehr Sicherheit als die direkte Dateispeicherung.
  • Direkte Dienstkontoschlüsseldateien eignen sich für erste Tests oder Umgebungen, in denen andere Methoden nicht möglich sind. Diese Methode erfordert jedoch eine sorgfältige manuelle Schlüsselverwaltung und -rotation.

Nächste Schritte