Schlüssellose Authentifizierung in der Google Cloud dank Identitätsföderationen. Wie die Workload Identity Federation die Verwendung von Dienstkontoschlüsseln bei der API-Authentifizierung ablöst. 

Ausgangslage

In einer zunehmend digitalisierten Arbeitswelt sind Cloud-basierte Infrastrukturen und die Automatisierung von Arbeitsabläufen unverzichtbar. Konzepte wie Infrastructure as Code (IaC) oder eine Versionsverwaltung, wie Git, spielen dabei eine zentrale Rolle. So ermöglicht beispielsweise IaC, Cloud-Infrastrukturen und Ressourcen mithilfe von Code zu definieren und zu verwalten. Kombiniert mit einer Plattform für Versionsverwaltung wie GitHub entsteht ein etabliertes Grundgerüst zur Verwaltung einer Cloud Infrastruktur.

Bei der Infrastrukturverwaltung in einem Cloud-externen Provider wie GitHub ist eine Form der Authentifizierung gegenüber dem Cloud-Provider erforderlich, um die entsprechenden Änderungen vorzunehmen. Eine der Möglichkeiten, diese Authentifizierung abzubilden und zu automatisieren, besteht in der Verwendung von Zugriffsschlüsseln.

In der Google Cloud Platform (GCP) werden diese als Dienstkontoschlüssel (Service Account Key) bezeichnet und ermöglichen den Zugriff auf Ressourcen über ein Dienstkonto (Service Account). Bei Amazon Web Services (AWS) werden diese Zugriffsschlüssel direkt Zugriffsschlüssel genannt und ermöglichen einen Zugriff auf einen IAM-Benutzer.

Dienstkontoschlüssel oder Zugriffsschlüssel sind langlebige und zugriffsstarke Anmeldeinformationen. Die Schlüssel werden beim API-Aufruf mitgeben und so der Aufruf authentifiziert. Die Schlüssel müssen sicher aufbewahrt, verwaltet und regelmäßig geändert (rotiert) werden. Wird dieser Verwaltungsaufwand der Schlüssel vernachlässigt, kann dadurch ein Sicherheitsrisiko entstehen.

In der GCP und AWS wird bei der Erstellung solcher Zugriffsschlüssel explizit auf die damit verbunden Risiken hingewiesen, wie Abbildung 1 und 2 zeigen. 

Um die entsprechenden Risiken zu vermeiden, können auch andere Wege der Authentifizierung gewählt werden. Neben der Verwendung von Dienstkontoschlüsseln kann in der Google Cloud beispielsweise auch eine Identitätsföderation verwendet werden, auf welche der Text in Abbildung 1 bereits hinweist. Diese Möglichkeit heißt in der Google Cloud „Workload Identity Federation“. 

Was ist die Workload Identity Federation?

Die Google Cloud Workload Identity Federation (WIF) ermöglicht eine einfache, sichere und schlüssellose Authentifizierung für Workloads außerhalb der Google Cloud, welche auf Google Cloud Ressourcen zugreifen. Mit WIF wird der bestehende Identity Provider (IdP) für die Authentifizierung von Benutzern und Workloads verwendet, ohne dass spezifische Google Cloud Anmeldeinformationen, wie beispielsweise Dienstkontoschlüsseln, erstellt und verwaltet werden müssen. Der Identity Provider ist ein System, welches digitale Identitäten von Benutzern verwaltet. Benutzer können sich beim IdP beispielsweise über Benutzername und Passwort authentifizieren und dann auf entsprechend verwaltete Ressourcen zugreifen. Wird der IdP als Vertrauensstelle in der Google Cloud eingetragen, entsteht eine sog. Identitätsföderation zwischen der GCP und dem IdP. Eingetragene Benutzer im IdP können dann mit entsprechenden Berechtigungen versehen werden und so auf Ressourcen in der Google Cloud zugreifen. Das Sicherheitsrisiko durch eine ungeregelte Verwaltung von Dienstkontoschlüssel sowie der Aufwand der sicheren Speicherung und Rotation entfallen, da durch die Identitätsföderation keine langlebigen Dienstkontoschlüssel, sondern kurzlebige Anmeldedaten, vergeben durch den IdP, verwendet werden können.

Die Verwendung der Workload Identity Federation bietet gegenüber Dienstkontenschlüsseln somit folgende Vorteile:

• Feingradige Zugriffskontrolle (fine-grained scoping)
• Kurzlebige Anmeldedaten (short-lived credentials)
  
• Geringer Verwaltungsaufwand (minimal Management Overhead)
  

Feingradige Zugriffskontrolle

Bei der Verwendung von Dienstkontenschlüsseln kann bei der Authentifikation nur zwischen erlaubtem Zugriff und nicht erlaubtem Zugriff unterschieden werden. Bei WIF hingegen kann eine Authentifikation basierend auf Attributen geschehen. So kann unter verschiedenen Anwendungen auch innerhalb eines eingetragenen Providers unterschieden werden und der Zugriff genau geregelt werden. 

Kurzlebige Anmeldedaten

Anders als Dienstkontenschlüssel sind Workload Identity Federation erstellte Anmeldedaten kurzlebig. Standardmäßig sind die Anmeldedaten eine Stunde gültig. Diese Zeitspanne kann jedoch geändert werden. Die kurze Lebensdauer reduziert das Zeitfenster für einen potenziellen Angreifer deutlich im Vergleich zu den langlebigen Dienstkontenschlüsseln, welche bis zur nächsten Schlüssel-Rotation gültig sind. 

Geringer Verwaltungsaufwand

Dienstkontenschlüssel sollten einer geregelten Verwaltung unterliegen, um diese sicher aufzubewahren, zu rotieren und zu verwenden. Dieser Verwaltungsaufwand der Schlüssel entfällt bei WIF gänzlich, da die kurzlebigen Anmeldedaten keine Rotation oder Verwaltung benötigen. Jedoch bleibt der Aufwand für die Verwaltung der feingradigen Zugriffskontrolle durch ein entsprechendes Rechtekonzept. 

​Funktionsweise

Grundlegend basiert die Authentifizierung bei WIF auf OpenID Connect (OIDC). OICD ist ein Identitätsprotokoll, welches auf OAuth 2.0 aufbaut und eine sichere und standardisierte Authentifizierung ermöglicht. Die Anwendungen, welche OIDC verwenden, müssen dabei selbst keine Anmeldedaten verwalten, da der Prozess der Authentifizierung und Identitätsverwaltung durch einen externen Identity Provider (IdP) übernommen wird.

Bei WIF wird dieser IdP in der Google Cloud als Google Cloud Workload Identity Provider in einen Identity Pool eingetragen. So wird eine Vertrauensbeziehung zwischen der Google Cloud und dem IdP hergestellt. Identity Pools sind dabei die Entitäten, in welchen diese Vertrauensbeziehungen verwaltet werden.

Darüber hinaus wird ein Dienstkonto erstellt, welcher für den Zugriff auf die Google Cloud Ressourcen verwendet wird. An dieses Dienstkonto werden die entsprechenden Berechtigungen vergeben, die den Zugriff auf die Ressourcen ermöglichen. Um den Identity Pools den Zugriff auf das Dienstkonto zu ermöglichen, muss noch eine Richtlinie (Policy) erstellt werden, die diese Übernahme des Dienstkontos ermöglicht (Impersonate Service Account).

Die vorbereitenden Schritte für die Verwendung von WIF können wie folgt zusammengefasst werden:

1. Aktivierung der „IAM Credentials API“
2. Erstellung eines Workload Identity Pools in der Google Cloud
3. Erstellung eines Providers im Workload Identity Pool und Herstellung einer Vertrauensbeziehung zwischen dem Identity Pool und einem externen Identity Provider
4. Erstellung eines Dienstkontos (Service Account)
5. Vergabe von Berechtigungen an den Identity Pool/den Service Account

Ablauf der Authentifizierung

Wurde die Workload Identity Federation erfolgreich eingerichtet, so kann die Authentifizierung nun ohne einen Schlüssel ablaufen. Die folgende Abbildung illustriert, wie der Aufruf von einem externen Workload authentifiziert wird. 

​1. Voraussetzungen

Vorbereitung und Einrichtung des Workload Identity Providers und des Service Accounts. 

2. Authentifizierung Identity Provider

Der Workload authentifiziert sich beim Identity Provider und erhält einen OIDC-Token von diesem. 

3. Authentifizierung der Google Cloud

Der Workload verwendet den vom Identity Provider erhaltenen OIDC-Token bei der Authentifizierung bei der Google Cloud. Der Security Token Service (STS) gleicht diesen mit den im Identity Pool hinterlegten Informationen ab. Ist der Identity Provider entsprechend eingetragen und die Attribute des Workloads erlauben einen Zugriff, gibt der STS kurzlebige Anmeldedaten zurück. 

4. Zugriff auf Google Cloud Ressourcen

Die vom Security Token Service (STS) ausgestellten kurzlebigen Anmeldedaten können letztlich verwendet werden, um auf ein Dienstkonto zuzugreifen (Impersonate Service Account). Über dieses Dienstkonto können dann Google Cloud Ressourcen erreicht werden. Jedoch nur diese, auf welche das Dienstkonto Berechtigungen erhalten hat. 

Beispielszenario

Das folgende Szenario zeigt die Funktionsweise und insbesondere den Ablauf der Authentifizierung anhand eines Beispiels. Es wird die Einrichtung der Workload Identity-Federation im Verbund mit GitHub sowie die Authentifikation in einem Workload aufgezeigt.

Der Zugriff auf die Google Cloud Ressourcen erfolgt aus einer GitHub Action heraus. GitHub Actions ist eine Continuous Integration/Continuous Delivery (CI/CD) Lösung, welche Software-Workflows in GitHub automatisiert. Für den Authentifikationsprozess in der GitHub Action wird die GitHub Action google-github-actions/auth verwendet. Diese Action wird wie folgt in den eigenen GitHub Actions-Workflow eingebaut:

Unter dem Attribut workload_identity_provider wird der Name des Identity-Pools eingetragen und unter dem Attribut service_account der Name des Dienstkontos, welches für den Zugriff verwendet werden soll.

Zur Vorbereitung auf der Google Cloud Seite werden die folgenden Schritte zu Einrichtung der Workload Identity Federation in der Google Cloud durchlaufen:

1. Aktivierung der „IAM Credentials API“ in der Google Cloud.
2. Erstellung des Dienstkontos und Vergabe der benötigten Berechtigungen.
3. Erstellung eines Workload Identity Pools.
4. Herstellen einer Vertrauensbeziehung zwischen dem Identity Pool und dem GitHub OIDC Provider (IdP). Hier werden zudem Attribute wie der Name des Repository oder der Benutzername des Ausführenden eingetragen.
5. Vergabe von Berechtigungen an den Identity Pool, hier die Berechtigung den Service Account zu übernehmen

1. Authentifizierung Google Cloud​

Die GitHub Action verwendet den vom GitHub OIDC-Provider erhaltenen OIDC-Token bei der Authentifizierung bei der Google Cloud. 

2. Abgleich der Informationen mit dem Identity-Pool​

Der Security Token Service (STS) gleicht die erhaltenen Attribute sowie den OIDC-Token mit den im Identity Pool hinterlegten Informationen ab. Ist der Identity-Provider entsprechend eingetragen und die Attribute des Workloads erlauben einen Zugriff, gibt der STS kurzlebige Anmeldedaten zurück. Die Attribute in dem Beispiel sind Informationen wie der Repository Name, der Benutzername oder der Event-Typ. Durch diese Informationen spiegelt sich die feingradige Zugriffskontrolle ab, da nur Workloads mit den hinterlegten Attributen den Zugriff erhalten.

3. Zugriff auf Google Cloud Ressourcen​

Die vom Security Token Service (STS) ausgestellten kurzlebigen Anmeldedaten können letztlich verwendet werden, um auf ein Dienstkonto zuzugreifen (Impersonate Service Account). Über dieses Dienstkonto können dann Google Cloud Ressourcen erreicht werden. Jedoch nur solche, auf die das Dienstkonto Berechtigungen erhalten hat. 

Fazit

Die Workload Identity Federation bietet neben der klassischen Verwendung von Dienstkontenschlüssel eine Möglichkeit, Cloud-externe Workloads zu authentifizieren und so den Zugriff auf Cloud-interne Ressourcen zu ermöglichen. Dabei wird der Authentifizierungsprozess vereinfacht und durch den Wegfall von langlebigen und verwaltungsaufwendigen Dienstkontenschlüsseln die Sicherheit verbessert. Die Integration in bestehende Workloads wird durch vorgefertigte Workloads vereinfacht. Eine Umstellung auf die Workload Identity Federation kann auch schrittweise pro Workflow erfolgen. Gerne unterstützt die ORDIX AG Sie bei diesem Vorhaben. Setzen Sie sich einfach mit uns in Verbindung. 

Seminarempfehlung