IAM Policy Autopilot analysiert jetzt Terraform-Pläne vor dem Deploy

Terraform-Pläne werden zur Berechtigungsgrundlage

AWS hat IAM Policy Autopilot um eine Terraform-Anbindung erweitert, die aus einem Plan-File künftige Berechtigungen ableitet, bevor ein einziger Ressourcen-Call bei AWS ankommt. Im offiziellen Announcement beschreibt AWS das Feature schlicht: Sie füttern das Tool mit einer terraform plan-Ausgabe, es liest die geplanten Ressourcen und schreibt eine passende IAM-Policy heraus, bevor Sie apply drücken. Das klingt nach einem kleinen Detail, verschiebt aber den Zeitpunkt der Rechteanalyse um eine ganze Projektphase nach vorne.

Der Hintergrund: IAM Policy Autopilot ist ein Open-Source-Tool, das AWS auf der re:Invent 2025 vorgestellt hat. Es analysiert deterministisch Anwendungscode und leitet daraus eng geschnittene IAM-Policies ab, die Entwicklerinnen und Entwickler anschließend verfeinern – mit dem erklärten Ziel, weniger Zeit mit Policy-Schreiben und Access-Debugging zu verbrennen. Wer das Tool schon für Lambda-Funktionen oder SDK-Aufrufe genutzt hat, kennt das Prinzip: kein Rätselraten mehr, welche Actions eine Rolle wirklich braucht, sondern ein aus dem Code abgeleiteter Vorschlag.

Bisher endete diese Analyse aber an der Infrastrukturgrenze. Der Autopilot las Anwendungscode, konnte aber keine Policies für Ressourcen ableiten, die per Infrastructure as Code deployt werden – ein Terraform-Modul mit fünfzehn S3-Buckets, drei DynamoDB-Tabellen und zwei Lambda-Functions blieb für das Tool unsichtbar, solange es nicht als SDK-Aufruf im Anwendungscode auftauchte. Genau diese Lücke schließt die neue Terraform-Unterstützung.

Das trifft einen wunden Punkt vieler Teams: Die IAM-Rolle für die eigentliche Deploy-Pipeline – also die Rolle, mit der Terraform selbst Ressourcen anlegt – wird in der Praxis oft großzügiger geschnitten als jede Anwendungsrolle, weil niemand Lust hat, bei jedem neuen Ressourcentyp im Modul die Pipeline-Rechte nachzuziehen. Genau für diesen wiederkehrenden Reibungspunkt ist die neue Fähigkeit gedacht.

Autopilot leitet erwartete AWS-Aktionen ab

Der Mechanismus ist unspektakulär und genau deshalb interessant: Sie übergeben eine Plan-Datei, und Autopilot wendet eine deterministische Analyse an, die daraus eine Policy ableitet, die auf die CRUD-Funktionen der im Plan enthaltenen Ressourcen zugeschnitten ist. Es gibt also keinen Modell-Rateprozess und kein Wahrscheinlichkeits-Scoring – jede Ressource im Plan wird auf ihre erwarteten Create-, Read-, Update- und Delete-Operationen abgebildet, und daraus entsteht eine Liste konkreter IAM-Actions.

Praktisch heißt das: Sie können den Schritt in eine CI-Pipeline hängen, kurz nach terraform plan und vor jedem apply. Wer environment-übergreifend mit mehreren State-Files arbeitet, wird trotzdem zweimal hinschauen müssen – ein Plan pro Workspace bedeutet auch eine Policy-Ableitung pro Workspace, und wer das ignoriert, bekommt am Ende eine Sammlung leicht widersprüchlicher Berechtigungssätze statt einer einzigen Wahrheit.

Für Teams, die ihre Deploy-Pipelines ohnehin schon mit KI-Assistenz absichern, schließt sich hier ein Kreis: Wo sich GitHub Copilot Extensions direkt in bestehende Entwicklerworkflows einklinken, wächst der Bedarf nach einer vergleichbar automatisierten Kontrolle auf der Infrastrukturseite – und genau das liefert die Terraform-Anbindung von Autopilot.

Dieses Bild wurde komplett mit KI generiertProviderhiggsfieldModellseedream_v4_5; quality=high; 5120x2880PromptA developer hand compares a wide bundle of copper access keys with a smaller fitted set beside an unbuilt modular infrastructure model. A tight documentary composition emphasizes hands-on consequences in a fully text-free scene with blank surfaces and no legible markings. Photorealistic style image. Mood: practical, focused, and investigative. Avoid: watermark, signature, blurry, low quality, distorted, deformed, readable text, labels, numbers, captions, UI, dashboards, screens.

Least Privilege beginnt vor dem Apply

Der Least-Privilege-Anspruch zeigt sich am deutlichsten in einem Detail: Wo möglich, referenzieren die generierten Policies konkrete Resource-ARNs statt Wildcards. Statt einer Policy, die Zugriff über s3:* auf arn:aws:s3:::* erlaubt, bekommen Sie exakt die Buckets und Tabellen, die im Plan tatsächlich auftauchen – mit ihrem im Plan berechneten Namen.

Das ist im Alltag angenehmer, als es sich anhört, hat aber einen Haken, den man kennen sollte: Terraform berechnet manche Ressourcennamen erst zur Apply-Zeit, etwa wenn Suffixe aus count oder for_each entstehen oder wenn ein Name von einem Data-Source-Lookup abhängt, der erst beim Apply aufgelöst wird. In solchen Fällen bleibt dem Autopilot nur eine best-effort-Ableitung, und die Policy landet dann doch näher an einem eingegrenzten Wildcard-Muster als an einem exakten ARN. Wer das nicht prüft, wundert sich später, warum eine vermeintlich enge Policy trotzdem einen ganzen Namensraum abdeckt.

Für die Bewertung zählt trotzdem der Normalfall, nicht der Sonderfall: Bei statisch benannten Ressourcen – und das ist in den meisten Terraform-Modulen die Mehrheit – liefert die ARN-Bindung tatsächlich engere Rechte, als sie viele Teams von Hand je geschrieben hätten.

Wer schon einmal versucht hat, für ein großes Modul händisch eine minimalinvasive Policy zu schreiben, kennt die Versuchung: Nach der dritten fehlgeschlagenen Deploy-Aktion wegen einer fehlenden Action landet man doch wieder bei einem Wildcard, weil die Deadline näher rückt als die Geduld. Ein Ableitungsschritt, der von Anfang an die exakten ARNs liefert, nimmt genau diesen Anreiz zur faulen Lösung weg.

Plan und Laufzeit bleiben zwei verschiedene Zustände

Ein Punkt, der in der Ankündigung leicht untergeht: IAM Policy Autopilot ist kostenlos nutzbar und läuft auf der eigenen Maschine – es gibt keinen AWS-Service, an den Sie Ihre Terraform-Pläne zur Analyse schicken, sondern ein CLI-Tool, das lokal rechnet. Für Firmen mit strengen Compliance-Vorgaben gegen das Verschicken von Infrastrukturdefinitionen an Drittsysteme ist das ein relevanter Unterschied zu cloud-basierten Policy-Generatoren.

Wichtig ist dabei die Unterscheidung zwischen Plan und Laufzeit: Die neue Fähigkeit ergänzt die bereits vorhandene Terraform-bewusste Analyse, die Terraform-Ressourcendefinitionen mit SDK-Aufrufen im Anwendungscode abgleicht, um Berechtigungen aufzulösen. Autopilot kombiniert damit zwei Blickwinkel – was der Code zur Laufzeit tatsächlich aufruft, und was die Infrastruktur laut Plan überhaupt erst bereitstellt. Laut AWS war genau diese Erweiterung um Terraform-Plan-Dateien die meistgewünschte Fähigkeit seit dem Launch des Tools.

Was die Analyse nicht ersetzt, ist eine Prüfung nach dem Apply. Ein Plan zeigt die erwartete Änderung, keine Garantie für das tatsächliche Ergebnis – Race Conditions, manuell nachgezogene Änderungen in der Konsole oder ein State, der nicht mehr zur Realität passt, tauchen im Plan nicht auf und damit auch nicht in der abgeleiteten Policy.

Automatische Richtlinien brauchen einen Gegencheck

Zusammengefasst liefert AWS mit diesem Release die Fähigkeit, Basis-IAM-Policies direkt aus einer Terraform-Plan-Datei zu erzeugen. Das ist der Kernsatz der Ankündigung, und er ist bewusst vorsichtig formuliert: Baseline-Policy, nicht fertige Produktions-Policy. Die generierte Richtlinie ist ein Startpunkt für Ihre eigene Review, kein Freibrief zum ungeprüften Deploy.

Wer schon einmal eine automatisch generierte IAM-Policy in ein Security-Review gegeben hat, weiß, wie schnell aus ‚die Maschine hat das schon geprüft‘ ein blinder Fleck wird. Ein deterministischer Ableitungsprozess ist zwar nachvollziehbar – anders als ein KI-Vorschlag lässt sich hier tatsächlich zurückverfolgen, warum welche Action in der Policy steht – aber nachvollziehbar heißt nicht automatisch korrekt für Ihren speziellen Compliance-Rahmen. Wenn Ihr Regelwerk zusätzliche Bedingungen wie IP-Restriktionen, MFA-Zwang oder Tag-basierte Zugriffskontrollen verlangt, muss das jemand händisch ergänzen; der Autopilot leitet solche Zusatzbedingungen nicht aus einem Terraform-Plan ab, weil sie dort schlicht nicht stehen.

Der Trend zu automatisch abgeleiteten Sicherheitsentscheidungen zieht sich derzeit durch mehrere Ecken der Branche – etwa dort, wo Microsofts Defender-Agenten Reaktionen auf Sicherheitsvorfälle automatisieren. Der gemeinsame Nenner ist überall derselbe: Automatisierung verschiebt Aufwand, sie verschwindet nicht. Am Ende bleibt ein Mensch verantwortlich, der die Ausgabe versteht, bevor sie live geht.

Ein zusätzlicher Punkt für die Review-Checkliste: Wenn eine Policy plötzlich deutlich schmaler ausfällt als die bisherige, lohnt sich nicht nur Freude, sondern auch die Frage, ob eine Ressource im Plan schlicht fehlt – etwa weil ein Modul konditional übersprungen wird oder ein count auf null steht. Eine zu enge Policy ist in der Produktion mindestens so ärgerlich wie eine zu weite, nur fällt der Fehler meist erst beim ersten fehlgeschlagenen Deploy auf.

Ein Testpfad für Infrastruktur-Repositories

Wer das ausprobieren will, findet den Einstieg im GitHub-Repository von IAM Policy Autopilot – dort liegen Quellcode und Installationsanleitung für die CLI. Der pragmatische Testpfad sieht in etwa so aus: einen bestehenden Terraform-Workspace nehmen, terraform plan -out ausführen, das Plan-File durch den Autopilot schicken und die generierte Policy neben die aktuell verwendete IAM-Rolle legen.

Interessant wird der Diff selbst: Fehlen in der bestehenden Rolle Actions, die der Plan eigentlich braucht, war die alte Policy vermutlich zu grob geschnitten und hat über Wildcards kompensiert. Enthält die generierte Policy Actions, die die bestehende Rolle nicht hat, lohnt sich die Frage, ob diese Ressourcen überhaupt schon produktiv laufen oder ob der Plan gerade erst neue Ressourcen einführt. Beide Fälle sind normal, keiner davon ist ein Bug im Tool.

Für Repositories mit vielen Modulen und verschachtelten Terraform-Aufrufen lohnt sich außerdem ein zweiter Blick auf Module, die selbst wieder andere Module ziehen: Die Plan-Ausgabe listet am Ende zwar alle Ressourcen flach auf, aber wer die generierte Policy versteht, sollte auch nachvollziehen können, aus welchem Modul welche Ressource stammt – sonst wird die spätere Pflege der Rolle zur Ratearbeit.

Rollout-Reihenfolge für Teams mit IaC-Pipelines

Für den Rollout in einer bestehenden Pipeline bietet sich eine schrittweise Reihenfolge an: zunächst den Autopilot parallel neben der bestehenden Rechteverwaltung laufen lassen und nur die Diffs sammeln, ohne automatisch etwas zu ändern. Erst wenn genug Diffs manuell bestätigt sind, folgt der nächste Schritt – ein CI-Gate, das bei signifikanten Abweichungen zwischen bestehender Rolle und abgeleiteter Policy einen Reviewer hinzuzieht, statt automatisch zu mergen.

Was der Autopilot laut Ankündigung nicht abdeckt, ist die andere Seite von Berechtigungen: Resource-based Policies, Cross-Account-Zugriffe oder Service-Control-Policies auf Organisationsebene bleiben außen vor, weil sie nicht aus einem einzelnen Terraform-Plan-File ableitbar sind. Wer in einer Multi-Account-Landschaft mit Assume-Role-Ketten arbeitet, bekommt also einen guten Ausgangspunkt für die Identity-based Policy der Rolle selbst, aber keine vollständige Berechtigungslandkarte.

Ein letzter praktischer Hinweis für den Einstieg: Fangen Sie nicht mit dem größten, verschachteltsten Repository an, sondern mit einem kleineren, gut verstandenen Workspace. Dort lässt sich am schnellsten prüfen, ob die abgeleitete Policy plausibel ist, bevor man das Verfahren auf komplexere Module mit dynamischen Namen und bedingten Ressourcen ausweitet.

Damit bleibt die Kernaussage der Ankündigung angemessen bescheiden: ein zusätzlicher, deterministischer Analyseschritt vor dem Apply, der weniger Wildcard-Policies produziert – kein Ersatz für Reviews, aber ein Werkzeug, das den Ausgangspunkt jeder neuen IAM-Rolle enger macht, bevor überhaupt eine Ressource in AWS existiert.