Identitätsmanagement in Google Cloud Platform
Nicht täuschen lassen
Veröffentlicht in Ausgabe 10/2024 - SCHWERPUNKT
Die Google Cloud Platform (GCP) bietet eine breite Palette von Tools und Diensten, die Unternehmen dabei unterstützen, Identitäten sicher zu verwalten und den Zugriff auf Ressourcen zu kontrollieren. Die Aufgaben dieser Dienste sind dabei vielfältig und beinhalten die Benutzerverwaltung, die Authentifizierung inklusive Multifaktor-Authentifizierung und Single Sign-on (SSO) sowie die Autorisierung mitsamt Zugriffsrechten und Zugriffskontrolle. Ebenfalls zu nennen sind das Verwalten eines Verzeichnisdienstes und dessen Anbindung an andere Services wie zum Beispiel Microsoft Entra ID. Fortgeschrittene Szenarien betreffen die Föderation mit anderen Verzeichnisdiensten mittels Token-Tausch, sodass User und Anwendungen die Zugriffsdaten ihres Identitätsanbieters nutzen können, um auf Ressourcen in der Google-Cloud zuzugreifen.
Die Basis bildet Googles Cloud Identity
Im Mittelpunkt des Identitätsmanagements steht "Cloud Identity", eine zentrale Plattform für die Verwaltung von Identitäten in der Google-Umgebung. Diese ist zwar losgelöst von GCP, aber eine zwingende Voraussetzung für deren Nutzung. Cloud Identity dient als Basis für die Benutzer- und Gruppenverwaltung der meisten Google-Produkte. Das Einrichten geht relativ leicht von der Hand. Dabei fragt Sie das System nach dem Namen einer Domäne (in der Regel die eigene Firmen-Domäne), deren Besitz Sie mit dem Setzen eines TXT-Eintrages validieren. Die genauen Schritte zum Setup von Cloud Identity sowie wie das Anbinden an Entra ID zeigt unser Beitrag im IT-Administrator Sonderheft "Cloud Security" [1].
Standardmäßig ist bei Cloud Identity der Login mit Username und Passwort konfiguriert. Aus Sicherheitsgründen empfiehlt es sich aber, die 2-Faktor-Authentifizierung (2FA) zu aktivieren. Dabei stehen unterschiedliche 2FA-Methoden zur Verfügung: SMS, Backup-Codes, Einmalpasswörter (OTP) und mobile Push-Benachrichtigungen bieten einen guten Grundschutz, sind jedoch immer noch anfällig für Phishing-Angriffe. Je nach Einsatzgebiet sind unterschiedliche Verfahren empfohlen. Für den Basisschutz sind die genannten Ansätze durchaus ausreichend, jedoch empfiehlt Google zum Absichern hochprivilegierter Accounts wie zum Beispiel den Super User oder den Organization-Admin einen besseren Schutz wie "FIDO Universal 2nd Factor" (U2F), dessen Sicherheitsschlüssel äußerst resistent gegen Phishing sind. Dabei verwendet das U2F-Protokoll Kryptografie, um die Identität des Benutzers und die URLs der aufgerufenen Website zu verifizieren. Wichtig ist, dass die Schlüssel dabei auf dem Gerät verbleiben, sodass serverseitig geteilte Geheimnisse abgesichert sind, was gegen Phishing, Man-in-the-Middle- und Replay-Angriffe schützt.
Die Google Cloud Platform (GCP) bietet eine breite Palette von Tools und Diensten, die Unternehmen dabei unterstützen, Identitäten sicher zu verwalten und den Zugriff auf Ressourcen zu kontrollieren. Die Aufgaben dieser Dienste sind dabei vielfältig und beinhalten die Benutzerverwaltung, die Authentifizierung inklusive Multifaktor-Authentifizierung und Single Sign-on (SSO) sowie die Autorisierung mitsamt Zugriffsrechten und Zugriffskontrolle. Ebenfalls zu nennen sind das Verwalten eines Verzeichnisdienstes und dessen Anbindung an andere Services wie zum Beispiel Microsoft Entra ID. Fortgeschrittene Szenarien betreffen die Föderation mit anderen Verzeichnisdiensten mittels Token-Tausch, sodass User und Anwendungen die Zugriffsdaten ihres Identitätsanbieters nutzen können, um auf Ressourcen in der Google-Cloud zuzugreifen.
Die Basis bildet Googles Cloud Identity
Im Mittelpunkt des Identitätsmanagements steht "Cloud Identity", eine zentrale Plattform für die Verwaltung von Identitäten in der Google-Umgebung. Diese ist zwar losgelöst von GCP, aber eine zwingende Voraussetzung für deren Nutzung. Cloud Identity dient als Basis für die Benutzer- und Gruppenverwaltung der meisten Google-Produkte. Das Einrichten geht relativ leicht von der Hand. Dabei fragt Sie das System nach dem Namen einer Domäne (in der Regel die eigene Firmen-Domäne), deren Besitz Sie mit dem Setzen eines TXT-Eintrages validieren. Die genauen Schritte zum Setup von Cloud Identity sowie wie das Anbinden an Entra ID zeigt unser Beitrag im IT-Administrator Sonderheft "Cloud Security" [1].
Standardmäßig ist bei Cloud Identity der Login mit Username und Passwort konfiguriert. Aus Sicherheitsgründen empfiehlt es sich aber, die 2-Faktor-Authentifizierung (2FA) zu aktivieren. Dabei stehen unterschiedliche 2FA-Methoden zur Verfügung: SMS, Backup-Codes, Einmalpasswörter (OTP) und mobile Push-Benachrichtigungen bieten einen guten Grundschutz, sind jedoch immer noch anfällig für Phishing-Angriffe. Je nach Einsatzgebiet sind unterschiedliche Verfahren empfohlen. Für den Basisschutz sind die genannten Ansätze durchaus ausreichend, jedoch empfiehlt Google zum Absichern hochprivilegierter Accounts wie zum Beispiel den Super User oder den Organization-Admin einen besseren Schutz wie "FIDO Universal 2nd Factor" (U2F), dessen Sicherheitsschlüssel äußerst resistent gegen Phishing sind. Dabei verwendet das U2F-Protokoll Kryptografie, um die Identität des Benutzers und die URLs der aufgerufenen Website zu verifizieren. Wichtig ist, dass die Schlüssel dabei auf dem Gerät verbleiben, sodass serverseitig geteilte Geheimnisse abgesichert sind, was gegen Phishing, Man-in-the-Middle- und Replay-Angriffe schützt.
Cloud Identity bietet auch die Möglichkeit, 2FA mit einem externen Identitätsanbieter (IDP) wie Entra ID oder Okta zu verlangen. Bei dieser SSO-Option meldet sich ein Benutzer beispielsweise bei Entra ID an, indem er sein Passwort eingibt und nach einem erfolgreichen SAML-Austausch zwischen dem IdP und Google wird er mit der in Google eingerichteten 2FA-Methode überprüft. Auch das SSO zwischen Cloud Identity und Entra ID ist ausführlich in [1] beschrieben.
Um 2FA-Authentifizierung in der Cloud-Identity-Admin-Konsole zu aktivieren, benötigen Sie entweder die Super-User-oder User-Management-Admin-Rolle. So ausgestattet wechseln Sie in der Konsole auf die Seite "Sicherheit/Authentifizierung/2-Faktor-Authentifzierung". Um für verschiedene Personenkreise eine unterschiedliche Konfiguration vorzunehmen, legen Sie zuerst eine Gruppe mit den Nutzern an. Anschließend konfigurieren Sie diese Gruppe entsprechend.
In vielen Fällen nutzen Unternehmen Entra ID als führendes Identitätssystem und wollen dessen Identitäten auch für den Zugriff auch die Google-Cloud heranziehen. Die dabei gängigsten Szenarien sind:
- SSO-Konfiguration: Dies bedeutet, dass User, die sich an der Google-Konsole anmelden oder die gcloud CLI nutzen wollen, zu Entra ID weitergeleitet werden, sich dort authentifizieren und anschließend Zugriff auf Google erhalten. Damit dies gelingen kann, müssen Sie neben der Konfiguration von SSO dafür sorgen, dass alle Nutzer- und Gruppenkonten aus dem führenden Identitätssystem nach Google synchronisiert werden. Die notwendigen Schritte zeigt einmal mehr [1].
- Zugriff ohne SSO und User-Synchronisation: Falls eine SSO-Konfiguration nicht möglich ist, aber dennoch Benutzern Zugriff auf Cloudressourcen gewährt werden soll, kann Workforce Identity Federation zum Einsatz kommen.
- Dienstzugriff ohne SSO: Für den Fall, dass nicht Benutzer, sondern Dienstkonten beziehungsweise Applikationen auf Google-Cloudressourcen Zugriff erhalten sollen, nutzen Sie Workpool Identity Federation.
Anbinden externer Identitätsanbieter
Typischerweise kommt Workforce Identity Federation (WFIF) zum Einsatz, wenn ein externer Identitätsanbieter dazu dient, einer Gruppe von Nutzern wie zum Beispiel Mitarbeiter, Partner oder Auftragnehmer Zugriff auf GCP-Ressourcen zu ermöglichen. Darüber hinaus kommt WFIF mit einem Sicherheitsvorteil daher, weil dessen temporäre, kurzlebige Zugangstokens (anstelle von langfristigen Schlüsseldateien) Sicherheitsrisiken reduzieren und die Verwaltung von Zugangsrechten vereinfachen. WFIF nutzt im Hintergrund OpenID Connect (OIDC) und SAML 2.0, sodass Sie alle IDPs einsetzen können, die diese Standards unterstützen, also beispielsweise Entra ID, Active Directory Federation Services (ADFS) oder Okta.
Im Detail meldet sich ein Nutzer im Rahmen des WFIF-Prozesses zuerst einmal an. Dies kann auf einer speziellen Google-Anmeldeseite, in der Clientapplikation (wie zum Beispiel PowerBI) oder mittels API geschehen. Anschließend erfolgt eine Weiterleitung an den externen IDP. Sobald der Anmeldevorgang abgeschlossen ist, sendet der externe IDP ein valides Antwort-Token zurück. Dieses Token geht an WFIF, wird dort überprüft und dann folgt ein Tokentausch. Schließlich erlangt der Anwender mit dem erhaltenen Token Zugriff auf GCP-Ressourcen.
Workforce Identity Federation einrichten
Die WFIF-Konfiguration besteht in der Regel aus verschiedenen Schritten, die sich abhängig vom gewählten externen IDP unterscheiden. Im Folgenden stellen wir eine Verbindung mit Entra ID mittels OpenID her – alternativ wäre auch eine Konfiguration mittels SAML für das Active Directory möglich. Für unser Beispiel müssen wir die folgenden Schritte ausführen:
- Erlangen der notwendigen Rechte zur Konfiguration
- Erstellen von Workforce-Pools
- Anlegen einer Entra-ID-Anwendung
- Abrufen der notwendigen Information aus Entra ID
- Konfiguration des Workforce-Pool-Providers mit Information der Entra-ID-Anwendung
- Zugriff auf GCP-Ressourcen erteilen
- Testen des Zugriffs
Damit Sie mit der Konfiguration starten können, müssen Sie zuerst in Google IAM die IAM-Rolle "Mitarbeiteridentitätspool-Administrator" (roles/iam.workforcePoolAdmin) für die Organisation zuweisen. Anschließend erstellen Sie einen Workforce Pool, indem Sie in der Google-Konsole auf Organisationsebene die Seite "IAM / Workforce Identity Federation" aufrufen und auf "Create Pool" klicken. Hier geben Sie einen Namen für die Pool-ID und optional eine Beschreibung an. Anschließend wählen Sie "Next" und nach ein bis zwei Minuten ist der Pool verfügbar.
Nun wechseln Sie in das Entra-ID-Portal auf die Seite "App Registrations" und legen dort eine ebensolche an. Nachdem Sie einen Namen vergeben hat, wählen Sie unter "Redirect URI" die Option "Web" aus und hinterlegen die URI " https://auth.cloud. google/signin-callback/locations/global/ workforcePools/it-admin-pool/providers/ azure-ad-oidc-provider". Dabei ist "it-admin-pool" der vorher in Google erstellte Pool-Name und "azure-ad-oidc-provider" ein frei wählbarer Provider-Name. Mit einem Klick auf "Register" beenden Sie den Vorgang.
Bevor Sie einen "Entra ID Workforce Identity Pool Provider" anlegen, gilt es zuerst eine Reihe von Information aus Entra ID abzurufen. Als Erstes ist der "Issuer" der Entra ID App Registration zu ermitteln, den Sie unter "App Registration" finden, indem Sie dort oben auf "Endpoints" klicken und den Wert des "OpenID Connect metadata document"-Felds abrufen. Wichtig ist an dieser Stelle, den Suffix "/.well-known/openid-configuration" zu entfernen. Anschließend brauchen Sie noch die "Application (client) ID" und ein "Client Secret". Beide erzeugen Sie unter "Manage / Certificates & Secrets". Mit diesen Informationen wechseln Sie zurück in die Google-Konsole.
Nun richten Sie innerhalb des Workforce-Pools den Provider ein. Dazu wählen Sie im Pool die Schaltfläche "Add Provider" und als Protokoll "OpenID Connect (OIDC)" aus. Auf der folgenden Maske definieren Sie eine eindeutige ID, optional eine Beschreibung und geben den vorher notierten Issuer ("Open ID Connect Metadata Document") sowie die Client-ID ein. Anschließend klicken Sie auf "Continue" und hinterlegen auf der folgenden Seite den "Response Type". Mit der Option "Code" aktivieren Sie ein webbasiertes Single Sign-on. Zusätzlich tragen Sie das Client-Secret ein.
Jetzt müssen Sie noch die Entra-ID-Attribute auf die Google-Attribute mappen. Das ist wichtig, damit Google Informationen wie den Usernamen und die Gruppenmitgliedschaft erhält. Die Konfiguration erfolgt mit der Common Expression Language (CEL) und Sie hinterlegen die folgenden Zeilen, bevor Sie den Assistenten abschließen:
google.subject=assertion.sub,
google.groups=assertion.groups,
google.display_name=assertion.preferred_username
Nachdem der Provider konfiguriert ist, vergeben Sie die entsprechenden Berechtigungen auf Cloudressourcen. Diese Rechte erhalten Benutzer und Gruppen nicht direkt, sondern sie orientieren sich an Identitäten innerhalb eines Workforce-Pools. Dies können einzelne User, Gruppen oder eben andere Elemente sein, für deren Attribute Sie zuvor ein Mapping durchgeführt haben. Als Beispiel vergibt der folgende Code mittels des subject-Attributs Cloud-Storage-Berechtigungen innerhalb eines Projekts:
gcloud projects add-iam-policy-binding playground-258112 \
--role="roles/storage.admin" \
--member="principal://iam.google-apis.com/locations/global/work-forcePools/it-admin-pool/subject/ guido.soeldner@soeldner-consult.de"
Um Ihre Einstellung nun zu testen, wechseln Sie auf die Google-Seite zum föderierten Zugriff ("https://auth.cloud. google/signin?continueUrl=https://console.cloud.google/") und geben den vollständigen Namen des Providers an. In unserem Fall lautet dieser "locations/global/workforcePools/it-admin-pool/providers/it-admin-provider". Jetzt gelangen Sie auf die Entra-ID-Login-Seite und nach erfolgreicher Credential-Eingabe wieder zurück auf die Google-Cloud-Konsole. Indem Sie oben rechts auf den Avatar klicken, überprüfen Sie die Attributsübergabe und sehen das entsprechende Konto des Benutzers.
Praxisbeispiel Zugriff auf PowerBI
Ein guter Anwendungsfall für WFIF ist der Zugriff auf BigQuery mittels Tools wie Microsoft PowerBI. Google BigQuery ist eine der führenden Big-Data-Warehouse- und Analytics-Plattformen, und so ist es oft notwendig, aus Clientapplikationen wie PowerBI darauf zuzugreifen.
Die zur Konfiguration notwendigen Schritte gleichen in vielem dem soeben beschriebenen Vorgehen und wir wollen daher nicht alle wiederholen: Zuerst müssen Sie einen Workload-Pool in Google erstellen, anschließend eine Entra-ID-Applikation erzeugen, einen Entra ID Workforce Identity Pool Provider konfigurieren und zuletzt entsprechende Berechtigungen vergeben.
Nachdem Sie auf dem bereits beschriebenen Weg einen Workload-Pool und eine Entra-ID-Applikation angelegt haben, ist es innerhalb Entra ID noch notwendig, Berechtigungen zu setzen, um User- und Gruppeninformationen an Power BI über- mitteln zu können. Dies gelingt, indem Sie innerhalb der Entra-ID-Applikation auf die Seite "API Permissions" wechseln. Dort wählen Sie unter "Configured Permissions" die Option "Add Permissions" aus. Nun klicken Sie "Request API Permission" und dann "Microsoft Graph". In der nächsten Maske selektieren Sie "Application Permission" und fügen die Berechtigung "User. ReadBasic.All" hinzu. Jetzt wiederholen Sie dies, doch entscheiden sich für "GroupMember.Read.All".
Nun erzeugen Sie den Provider, am besten per CLI. Dabei referenzieren Sie mit der Option "workforce-pool" den bereits erstellten Workforce-Pool. Bei "Issuer URL" hinterlegen Sie die "Tenant ID" von Entra ID. Die Werte für "extra-attribute-issuer-uri", die Client-ID und das Client-Secret sind bereits aus den vorherigen Schritten bekannt. Insgesamt gehen Sie also so vor wie in Listing 1, ändern dabei jedoch die Beispielwerte in die für Sie relevanten.
Listing 1: Provider per CLI erzeugen
gcloud iam workforce-pools providers create-oidc it-admin-power-bi-provider \
--workforce-pool=it-admin-pool \
--location=global \
--display-name=PowerBiProvider \
--issuer-uri=https://sts.windows.net/babcf8c6-dfac-4377-b0cd-c8c67d0184bb \
--client-id=https://analysis.windows.net/powerbi/connector/GoogleBigQuery \
--attribute-mapping=google.subject=assertion.sub \
--web-sso-response-type=id-token \
--web-sso-assertion-claims-behavior=only-id-token-claims \
--extra-attributes-issuer-uri=https://login.microsoftonline.com/babcf8c6-dfac-4377-b0cd-c8c67d0184bb/v2.0 \
--extra-attributes-client-id=bcf964ba-9fe6-41a9-9d5b-13d903204790 \
--extra-attributes-client-secret-value=-ABCF \
--extra-attributes-type=azure-ad-groups-mail
Auch die Berechtigung erfolgt nun wieder analog – allerdings sind nun Rechte für Big Query notwendig. Der folgende Befehl erteilt Viewer-Berechtigungen auf Big Query:
gcloud projects add-iam-policy-binding playground-258112\
--role="roles/bigquery.dataViewer" \
--member="principalSet: //iam.googleapis.com/locations/global/workforcePools/it-admin-pool/group/GROUP_ID"
Nun testen Sie den Zugriff aus Power BI. In der Desktop-App klicken Sie dazu auf "Daten abrufen", dann auf "Datenbank" und wählen nun "Google BigQuery (Azure AD) (Beta)" aus der Liste der Datenbanken aus. Ein Klick auf "Verbinden" bringt folgende Pflichtfelder zum Vorschein:
- Abrechnungs-Projekt-ID: Dies ist die Projekt-ID, in der sich das Big Query Dataset befindet.
- Zielgruppen-URI, mit dem Pool und Provider codiert: "//iam.googleapis.com/ locations/global/workforcePools/it-admin-pool-power-bi/providers/it-admin-power-bi-provider"
Abschließend wählen Sie "OK" und "Next" und sind jetzt in der Lage, Daten abzurufen.
Ressourcen für externe Workloads bereitstellen
Während es mittels der Workforce Identity Federation möglich ist, Nutzern externer IDPs Zugriff auf Google zu gewähren, hat Workload Identity Federation (WLIF) das Ziel, externen Arbeitslasten den Zugang zu erlauben. Szenarien dafür gibt es genug: In erster Linie Multi-Cloud-Umgebungen, aber auch der Zugriff aus Tools wie zum Beispiel GitLab oder Terraform sind relevante Szenarien.
Einer der Vorteile von WLIF ist, dass Sie für Service-Accounts keine Dienstschlüssel mehr erzeugen und verwalten müssen. Weiterhin sind Sie in Sachen Sicherheit besser aufgestellt, denn wenn keine Dienstschlüssel mehr existieren, müssen Sie auch deren Zugriff nicht mehr kontrollieren. Zudem erlaubt die Integration mit gängigen Identitätsanbietern und Identity-Federation-Standards (OpenID Connect, SAML) eine einfache und flexible Implementierung.
Google unterstützt dabei eine Reihe von IDPS wie AWS, Entra ID, GitHub, GitLab, Kubernetes Cluster, Okta, lokale Active Directory Federation Services und Terraform. Auch ermöglichen die fein abgestuften Zugriffskontrollen mittels IAM-Richtlinien, dass Arbeitslasten nur auf notwendige Ressourcen zugreifen können. Zu guter Letzt gewährleisten das Vermeiden einer Schlüsselverwaltung und die Nutzung sicherer, zeitlich begrenzter Tokens die Erfüllung strenger Sicherheits- und Compliance-Anforderungen.
Die Funktionsweise von Workload Identity Federation (siehe Bild 2) umfasst folgende Schritte: Ein Workload, der lokal oder bei einem anderen Cloudanbieter läuft, sendet eine Anfrage zur Authentifizierung an den IDP. Dieser authentifiziert die mit dieser Arbeitslast verbundene Identität und gibt Credentials zurück. Anschließend kann der Workload einen Aufruf an den Google Cloud Secure Token Service (STS) durchführen und dabei die vom IDP ausgegebenen Credentials übermitteln. STS validiert das übermittelte Token und gibt ein kurzlebiges Token zurück. Die Arbeitslast verwendet dieses Token, um einen Identitätswechsel des Dienstkontos durchzuführen. Im letzten Schritt gelingt der Zugriff auf die GCP-Ressourcen.
Workload Identity Federation in der Praxis
Ein häufig vorkommendes Szenario für Workload Identity Federation ist die Kopplung von GitLab-CI und GCP. Beim Setup ist jedoch darauf zu achten, dass die GitLab-Instanz von der Google-Cloud erreichbar ist. Dergestalt ist es möglich, Zugriffsdaten für eine Pipeline dynamisch zu erzeugen, anstatt Credentials statisch in GitLab-Variablen hinterlegen zu müssen. Diese Konfiguration ermöglicht es, Terraform-Deployments GitOps-mäßig auszuführen, sodass Repositories nur auf ausgewählte Google-Projekte Zugriff erhalten.
Schauen wir uns die praktische Umsetzung dieses Anwendungsfalls an: Zuerst muss die Konfiguration des Identity-Pools erfolgen. Diesen müssen Sie jedoch innerhalb eines Projekts anstatt auf Organisationsebene erstellen (anderes als beim Workforce-Pool). Das Anlegen eines Workload-Identity-Providers erfolgt ähnlich und erfordert in GitLab bei "Issuer URL" den Namen der GitLab-Instanz und bei "Allowed Audience" die Instanz, die Zugriff erhalten soll. Nun müssen Sie ein Mapping bereitstellen, damit möglichst viele GitLab-Attribute wie Project ID, User oder Namespace an GCP übermittelt. Typische Mapping-Attribute können wie folgt aussehen:
google.subject assertion.sub
attribute.aud assertion.aud
attribute.project_path assertion.project_path
attribute.project_id assertion.project_id
attribute.namespace_id attribute.namespace_id
attribute.namespace_path assertion.namespace_path
attribute.user_email assertion.user_email
attribute.ref attribute.ref
attribute.ref_type attribute.ref_type
Da die Konfiguration pro Projekt erfolgt, lassen sich einfach Einschränkungen hinterlegen. Wenn Sie beispielsweise in GitLab eine Ordnerstruktur analog zu der Hierarchie in GCP hinterlegt haben, ist es einfach, eine entsprechende Bedingung zu hinterlegen.
Das folgende Beispiel zeigt, wie Sie die Nutzung mittels CEL einschränken:
matches(assertion.namespace_path, "deployment-it-admin-project.*")
Jetzt gilt es noch, Berechtigungen zu vergeben. Dies gelingt, wie bereits vorher gezeigt, wie folgt:
principalSet://iam.googleapis.com/projects/PROJECT_NUMBER/locations/global/workloadIdentityPools/POOL_ID/attribute.user_login/guido.soeldner
Nunmehr lässt sich die GitLab-CI-Pipeline so anpassen, dass Credentials automatisch erzeugt werden. Dazu definieren Sie in der Pipeline zunächst einen neuen Job:
job:
id_tokens:
GITLAB_OIDC_TOKEN:
aud: https://gitlab.example.com
Listing 2: Temporäres Token erzeugen
PAYLOAD="$(cat <EOF
{
"audience": "//iam.googleapis.com/projects/PROJECT_NUMBER/locations/global/workloadIdentityPools/POOL_ID/providers/PROVIDER_ID",
"grantType": "urn:ietf:params:oauth:grant-type:token-exchange",
"requestedTokenType": "urn:ietf:params:oauth:token-type:access_token",
"scope": "https://www.googleapis.com/auth/cloud-platform",
"subjectTokenType": "urn:ietf:params:oauth:token-type:jwt",
"subjectToken": "${GITLAB_OIDC_TOKEN}"
}
EOF
)"
FEDERATED_TOKEN="$(curl --fail "https://sts.googleapis.com/v1/token" \
--header "Accept: application/json" \
--header "Content-Type: application/json" \
--data "${PAYLOAD}" \
| jq -r '.access_token'
Nun erzeugen Sie ein temporäres Token, wie in Listing 2 zu sehen. Dieses Token wandeln Sie anschließend in der Pipeline in ein Access-Token für den entsprechenden Service-Account um (Listing 3). Um nun Terraform zu nutzen, ist es notwendig, die Kommandos aus Listing 4 mit den erhaltenen Werten auszuführen. Nun ist es einfach möglich, Terraform in der Pipeline auszuführen.
Listing 3: Token umwandeln
ACCESS_TOKEN="$(curl --fail "https://iamcredentials.googleapis.com/v1/projects/-/serviceAccounts/SERVICE_ACCOUNT_EMAIL:generateAccessToken" \
--header "Accept: application/json" \
--header "Content-Type: application/json" \
--header "Authorization: Bearer FEDERATED_TOKEN" \
--data '{"scope": ["https://www.google-apis.com/auth/cloud-platform"]}' \
| jq -r '.accessToken'
)"
Listing 4: gcloud-auth-Befehl ausführen
gcp-auth:
image: google/cloud-sdk:slim
extends: .id_tokens
script:
- echo ${GITLAB_OIDC_TOKEN} > .ci_job_jwt_file
- gcloud iam workload-identity-pools create-cred-config ${GCP_WORKLOAD_IDENTITY_PROVIDER}
--service-account="${GCP_SERVICE_ACCOUNT}"
--output-file=.gcp_temp_cred.json
--credential-source-file=.ci_job_jwt_file
- gcloud auth login --cred-file=`pwd` /.gcp_temp_cred.json
- gcloud auth list
Fazit
Workforce Identity Federation und Work-load Identity Federation verbessern erheblich die Sicherheit und Verwaltung von Zugriffen auf Cloudressourcen. Sie ermöglichen es Unternehmen, Identitäten aus externen Anbietern nahtlos und sicher zu integrieren, ohne auf langfristige Schlüssel angewiesen zu sein, was das Risiko von Schlüsselkompromittierungen verringert. Zudem erleichtern sie die Einhaltung von Compliance-Anforderungen und reduzieren den administrativen Aufwand durch die Automatisierung und Zentralisierung von Identitätsmanagement-Prozessen.
(jp)
Link-Codes
[1] IT-Administrator Sonderheft "Cloud Security", Seite 43: Google Cloud Identity und IAM: https://it-a.eu/o0z31