Dezentrales IAM und Multi-Cloud-Sicherheit: Zero Trust im großen Maßstab aufbauen

Die Ära des klassischen Sicherheitsmodells mit Burg und Wassergraben (Castle-and-Moat) ist vorbei. Wenn sich Ihre Infrastruktur über AWS, GCP, Azure und On-Premise-Umgebungen erstreckt, gibt es keinen festen Netzwerk-Perimeter mehr. In dieser Realität ist dezentrales IAM und Multi-Cloud-Sicherheit kein bloßes architektonisches Muster - es ist die einzig wirksame Verteidigung gegen laterale Bewegungen von Angreifern und raffinierte Supply-Chain-Angriffe. Die Identität des Anfordernden, ob Mensch oder Maschine, ist die neue Grenze.

Die meisten Organisationen scheitern daran. Sie versuchen, veraltete, zentralisierte Identity Provider (IdPs) in dynamische Multi-Cloud-Kubernetes-Cluster zu integrieren. Das führt zu fehleranfälligen Verknüpfungen, übermäßig vergebenen Berechtigungen und Single Points of Failure. In diesem Beitrag analysieren wir das Problem, schlagen eine klare Architektur vor und zeigen Ihnen genau, wie Sie diese implementieren, ohne die Entwicklungsgeschwindigkeit zu beeinträchtigen.

Das Problem: Die Hub-and-Spoke-Identitätsfalle

Wenn Unternehmen zum ersten Mal eine Multi-Cloud-Strategie einführen, leiten sie in der Regel die gesamte Authentifizierung und Autorisierung über ein einziges zentrales Verzeichnis (z. B. Active Directory oder eine Okta-Instanz). Dies schafft die Hub-and-Spoke-Identitätsfalle.

Jeder Dienst in AWS, der auf eine Datenbank in GCP zugreifen möchte, muss sich am zentralen Hub authentifizieren. Dieses Design weist drei kritische Schwachstellen auf:

1. Latenz: Eine Microservice-Architektur, die Hunderte von internen API-Aufrufen pro Sekunde durchführt, kann sich die Round-Trip-Latenz zu einem zentralen IdP nicht leisten.
2. Verfügbarkeit: Wenn der zentrale IdP ausfällt, steht die gesamte Multi-Cloud-Infrastruktur still.
3. Explosionsradius (Blast Radius): Ein kompromittiertes zentrales Verzeichnis gibt dem Angreifer die Schlüssel für das gesamte Königreich über alle Clouds hinweg in die Hand.

Sie müssen Identitäten lokal verifizieren, aber global verwalten.

Warum dezentrales IAM und Multi-Cloud-Sicherheit schwierig sind

Identität zu dezentralisieren bedeutet, Vertrauen zu verteilen. Das wiederum erfordert kryptografische Nachweise, die kontinuierlich validiert werden. Wenn eine Workload in AWS EKS ein Objekt in einem Google Cloud Storage-Bucket lesen muss, woher weiß GCP dann, dass es dem AWS-Pod vertrauen kann?

Der naive Ansatz besteht in langlebigen statischen Anmeldeinformationen (z. B. AWS Access Keys oder JSON-Dateien für GCP-Dienstkonten), die in Vault oder Kubernetes Secrets gespeichert werden. Das ist ein massives Anti-Pattern. Statische Zugangsdaten lecken, sie werden selten rotiert und sie verletzen das Kernprinzip von Zero Trust: kurzlebiger, genau definierter Zugriff.

Die Herausforderung besteht darin, Workload-Identitätsföderation über verschiedene Vertrauensdomänen hinweg aufzubauen. Sie müssen eine Identität in Domäne A (AWS OIDC-Provider) einer Rolle in Domäne B (GCP IAM) zuweisen, ohne langlebige Geheimnisse auszutauschen.

Die empfohlene Architektur: Workload Identity Federation

Wir plädieren für eine Architektur, bei der jede Umgebung als eigener Identity Provider (IdP) für die von ihr gehosteten Workloads fungiert. Diese lokalen IdPs föderieren das Vertrauen dann mit anderen Cloud-Umgebungen über OpenID Connect (OIDC).

Unsere Referenzarchitektur nutzt:

• Kubernetes (EKS v1.30): Zum Hosten der Workloads.
• AWS IAM OIDC Provider: Der lokale IdP für EKS.
• GCP Workload Identity Federation: Vertraut dem AWS OIDC-Provider.
• SPIFFE/SPIRE (v1.8.0): Für internes Service-zu-Service mTLS und die Ausstellung von Identitäten.

Anstatt Secrets zu übertragen, fordert die Workload ein kurzlebiges Token aus ihrer lokalen Umgebung an. Dieses Token wird vom lokalen IdP kryptografisch signiert. Die Zielumgebung (GCP) überprüft die Signatur, ordnet den OIDC-Claim einer lokalen IAM-Rolle zu und gewährt temporären Zugriff.

Implementierung: AWS EKS zu GCP BigQuery

Betrachten wir eine konkrete Implementierung. Wir haben einen Datenerfassungsdienst (Data Ingestion Service), der in einem AWS EKS-Cluster läuft und in ein GCP BigQuery-Dataset schreiben muss.

1. Konfigurieren des AWS EKS OIDC-Providers

Stellen Sie zunächst sicher, dass Ihrem EKS-Cluster ein IAM OIDC-Provider zugeordnet ist. Dies ermöglicht es Kubernetes-Servicekonten, IAM-Rollen anzunehmen, und bietet vor allem eine Aussteller-URL (Issuer URL), der GCP vertrauen kann.

1# Terraform v1.8.0
2# AWS Provider v5.40.0
3
4data "tls_certificate" "eks" {
5  url = aws_eks_cluster.main.identity[0].oidc[0].issuer
6}
7
8resource "aws_iam_openid_connect_provider" "eks" {
9  client_id_list  = ["sts.amazonaws.com"]
10  thumbprint_list = [data.tls_certificate.eks.certificates[0].sha1_fingerprint]
11  url             = aws_eks_cluster.main.identity[0].oidc[0].issuer
12}

2. Erstellen des GCP Workload Identity Pools

In GCP erstellen wir einen Workload Identity Pool und einen Provider. Der Provider verweist auf die AWS EKS OIDC-Aussteller-URL. Wir ordnen den sub-Claim (der den Kubernetes-Namespace und den Namen des Servicekontos enthält) einem Google IAM-Subjekt zu.

1# GCP Provider v5.20.0
2
3resource "google_iam_workload_identity_pool" "aws_pool" {
4  workload_identity_pool_id = "aws-eks-pool"
5  display_name              = "AWS EKS Trust Pool"
6  description               = "Identity-Pool für EKS-Workloads"
7}
8
9resource "google_iam_workload_identity_pool_provider" "aws_provider" {
10  workload_identity_pool_id          = google_iam_workload_identity_pool.aws_pool.workload_identity_pool_id
11  workload_identity_pool_provider_id = "aws-eks-provider"
12  display_name                       = "AWS EKS OIDC Provider"
13  
14  attribute_mapping = {
15    "google.subject" = "assertion.sub"
16    "attribute.namespace" = "assertion['kubernetes.io']['namespace']"
17  }
18  
19  oidc {
20    issuer_uri = aws_eks_cluster.main.identity[0].oidc[0].issuer
21  }
22}

3. Zuweisen des GCP-Servicekontos

Jetzt erstellen wir ein GCP-Servicekonto mit Schreibrechten für BigQuery und erlauben dem spezifischen Kubernetes-Servicekonto (über den Identity Pool), sich als dieses auszugeben (Impersonation).

1resource "google_service_account" "bq_writer" {
2  account_id   = "bq-writer-sa"
3  display_name = "BigQuery Writer Service Account"
4}
5
6resource "google_project_iam_member" "bq_data_editor" {
7  project = var.project_id
8  role    = "roles/bigquery.dataEditor"
9  member  = "serviceAccount:${google_service_account.bq_writer.email}"
10}
11
12resource "google_service_account_iam_member" "workload_identity_user" {
13  service_account_id = google_service_account.bq_writer.name
14  role               = "roles/iam.workloadIdentityUser"
15  
16  # Der Member-String entspricht dem Google-Subjekt-Mapping des Providers
17  # Format: principal://iam.googleapis.com/projects/PROJECT_NUMBER/locations/global/workloadIdentityPools/POOL_ID/subject/SUBJECT
18  member = "principal://iam.googleapis.com/${google_iam_workload_identity_pool.aws_pool.name}/subject/system:serviceaccount:data-ingest:bq-writer"
19}

4. Der Anwendungscode

Die in EKS ausgeführte Anwendung nutzt das Google Cloud SDK. Das SDK erkennt automatisch das von EKS bereitgestellte projizierte Servicekonto-Token, verwendet es zur Authentifizierung beim GCP Workload Identity Pool und ruft ein kurzlebiges Zugriffstoken für das bq-writer-sa ab. Es sind keine statischen Schlüssel erforderlich.

1# Definition des Kubernetes-Servicekontos und Pods
2apiVersion: v1
3kind: ServiceAccount
4metadata:
5  name: bq-writer
6  namespace: data-ingest
7  annotations:
8    # Optional: Wenn Sie auch AWS-Berechtigungen benötigen
9    eks.amazonaws.com/role-arn: arn:aws:iam::123456789012:role/bq-writer-role
10
11---
12apiVersion: v1
13kind: Pod
14metadata:
15  name: bq-writer-app
16  namespace: data-ingest
17spec:
18  serviceAccountName: bq-writer
19  containers:
20  - name: app
21    image: my-registry/bq-writer:v1.2.0
22    env:
23    # Google SDK mitteilen, wo die Konfiguration für die Anmeldedaten liegt
24    - name: GOOGLE_APPLICATION_CREDENTIALS
25      value: /var/run/secrets/google/credentials.json
26    volumeMounts:
27    - name: google-cloud-key
28      mountPath: /var/run/secrets/google
29    - name: k8s-token
30      mountPath: /var/run/secrets/tokens
31  volumes:
32  - name: google-cloud-key
33    configMap:
34      name: workload-identity-config
35  - name: k8s-token
36    projected:
37      sources:
38      - serviceAccountToken:
39          path: oidc-token
40          expirationSeconds: 3600
41          audience: sts.amazonaws.com # Oder Ihre GCP-Audience

Zu vermeidende Fallstricke

Die Implementierung dieser Architektur ist nicht ohne Risiken. Hier sind die häufigsten Fehlerbilder, die wir beobachten, wenn Teams dezentrales IAM einführen:

1. Zu breites Claim-Mapping

Achten Sie beim Konfigurieren des Attribut-Mappings des Workload Identity Providers darauf, keine zu allgemeinen Claims zuzuordnen. Wenn Sie "google.subject" = "assertion.aud" definieren, erlauben Sie jeder Workload im EKS-Cluster, sich als das GCP-Servicekonto auszugeben. Ordnen Sie das Mapping immer dem spezifischen sub (Subjekt) zu, welches den Namespace und den Namen des Servicekontos enthält (system:serviceaccount:namespace:sa-name).

2. Ignorieren des Token-Ablaufs

Projizierte Servicekonto-Token in Kubernetes laufen ab. Ihre Anwendung muss in der Lage sein, Anmeldeinformationen dynamisch neu zu laden. Die meisten modernen SDKs übernehmen dies automatisch, aber selbst geschriebene Autorisierungslogiken cachen Token oft unbegrenzt. Dies führt zu schwer zu debuggenden Fehlern, wenn das Token nach einer Stunde abläuft.

3. Vernachlässigung von Audit-Logs

Dezentralisierung kann die Sichtbarkeit einschränken. Sie müssen die Audit-Logs von AWS CloudTrail, GCP Cloud Logging und Ihrem Kubernetes-API-Server in einem zentralen SIEM aggregieren. Wenn eine Workload-Identität kompromittiert wird, müssen Sie in der Lage sein, ihre Aktionen über Cloud-Grenzen hinweg nachzuvollziehen. Stellen Sie sicher, dass Sie den sub-Claim aus dem OIDC-Token mit den resultierenden API-Aufrufen in der Zielumgebung korrelieren.

Das Ergebnis: Sicherheit als Wegbereiter

Der Übergang zu einer föderierten, dezentralen IAM-Architektur verändert das Sicherheitsniveau einer Software-Organisation grundlegend.

Durch die Eliminierung statischer Zugangsdaten beseitigen Sie den Hauptvektor für Supply-Chain-Angriffe. Wenn ein Entwickler Zugriff auf eine Cloud-übergreifende Ressource für einen neuen Dienst benötigt, fordert er keinen Schlüssel mehr beim Sicherheitsteam an. Er schreibt ein Terraform-Modul, um das Vertrauensverhältnis zu etablieren und die Richtlinie zu definieren.

Sicherheit wird zu Code. Vertrauen wird kurzlebig. Die Infrastruktur wird resilient. Dies ist der einzig gangbare Weg für professionelle Engineering-Teams, die im großen Maßstab operieren.