AWS IAM → STACKIT
AWS IAM zu STACKIT migrieren
AWS-IAM-Rollen werden zu STACKIT-Service-Accounts mit Rollenzuweisungen im Projekt. StackToIT unterscheidet die Rollen, die Ihre Anwendungen nutzen, von Rollen, die nur AWS-Dienste brauchen. So übernehmen Sie Identitäten, nicht AWS-Verdrahtung.
ECS-Task-Rollen zu STACKIT-Service-Accounts
Aus dem veröffentlichten Lauf der AWS Retail Store Sample App. Links die AWS-Quelle genau so, wie AWS sie veröffentlicht, rechts die Ressourcenblöcke, die StackToIT geschrieben hat; die Prüfkommentare über jedem Block in der Datei sind hier ausgelassen.
resource "aws_iam_role" "task_execution_role" {
name = "${var.environment_name}-${var.service_name}-te"
assume_role_policy = data.aws_iam_policy_document.assume_role_policy.json
tags = var.tags
}
resource "aws_iam_role_policy_attachment" "task_execution_role_policy" {
role = aws_iam_role.task_execution_role.name
policy_arn = "arn:aws:iam::aws:policy/service-role/AmazonECSTaskExecutionRolePolicy"
}
resource "aws_iam_role_policy_attachment" "task_execution_role_additional" {
count = length(var.additional_task_execution_role_iam_policy_arns)
role = aws_iam_role.task_execution_role.name
policy_arn = var.additional_task_execution_role_iam_policy_arns[count.index]
}
resource "aws_iam_role" "task_role" {
name = "${var.environment_name}-${var.service_name}-task"
assume_role_policy = data.aws_iam_policy_document.assume_role_policy.json
tags = var.tags
}resource "stackit_service_account" "retail_app_ecs_carts_service_task_execution_role" {
project_id = var.project_id
name = "retail-app-ec-e66809"
}
resource "stackit_authorization_project_role_assignment" "retail_app_ecs_carts_service_task_execution_role" {
for_each = toset(var.carts_task_execution_project_roles)
resource_id = var.project_id
role = each.value
subject = stackit_service_account.retail_app_ecs_carts_service_task_execution_role.email
}Rollen werden zu Service Accounts
Jede Task- und Execution-Rolle wird zu einem STACKIT-Service-Account, benannt innerhalb der STACKIT-Grenze von 20 Zeichen.
Berechtigungen werden zu Rollenzuweisungen
AWS-Aktionen lassen sich nicht eins zu eins auf STACKIT-Rollen abbilden. Die Rollen sind daher je Service Account eine Variable, die Ihr Architekt füllt.
Dienstrollen entfallen
Rollen, die nur ein AWS-verwalteter Dienst nutzt, etwa die EKS-Control-Plane, werden auf STACKIT als nicht nötig benannt.
Trust Policies benannt
Ein STACKIT-Service-Account hat keine Trust Policy. Der Code sagt das, und Verweise auf Rollen-ARNs werden zur Anpassung aufgelistet.
Was der Lauf zum Retail Store erzeugt hat
Identität ist mehr als Rollen. Das sind die Fakten des veröffentlichten Laufs zum AWS Retail Store.
Zehn Rollen, zehn Service Accounts
Fünf Services (ui, catalog, carts, checkout, orders) haben jeweils eine Task-Rolle und eine Execution-Rolle. Jede wird zu einem stackit_service_account.
Eine Variable je Account
Jeder Service Account erhält eine Rollenzuweisung, die über eine Variable gesteuert wird, etwa carts_service_task_project_roles oder carts_task_execution_project_roles. Der Lauf hat zehn davon geschrieben, damit Ihr Architekt sie füllt.
Namen innerhalb der Grenze
Ein Service-Account-Name hat höchstens 20 Zeichen aus Kleinbuchstaben, Ziffern und einzelnen Bindestrichen und ist im Projekt eindeutig. Der Entwurf kürzt den Namen und hängt ein Suffix aus dem SHA-256 der Quelladresse an, zum Beispiel retail-app-ec-e66809. Setzen Sie den Namen, den Sie bevorzugen.
Verknüpfung bleibt eine Entscheidung
Bei allen fünf ECS-Services ist die Verknüpfung der Identität als Entscheidung markiert. Der Identity Architect verantwortet das Arbeitspaket „Set up the identities and access“ mit zehn Schritten.
Abgeschaltete Rollen sind trotzdem eingeordnet
In der Retail-Umgebung sind die beiden RDS-Enhanced-Monitoring-Rollen und die VPC-Flow-Log-Rolle mit count = 0 abgeschaltet. Der Lauf hält dennoch fest, wie er sie behandeln würde: Eine Monitoring-Rolle, die eine Datenbankinstanz nutzt, gilt als Rolle eines AWS-verwalteten Dienstes; eine Rolle, deren Zweck erst zur Planzeit bekannte Werte bestimmen, geht an Ihren Architekten.
Secrets daneben
Vier Secrets-Manager-Secrets werden auf STACKIT Secrets Manager abgebildet. Ein Skript schreibt sie über dessen Vault-kompatible API, sobald Sie die Entscheidung zur Nutzung dieser API annehmen.
Bewiesen an einer echten AWS-Umgebung
Die AWS Retail Store Sample App, ein öffentliches Terraform-Projekt von AWS, von StackToIT bewertet und vollständig veröffentlicht, genau so, wie der Lauf es geschrieben hat.
Fallstudie ansehen (Englisch)- 282
- Terraform-Ressourcendefinitionen analysiert
- 44
- Migrationseinheiten identifiziert
- 38
- Zieleinheiten erzeugt, von 52 betrachteten
- 331
- Planschritte erstellt
Fragen aus Security-Teams
Übersetzt StackToIT IAM-Policies in STACKIT-Rollen?
StackToIT ordnet jede Rolle mit ihren Policies einem Service Account mit Rollenzuweisungen zu und überlässt die Wahl der STACKIT-Rollen Ihrem Architekten, denn AWS-Aktionen und STACKIT-Rollen decken sich nicht eins zu eins.
Ist die STACKIT-Ressource für Rollenzuweisungen stabil?
stackit_authorization_project_role_assignment gehört zum Feature „iam“ des STACKIT-Providers, einem optional zu aktivierenden Feature, das sich laut Provider noch ändern kann. StackToIT aktiviert es ausdrücklich und sagt das im Code.
Was ist mit Berechtigungen auf einzelne Ressourcen?
Eine Rollenzuweisung im Projekt gilt für das ganze Projekt. Wo eine Quell-Policy Berechtigungen auf bestimmte Ressourcen begrenzt, weist StackToIT darauf hin, damit Sie Bindungen je Ressource nutzen können, wo der STACKIT-Dienst sie anbietet.
Entscheidet StackToIT, wie sich ein Workload authentifiziert?
Es benennt die Frage. Der Lauf führt je Service auf, wie der Workload seinen Service Account erhält, als Entscheidung für den Identity Architect. Ob Workload Identity Federation passt, Unterschiede bei den Berechtigungen, Break-Glass-Zugänge und menschliche Identitäten bleiben bei Ihren Architekten; der Lauf verknüpft nichts, vergibt nichts und föderiert nichts.
Warum sehen die erzeugten Service-Account-Namen gekürzt aus?
STACKIT begrenzt den Namen eines Service Accounts auf 20 Zeichen; ein langer AWS-Rollenname lässt sich daher nicht unverändert übernehmen. Der Entwurf kürzt ihn und ergänzt ein Hash-Suffix, damit zwei Rollen nie kollidieren. Sie können jeden gültigen Namen setzen.
Wie viele Rollenvariablen braucht eine Umgebung?
Eine je Service Account. Die Retail-Store-Umgebung hat zehn Rollen, und der Lauf schrieb zehn Variablen; jede füllt Ihr Architekt mit den STACKIT-Rollen, die der jeweilige Service Account braucht.
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.