Methoden zur Dienstkontoauthentifizierung in Apigee Hybrid

Authentifizierungsmethoden für Dienstkonten in Apigee Hybrid auswählen

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

Dienstkonto-Authentifizierung

Apigee Hybrid verwendet Google Cloud Dienstkonten zur Authentifizierung und Autorisierung von Komponenten, 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 benötigt 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 unterschiedlich verwaltet, was zu unterschiedlichen Sicherheitsstufen und unterschiedlicher betrieblicher Komplexität führt. Berücksichtigen Sie bei der Auswahl einer Methode Ihre Plattform, Ihre Sicherheitslage und Ihre bestehende 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
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. Bei dieser Methode werden die integrierten Funktionen zur Secret-Verwaltung in Kubernetes genutzt. Kubernetes-Secrets können eine sicherere Methode zum Verwalten von Schlüsseln als die direkte Dateispeicherung bieten. Sie verwalten die Schlüsselrotation weiterhin manuell.

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 direkt in einem Dateisystem gespeichert. Dieser Ansatz vereinfacht die Ersteinrichtung. Dazu ist es jedoch erforderlich, die Sicherheit des Dateisystems zu 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 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 Dienstkonto-Schlüsseldateien mit dem mit Apigee Hybrid bereitgestellten Tool create-service-account generieren und herunterladen. 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 der dynamischen Secret-Generierung, der Überwachung und der automatischen Schlüsselrotation. Dazu ist es erforderlich, eine Vault-Instanz einzurichten und zu verwalten.

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 Identitätsföderation von Arbeitslasten 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. Beim Installationsvorgang für 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 Identitätsföderation von Arbeitslasten für GKE in Ihrer Datei „overrides.yaml“ mit der Eigenschaft gcp.workloadIdentity.enabled.

Beispiel:

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

Weitere Informationen finden Sie unter Identitätsföderation von Arbeitslasten für GKE aktivieren.

Identitätsföderation von Arbeitslasten 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-externer Cluster bei Google Cloud authentifizieren. Dazu wird der OIDC-Anbieter Ihres Clusters verwendet, um eine Vertrauensbeziehung zwischen dem Identitätsanbieter Ihres Clusters und Google Cloudzu konfigurieren. Nach der Ersteinrichtung sind für diese Methode keine Dienstkontoschlüsseldateien mehr erforderlich.

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

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

Wenn Sie die Workload Identity Federation verwenden möchten, erstellen Sie für jedes Google Cloud Dienstkonto Konfigurationsdateien für Anmeldedaten. 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 Identitätsföderation von Arbeitslasten 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-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 entfällt die Notwendigkeit, Dienstkontoschlüsseldateien direkt zu verwalten.
  • Für Kubernetes-Bereitstellungen, die nicht in GKE erfolgen (AKS, EKS, OpenShift), bietet die Identitätsföderation von Arbeitslasten eine ähnliche schlüssellose Authentifizierung. Diese Methode wird für diese Umgebungen empfohlen.
  • Wenn die Workload Identity Federation for GKE oder die 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 höhere 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