Migration von GCP IAM und Service Accounts nach STACKIT

Ein Service Account, sein Schlüssel und seine Rolle, bewertet

Eine kleine Identitätsumgebung, für diese Seite geschrieben und am 4. November 2026 von StackToIT bewertet (acht Ressourcen). Links das CI-Deployer-Konto, sein Schlüssel und seine Projektbindung. Rechts der einzige Block dieser Gruppe, den die Engine als Terraform schreibt; die Prüfkommentare darüber in der Datei sind hier weggelassen. Die Eingabeblöcke stehen in main.tf nicht direkt hintereinander; jeder steht deshalb wörtlich in einem eigenen Ausschnitt.

resource "google_service_account" "deployer" {
  account_id   = "ci-deployer"
  display_name = "CI deployer"
}

resource "google_service_account_key" "deployer" {
  service_account_id = google_service_account.deployer.name
}

resource "google_project_iam_member" "deployer_editor" {
  project = "shop-platform-prod"
  role    = "roles/editor"
  member  = "serviceAccount:${google_service_account.deployer.email}"
}

resource "stackit_service_account" "deployer" {
  project_id = var.project_id
  name       = "ci-deployer"
}

• Der Name bleibt, die Adresse nicht

  Der Kontoname stammt aus account_id. Die E-Mail-Adresse ändert sich, weil STACKIT sie erzeugt; jeder Verweis auf die alte Adresse mit iam.gserviceaccount.com braucht eine Anpassung. Googles Adressformat ist Name, Projekt-ID und iam.gserviceaccount.com; suchen Sie danach in Anwendungskonfiguration, Bucket-Richtlinien und CI-Variablen.

• Für den Anzeigenamen gibt es kein Feld

  stackit_service_account nimmt einen Namen und eine Projekt-ID, sonst nichts; der Anzeigename wird deshalb als nicht übernommen geführt. Halten Sie die Beschreibung in Ihrem eigenen Inventar fest.

• Acht Ressourcen, zwei Einheiten

  Nur die beiden Service Accounts sind Einheiten. Der Schlüssel hängt als Facette an der Deployer-Einheit. Die drei Projektbindungen, die eigene Rolle und die Workload-Identity-Bindung sind als Hilfsressourcen vermerkt, die keine Einheit liest; der Entwurf schreibt dafür nichts.

Was der Lauf einer Person überlässt

Aus demselben Lauf: ein Auszug der Deployer-Einheit aus assessment.json, mit den Werten genau so, wie der Lauf sie geschrieben hat. Zwei kritische Einstellungen bleiben offen: die Rollenbindungen und der langlebige Schlüssel.

{
  "id": "google_service_account.deployer",
  "facets": [
    "google_service_account_key.deployer"
  ],
  "result": {
    "class": "RECONFIGURE",
    "confidence": "MEDIUM",
    "target": {
      "resources": [
        "stackit_service_account",
        "stackit_authorization_project_role_assignment"
      ]
    },
    "findings": [
      {
        "severity": "info",
        "message": "Long-lived JSON keys are issued; they become STACKIT service account keys — or disappear where workload identity replaces them."
      }
    ],
    "semantics": {
      "critical_open": [
        "long-lived-keys",
        "role-bindings"
      ]
    }
  }
}

• Rollenbindungen: Eine Person ordnet sie neu zu

  Als Ziel jedes Kontos steht stackit_authorization_project_role_assignment, das der Provider als Teil eines zuschaltbaren iam-Features führt, das sich noch ändern kann. Der Lauf übersetzt roles/editor, roles/viewer oder die eigene Rolle nicht in STACKIT-Rollen; er legt je Konto einen Prüfeintrag an.

• Schlüssel: Entscheiden, ob sie bleiben

  Ein langlebiger JSON-Schlüssel wird markiert. Auch STACKIT-Service-Accounts können Schlüssel haben, und die STACKIT-Seite selbst empfiehlt, einen solchen Schlüssel wie ein Passwort der Anwendung zu behandeln; Google rät von Schlüsseln ab, wo immer es eine sicherere Alternative gibt. Entscheiden Sie je Aufrufer, ob er noch einen braucht.

• Die Ziele der Bindungen werden als unbekannt gelesen

  In diesem Lauf liest die Engine ein Mitglied der Form serviceAccount: plus erzeugte Kontoadresse als unbekannten Wert und kann daher nicht zeigen, wen eine Bindung nennt. Prüfen Sie die Bindungsliste von Hand gegen Ihren echten Richtlinienexport.

Wie die Google-Konstrukte zugeordnet werden

Die Zeilen zwei bis sieben stammen aus der Hilfsressourcen-Liste in terraform/README.md und engineering/review.csv. Googles eigene Empfehlung: Basisrollen in Produktion meiden; eine eigene Rolle gilt nur in dem Projekt oder der Organisation, in der sie angelegt wurde.

Die Migration in der richtigen Reihenfolge

1. 01

   Identitäten und Berechtigungen inventarisieren

   Exportieren Sie alle Service Accounts, Schlüssel, Bindungen und eigenen Rollen der zu migrierenden Projekte. Das Terraform der Umgebung zeigt, was Sie als Code verwalten; Bindungen aus der Konsole oder von anderen Werkzeugen stehen nicht darin, und der Lauf sieht sie nicht.

2. 02

   Jedes Konto einordnen

   Trennen Sie Laufzeitidentitäten von Anwendungen, CI-Identitäten und von Google verwaltete Service Agents. Für die letzte Gruppe gibt es meist kein Gegenstück bei STACKIT, das Sie anlegen müssten; bestätigen Sie das je Konto.

3. 03

   Konten anlegen

   Wenden Sie die Blöcke stackit_service_account an. STACKIT-Service-Accounts haben standardmäßig keinen Zugriff; Berechtigungen kommen aus Rollen, die im Projekt zugewiesen werden. Vor Schritt vier funktioniert also nichts.

4. 04

   Rollen bewusst zuweisen

   Wählen Sie je Bindung die STACKIT-Rolle mit den geringsten Rechten, die die Aufgabe erfüllt. Die Provider-Ressource nimmt resource_id, role und ein kleingeschriebenes subject; die verfügbaren Rollen fragen Sie über die Authorization-API ab.

5. 05

   Schlüssel durch Föderation ersetzen

   Ein STACKIT-Service-Account kann einem externen OIDC-Issuer vertrauen: Die Issuer-URL muss HTTPS ohne abschließenden Schrägstrich sein, eine aud-Assertion ist Pflicht, und es gibt nur Gleichheits-Assertions. Auch der Terraform-Provider kann sich so in CI anmelden, wodurch kein gespeicherter Schlüssel nötig ist.

6. 06

   Workloads umstellen und aufräumen

   Stellen Sie die Anwendungen auf die neuen Zugangsdaten um, beobachten Sie abgelehnte Aufrufe und löschen Sie Google-Konten und -Schlüssel erst nach einer ruhigen Phase. Das Löschen eines STACKIT-Service-Accounts ist endgültig; bewahren Sie also einen Export auf.

Entscheidungen, die Ihre Architekten treffen

• Das Rollenmodell

  Ob Sie Googles Berechtigungen spiegeln oder mit den STACKIT-Rollen neu beginnen. Spiegeln trägt alte Überberechtigungen wie roles/editor mit.

• Woher Workloads sich anmelden

  Pods, die Googles Cluster-Identität nutzten (die Bindung nennt einen Kubernetes-Service-Account in einem Projekt-Pool), haben bei STACKIT kein Gegenstück, bis Sie ihren Issuer föderieren oder ihnen einen Schlüssel geben.

• Wer Schlüssel erzeugen darf

  Ein Schlüssel ist das Passwort des Kontos. Legen Sie fest, wer einen ausstellen darf und wo er liegt, bevor der erste existiert.

• Projektgrenzen

  Der Lauf legt jede Ressource in das eine Projekt aus var.project_id und vermerkt, dass eine über mehrere Projekte verteilte Quelle darin zusammengefasst wird. Entscheiden Sie, wie viele Projekte Sie wollen, denn Rollenzuweisungen gelten je Projekt.

Fragen von Sicherheitsteams

Quellen

• Google Cloud: Übersicht zu Service Accounts
• Google Cloud: Best Practices für die Verwaltung von Service-Account-Schlüsseln
• Google Cloud: Übersicht zu IAM-Rollen
• Google Cloud: Workload Identity Federation für GKE
• STACKIT: Service Accounts
• STACKIT: Föderationen für Service Accounts verwalten
• STACKIT-Terraform-Provider v0.121.0: stackit_authorization_project_role_assignment
• STACKIT-Terraform-Provider v0.121.0: Authentifizierung und Experimente