Methoden zur Dienstkontoauthentifizierung in Apigee Hybrid

Authentifizierungsmethoden für Dienstkonten in Apigee Hybrid auswählen

Apigee Hybrid erfordert Dienstkonten für die sichere Kommunikation mit Google Cloud Diensten. Wählen Sie eine Authentifizierungsmethode für diese Dienst Konten aus, die Ihren Sicherheits- und Betriebsanforderungen entspricht. In diesem Leitfaden erhalten Sie einen kurzen Überblick über die verfügbaren Optionen.

Authentifizierung von Dienstkonten

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 die Authentifizierungsmethode

Apigee Hybrid unterstützt mehrere Methoden zur Authentifizierung von Dienstkonten. Bei jeder Methode werden Dienstkontoschlüssel anders verwaltet, was unterschiedliche Sicherheitsstufen und unterschiedliche betriebliche Komplexität bietet. 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 des Schlüssels 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
Workload Identity Federation 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. Bei dieser Methode werden die integrierten Funktionen zur Secret-Verwaltung in Kubernetes genutzt. Kubernetes-Secrets können eine sicherere Möglichkeit zur Verwaltung von Schlüsseln bieten als die direkte Dateispeicherung. Die Schlüsselrotation wird weiterhin manuell verwaltet.

Hybridkomponenten verweisen mit den Attributen serviceAccountRef und envs[].serviceAccountRefs in der Datei overrides.yaml auf diese Secrets. 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 bietet Einfachheit bei der Ersteinrichtung. Sie müssen jedoch die Sicherheit des Dateisystems gewährleisten. Die Schlüsselrotation erfolgt manuell.

Platzieren Sie die JSON-Datei mit dem privaten Schlüssel jedes Dienstkontos in einem Verzeichnis, auf das die Apigee Hybrid-Komponenten zugreifen können. Verweisen Sie in der overrides.yaml Konfiguration mit den serviceAccountPath und envs[].serviceAccountPaths Attributen 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

Integrieren Sie HashiCorp Vault, um Ihre Dienstkontoschlüssel zu verwalten. Vault bietet eine robuste Lösung für die Secret-Verwaltung mit Funktionen wie dynamische Secret-Generierung, Audit-Logging und automatisierte Schlüsselrotation. Dazu müssen Sie eine Vault-Instanz einrichten und verwalten.

Sie müssen separate Vault-Secrets, -Richtlinien und -Rollen für die Komponenten auf Organisationsebene und Umgebungsebene erstellen. Verweisen Sie in der overrides.yaml Konfiguration mit den serviceAccountSecretProviderClass und envs[].serviceAccountSecretProviderClass Attributen 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 Workload Identity Federation for 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 mit Google Cloud IAM. Workload Identity Federation for 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. Beim Apigee Hybrid-Installationsprozess werden die Kubernetes-Dienstkonten erstellt, die für Ihre Installation spezifisch sind, 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 spezifische Apigee Hybrid-Komponente in diesem Diagramm.

Sie aktivieren Workload Identity Federation for GKE in der Datei overrides.yaml 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

Workload Identity Federation erweitert die Vorteile von Workload Identity Federation for 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 Nicht-GKE-Cluster bei authentifizieren, indem Google Cloud der OIDC-Anbieter Ihres Clusters verwendet wird, um eine Vertrauensbeziehung zwischen dem Identitätsanbieter Ihres Clusters und zu konfigurieren Google Cloud. Nach der Ersteinrichtung sind bei dieser Methode keine Dienstkontoschlüsseldateien mehr erforderlich.

Sie können Workload Identity Federation mit Folgendem verwenden:

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

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

Sie aktivieren Workload Identity Federation in der Datei overrides.yaml 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 Federation aktivieren.

Authentifizierungsmethode auswählen

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

  • Für GKE-Bereitstellungen bietet Workload Identity Federation for GKE einen sicheren und optimierten Ansatz. Dadurch ist es nicht mehr erforderlich, Dienstkontoschlüsseldateien direkt zu verwalten.
  • Für Kubernetes-Bereitstellungen, die nicht auf GKE basieren (AKS, EKS, OpenShift), bietet Workload Identity Federation eine ähnliche schlüssellose Authentifizierung. Diese Methode ist die empfohlene Wahl für diese Umgebungen.
  • Wenn Workload Identity Federation for GKE oder Workload Identity Federation 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 eine bessere 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