IDENTITÄT · AWS, AZURE, GOOGLE CLOUD → STACKIT
Cloud-IAM und Identitäten zu STACKIT migrieren
Richtlinien ziehen nicht um, Identitäten schon. Auf STACKIT wird eine Maschinenidentität aus AWS, Azure oder Google Cloud zu einem Service Account, Personen melden sich über den Identity Provider Ihrer Organisation an, und was die Identität darf, wird zu einer Rollenzuweisung, die Sie wählen, denn StackToIT übersetzt keine Cloud-Aktionen in STACKIT-Rollen. Drei kleine Läufe vom 4. November 2026 zeigen, was die Entwürfe schreiben, was sie Ihnen überlassen und warum die Zugriffsschlüssel der Teil sind, den Sie zuerst planen.
Wie jede Quellidentität abgebildet wird
Eine Zeile je Identitätsart, aus drei Läufen: einer AWS-Umgebung mit 11 Ressourcen sowie je einer Umgebung mit 4 Ressourcen für Azure und Google Cloud.
| Quellidentität | STACKIT-Ziel, das der Entwurf schreibt | Was bei Ihnen bleibt |
|---|---|---|
| AWS-IAM-User mit Access Key und ohne Konsolenzugang | Ein Service Account, ein Service-Account-Key und Rollenzuweisungen im Projekt | Die Rollen, die Laufzeit des Keys und die Übergabe des neuen Keys an jeden Aufrufer des alten |
| AWS-IAM-Rolle einer EC2-Instanz mit Instance Profile | Ein an den Server angehängter Service Account mit Rollenzuweisungen | Die Rollen und die Berechtigung, beim Anhängen als der Account zu handeln |
| AWS-IAM-Gruppe | Eine Gruppe im Identity Provider; die Rollen gehen an ihre Mitglieder | Wer die Mitglieder sind und welche Rollen sie erhalten |
| Azure User-assigned Managed Identity | Nur ein Service Account; die Rollenzuweisungen überlässt der Entwurf einer Person | Zuordnung der Resource Groups zu Projekten, der Code jedes Verbrauchers, die Rollen |
| Google Service Account mit Bucket- und Projektbindungen | Ein Service Account; die Bindungen prüft eine Person | Die Rollen und der Code von Workloads, die den Metadata-Server nutzten |
Im AWS-Lauf wurden aus 11 Ressourcen 5 Einheiten: Richtlinie, Anhänge, Mitgliedschaft, Instance Profile und Access Key gehen in User, Rolle, Gruppe und Instanz auf, zu denen sie gehören. Die Entwürfe für Azure und Google Cloud schreiben den Principal und lassen die Berechtigungen als offene Einstellungen. Nur der AWS-Entwurf schrieb Ressourcen für Rollenzuweisungen.
Aus einer Instanzrolle wird ein angehängter Service Account
Links: eine EC2-Rolle und ihr Instance Profile, wie die AWS-Quelle sie deklariert. Rechts: drei Blöcke des STACKIT-Entwurfs in identity.tf, ohne die Kommentarzeilen über den Blöcken.
resource "aws_iam_role" "app" {
name = "reports-app"
assume_role_policy = jsonencode({
Version = "2012-10-17"
Statement = [{ Effect = "Allow", Action = "sts:AssumeRole", Principal = { Service = "ec2.amazonaws.com" } }]
})
}
resource "aws_iam_instance_profile" "app" {
name = "reports-app"
role = aws_iam_role.app.name
}resource "stackit_service_account" "app" {
project_id = var.project_id
name = "app"
}
resource "stackit_authorization_project_role_assignment" "app" {
for_each = toset(var.app_project_roles)
resource_id = var.project_id
role = each.value
subject = stackit_service_account.app.email
}
resource "stackit_server_service_account_attach" "app" {
project_id = var.project_id
region = var.region
server_id = stackit_server.app.server_id
service_account_email = stackit_service_account.app.email
}Die Rollen sind eine Variable
Die Rollenzuweisung liest var.app_project_roles. Die Beschreibung der Variable nennt, was die Quellrichtlinie erlaubt – s3:GetObject und s3:PutObject – und überlässt die Wahl der STACKIT-Rollen Ihnen.
Die Berechtigung reicht weiter als die Richtlinie
Die AWS-Richtlinie nannte einen Bucket. Eine Rollenzuweisung im Projekt gilt für das ganze Projekt, und der Entwurf sagt das: Nutzen Sie Bindungen je Ressource, wo der STACKIT-Dienst sie anbietet.
Das Instance Profile hat kein Objekt
Der Entwurf vermerkt, dass STACKIT kein Instance Profile kennt: Der Server handelt direkt als angehängter Service Account, und Trust Policy, Sitzungsdauer und Permissions Boundary der Rolle werden nicht übernommen.
Zwei Fallen beim Anhängen
Das Anhängen verlangt das Recht, als der Account zu handeln. Der Entwurf hält fest, dass ein Anhängen etwa eine halbe Sekunde nach dem Anlegen des Accounts mit 403 und rund sieben Sekunden später mit 201 beantwortet wurde; wiederholen Sie den Vorgang also, bevor Sie ein Berechtigungsproblem vermuten.
Aus einem Access Key wird ein Service-Account-Key
Links: der CI-User mit seinem Access Key. Rechts: der Service Account, sein Key und die erste Rollenzuweisung aus demselben Entwurf; Kommentare über den Blöcken sind weggelassen.
resource "aws_iam_user" "ci" {
name = "ci-deploy"
}
resource "aws_iam_access_key" "ci" {
user = aws_iam_user.ci.name
}resource "stackit_service_account" "ci" {
project_id = var.project_id
name = "ci"
}
resource "stackit_service_account_key" "ci" {
project_id = var.project_id
service_account_email = stackit_service_account.ci.email
ttl_days = var.ci_key_ttl_days
}
resource "stackit_authorization_project_role_assignment" "ci" {
count = length([stackit_service_account.ci.email]) * length(var.ci_project_roles)
resource_id = var.project_id
role = var.ci_project_roles[count.index % length(var.ci_project_roles)]
subject = [stackit_service_account.ci.email][floor(count.index / length(var.ci_project_roles))]
}Der Key hat eine Laufzeit
ttl_days liest var.ci_key_ttl_days. Die Beschreibung der Variable vermerkt, dass die AWS-Access-Keys nicht ablaufen und ein STACKIT-Key ohne ttl_days gültig bleibt, bis er gelöscht wird.
Das Geheimnis reist nicht mit
Die Zugangsdaten sind die sensible JSON-Ausgabe des Keys, von STACKIT erzeugt. Das AWS-Secret wird nie gelesen oder übernommen, und der neue Key erreicht die Aufrufer über einen manuellen Übergabeschritt.
Der alte Key bleibt bis zum GO
Der Rollback der Übergabe besteht darin, die Aufrufer zurück auf den AWS-Key zu schalten, der bis zur Stilllegung des Users nach der GO-Entscheidung aktiv bleibt.
Föderation ist eine Frage, kein Ergebnis
Die Datei zum Identitätsübergang führt das statische Credential dieses Users als „beobachtet“ und die Workload Identity Federation als „Nachweis erforderlich“. Der Lauf behauptet nie, dass Föderation den Key ersetzen kann.
Azure: Die Identität zieht um, die Rollenzuweisung wartet auf eine Person
Links: eine User-assigned Managed Identity und ihre Blob-Rollenzuweisung. Rechts: der einzige Block, den der Entwurf dafür schreibt.
resource "azurerm_user_assigned_identity" "app" {
name = "id-reports-app"
resource_group_name = azurerm_resource_group.app.name
location = azurerm_resource_group.app.location
}
resource "azurerm_role_assignment" "app_blob" {
scope = azurerm_storage_account.reports.id
role_definition_name = "Storage Blob Data Contributor"
principal_id = azurerm_user_assigned_identity.app.principal_id
}resource "stackit_service_account" "app" {
project_id = var.project_id
name = "app"
}Drei offene Einstellungen
Der Plan fragt eine Person nach dem Geltungsbereich der Resource Group, dem Code ohne Credentials und den Rollenzuweisungen. Jede Azure-Rolle wird von Hand neu zugeordnet.
Code ändert sich bei jedem Verbraucher
Code, der eine Managed Identity nutzte, hält meist gar keine Credentials. Auf STACKIT braucht er Service-Account-Credentials oder Workload Identity, also ändert sich jeder Verbraucher, nicht nur die Infrastruktur.
Wo der Google-Cloud-Entwurf landet
Der Service Account wird genauso abgebildet, und seine E-Mail-Adresse ändert sich: Verweise auf die alte Adresse müssen angepasst werden. Die Bindung auf Projektebene prüft eine Person.
Die Schritte, der Reihe nach
Allgemeine Praxis, an die Dateien eines Laufs gebunden.
Den Identitätsübergang lesen
assurance/identity-transition.md führt jeden Workload auf, seine statischen Credentials und ob das Anhängen an einen Server exakt ist. Die Datei nennt auch, was sie nicht bewertet: Rechtedelta, Break-Glass-Zugang und menschliche Identität.
Personen und Workloads trennen
Personen melden sich über den Identity Provider der Organisation an, und Gruppen werden dort neu angelegt. Der Entwurf führt die Mitglieder in einer Variable und weist Rollen je User, Service Account oder Client zu, nicht je Gruppe.
Die Rollen wählen
Listen Sie für jede Variable wie app_project_roles die Rollen auf, die STACKIT im Projekt anbietet, und wählen Sie den engsten Satz, der abdeckt, was die alte Richtlinie erlaubte.
Accounts anlegen, dann anhängen
Legen Sie zuerst die Service Accounts an und geben Sie dem Principal, der den Entwurf ausrollt, die Berechtigung, in ihrem Namen zu handeln. Hängen Sie danach an die Server an und wiederholen Sie einmal, wenn die erste Antwort 403 ist.
Keys übergeben oder auf Föderation umstellen
Geben Sie jedem Aufrufer eines alten Access Keys sein neues Credential, oder richten Sie einen föderierten Identity Provider ein, der dem OIDC-Issuer des Aufrufers vertraut. STACKIT dokumentiert, dass die Issuer-URL dem exakten iss-Wert der Token entsprechen muss.
Quellidentitäten zuletzt stilllegen
Der Plan legt die Stilllegung von Usern und Rollen hinter die GO-Entscheidung, sodass der Rollback einer Übergabe ein Zurückschalten auf den alten Key bleibt.
Entscheidungen Ihrer Architekten
Rollen je Service Account
Die Entwürfe leiten nie eine STACKIT-Rolle aus einer Cloud-Aktion ab. Eine Person wählt, und der Geltungsbereich der Berechtigung ist das Projekt, sofern ein Dienst keine feineren Bindungen bietet.
Key oder Föderation
Ein Service-Account-Key ist ein Credential, und STACKIT warnt, dass ein abgeflossener privater Schlüssel alles offenlegt, was der Account erreichen kann. Föderation liefert kurzlebige Token ohne statische Keys, braucht aber einen OIDC-Issuer.
Projektaufbau
STACKIT kennt keine Resource Group. Wo Azure Rollen über eine Gruppe vererbte, entscheiden Sie, wie die Grenzen auf Projekte, Ordner und Rollen abgebildet werden.
Token-Flow
STACKIT nennt den 16. Dezember 2025 als Abkündigungsdatum für Service-Account-Access-Token und bietet eine Anleitung für den Wechsel vom Token-Flow zum Key-Flow. Bauen Sie neue Automatisierung auf Keys oder Föderation auf.
Fragen von Sicherheitsteams
Lassen sich meine IAM-Richtlinien in STACKIT importieren?
Nein. Die Entwürfe schreiben Rollenzuweisungen mit den Rollen als Variable, weil sich eine AWS-Aktion nicht eins zu eins auf eine STACKIT-Rolle abbilden lässt. Die Quellrichtlinie steht in der Beschreibung der Variable, und eine Person übersetzt sie.
Gibt es für ein EC2 Instance Profile ein Gegenstück auf STACKIT?
Der Server handelt als angehängter Service Account. Der Entwurf vermerkt, dass ein Metadata-Token-Pfad in seinen Tests vom 8. und 9. Oktober 2026 ein Token lieferte, ein Credentials-Pfad im EC2-Stil dagegen HTTP 500. Code, der Credentials von einem Instanz-Metadatenendpunkt liest, ändert sich daher.
Kann ich die Rollenzuweisungen so anwenden, wie sie geschrieben sind?
Sie sind mit einem Opt-in-Feature des STACKIT-Terraform-Providers geschrieben, das der Entwurf in seinem Provider-Block aktiviert und das der Provider als wahrscheinlich veränderlich dokumentiert. Prüfen Sie sie und setzen Sie die Rollen, bevor Sie anwenden.
Was geschieht mit dem AWS Access Key?
Er funktioniert weiter, bis Sie ihn stilllegen. Der Plan legt die Stilllegung hinter die GO-Entscheidung; bis dahin können Sie Aufrufer zurückschalten.
Quellen
Ihr nächster Schritt: STACKIT.
Erzählen Sie uns von Ihrer Umgebung. Wir zeigen Ihnen, was StackToIT dafür liefert: Zielarchitektur, Terraform-Artefakte und einen strukturierten Migrationsplan.