Auf dieser Seite werden die Identitätstypen beschrieben, mit denen Sie den Zugriff Ihrer Arbeitslasten auf Cloud de Confiance by S3NS Ressourcen konfigurieren können.
Cloud de Confiance bietet die folgenden Identitätstypen für Arbeitslasten:
Mit der Identitätsföderation von Arbeitslasten und der Identitätsföderation von Arbeitslasten für GKE können Ihre Arbeitslasten über föderierte Identitäten, die über einen externen Identitätsanbieter (IdP) authentifiziert werden, auf die meisten Cloud de Confiance Dienste zugreifen. NachdemCloud de Confiance die Identität als Hauptkonto authentifiziert hat, kann das Hauptkonto mithilfe der von Ihnen gewährten IAM-Rollen auf Ressourcen zugreifen.
Cloud de Confiance Dienstkonten können als Identitäten für Arbeitslasten in Produktionsumgebungen fungieren. Anstatt direkt auf eine Arbeitslast Zugriff zu erteilen, gewähren Sie einen Zugriff auf ein Dienstkonto und lassen die Arbeitslast dann das Dienstkonto als Identität verwenden.
Mit verwalteten Arbeitslastidentitäten (Vorabversion) können Sie stark attestierte Identitäten an Ihre Compute Engine- und GKE-Arbeitslasten binden.
Welche Identitätstypen Sie für Arbeitslasten verwenden und wie Sie sie konfigurieren, hängt davon ab, wo Ihre Arbeitslasten ausgeführt werden.
Arbeitslasten auf Cloud de Confiancekonfigurieren
Wenn Sie Arbeitslasten auf Cloud de Confianceausführen, können Sie mit den folgenden Methoden Identitäten für Ihre Arbeitslasten konfigurieren:
- Angehängte Dienstkonten
- Workload Identity-Föderation für GKE (nur für Arbeitslasten, die in Google Kubernetes Engine ausgeführt werden)
- Verwaltete Arbeitslastidentitäten (nur für Arbeitslasten, die in Compute Engine und GKE ausgeführt werden)
- Dienstkontoschlüssel
Angehängte Dienstkonten
Bei einigen Cloud de Confiance Ressourcen können Sie ein nutzerverwaltetes Dienstkonto angeben, das von der Ressource als Standardidentität verwendet wird. Dieser Vorgang wird als Anhängen des Dienstkontos an die Ressource oder Verknüpfen des Dienstkontos mit der Ressource bezeichnet. Wenn Code, der auf der Ressource ausgeführt wird, auf Cloud de Confiance -Dienste und ‑Ressourcen zugreift, verwendet er das an die Ressource angehängte Dienstkonto als Identität. Beispiel: Sie hängen ein Dienstkonto an eine Compute Engine-Instanz an und die Anwendungen auf der Instanz verwenden eine Clientbibliothek, um Cloud de Confiance APIs aufzurufen. Diese Anwendungen verwenden automatisch das angehängte Dienstkonto für die Authentifizierung und Autorisierung.
In den meisten Fällen müssen Sie beim Erstellen einer Ressource ein Dienstkonto an eine Ressource anhängen. Nachdem die Ressource erstellt wurde, können Sie nicht mehr ändern, welches Dienstkonto an der Ressource angehängt ist. Compute Engine-Instanzen sind eine Ausnahme von dieser Regel. Sie können je nach Bedarf ändern, welches Dienstkonto an eine Instanz angehängt ist.
Weitere Informationen zu Dienstkonto an eine Ressource anhängen.
Workload Identity Federation for GKE
Bei Arbeitslasten, die in GKE ausgeführt werden, können Sie mit der Workload Identity-Föderation für GKE für jede Anwendung in Ihrem Cluster separate, detaillierte Hauptkonten IAM-Rollen zuweisen. Mit der Identitätsföderation von Arbeitslasten für GKE können Kubernetes-Dienstkonten in Ihrem GKE-Cluster direkt über die Identitätsföderation von Arbeitslasten oder indirekt über die Identitätsdiebstahl-Methode für IAM-Dienstkonten auf Cloud de ConfianceRessourcen zugreifen.
Mit dem direkten Ressourcenzugriff können Sie der Identität des Kubernetes-Dienstkontos direkt IAM-Rollen für die Ressourcen des Cloud de Confiance Dienstes zuweisen. Die meisten Cloud de Confiance APIs unterstützen den direkten Ressourcenzugriff. Bei der Verwendung der Identitätsföderation können jedoch bestimmte API-Methoden eingeschränkt sein. Eine Liste dieser Einschränkungen finden Sie unter Unterstützte Produkte und Einschränkungen.
Alternativ können Arbeitslasten auch die Identitätsübernahme des Dienstkontos verwenden. Dabei ist das konfigurierte Kubernetes-Dienstkonto an ein IAM-Dienstkonto gebunden, das beim Zugriff auf Cloud de Confiance-APIs als Identität dient.
Weitere Informationen zur Identitätsföderation von Arbeitslasten für GKE finden Sie unter Workload Identity Federation for GKE.
Verwaltete Arbeitslastidentitäten
Mit verwalteten Arbeitslastidentitäten können Sie stark attestierte Identitäten an Ihre Compute Engine- und GKE-Arbeitslasten binden. Sie können verwaltete Arbeitslastidentitäten verwenden, um Ihre Arbeitslasten über mTLS bei anderen Arbeitslasten zu authentifizieren.
Weitere Informationen zu verwalteten Workload Identitys und zur Konfiguration von Plattformen für ihre Verwendung finden Sie unter Verwaltete Workload Identitys – Übersicht.
Externe Arbeitslasten konfigurieren
Wenn Sie Arbeitslasten außerhalb von Cloud de Confianceausführen, können Sie mit den folgenden Methoden Identitäten für Ihre Arbeitslasten konfigurieren:
- Workload Identity-Föderation
- Dienstkontoschlüssel
Workload Identity-Föderation
Sie können die Workload Identity-Föderation mit Arbeitslasten aufCloud de Confiance oder externen Arbeitslasten verwenden, die auf Plattformen wie AWS, Azure, GitHub und GitLab ausgeführt werden.
Mit der Workload Identity-Föderation können Sie Anmeldedaten von externen Identitätsanbietern wie AWS, Azure und Active Directory verwenden, um kurzlebige Anmeldedaten zu generieren, mit denen Arbeitslasten vorübergehend die Identität von Dienstkonten übernehmen können. Arbeitslasten können dann über das Dienstkonto als Identität auf Cloud de Confiance-Ressourcen zugreifen.
Die Identitätsföderation von Arbeitslasten ist die bevorzugte Methode zum Konfigurieren von Identitäten für externe Arbeitslasten.
Weitere Informationen zur Workload Identity-Föderation finden Sie unter Workload Identity-Föderation.
Dienstkontoschlüssel
Mit einem Dienstkontoschlüssel kann sich eine Arbeitslast als Dienstkonto authentifizieren und dann die Identität des Dienstkontos für die Autorisierung verwenden.
Lokale Entwicklung
Wenn Sie Entwicklungen in einer lokalen Umgebung durchführen, können Sie Arbeitslasten so konfigurieren, dass entweder Ihre Nutzeranmeldedaten oder ein Dienstkonto für die Authentifizierung und Autorisierung verwendet werden. Weitere Informationen finden Sie in der Authentifizierungsdokumentation im Artikel Lokale Entwicklungsumgebung.