Unsicherer generierter IaC-Code

Was ist Unsicherer generierter IaC-Code?

Ein KI-Assistent kann Infrastrukturcode schreiben, der gültig und lesbar ist und sich ohne Fehler anwenden lässt, und trotzdem Speicher für das Internet offen lassen. Hier gelangt ein generiertes Bucket-Modul durch eine Pipeline, die nur prüft, ob es sich anwenden lässt. Sie lesen, was das HCL tatsächlich erlaubt, bauen ein Policy-as-Code-Gate in die Plan-Phase ein, sehen zu, wie es das ausgelieferte Modul durchfallen lässt, korrigieren den Code und bestätigen, dass eine anonyme Anfrage jetzt abgelehnt wird.

Was Sie lernen in Unsicherer generierter IaC-Code

• Erklären, warum ein fehlerfreier Terraform-Plan nichts darüber aussagt, ob eine Änderung sicher ist
• Generiertes HCL daraufhin lesen, was es gewährt: öffentliche ACLs, Verschlüsselung und Aktionen in Richtlinien
• Die Plan-Phase um eine Policy-as-Code-Prüfung ergänzen, damit eine fehlgeschlagene Regel das Apply stoppt
• Zeigen, dass das Gate das unsichere Modul durchfallen und das korrigierte bestehen lässt
• Von außen bestätigen, dass eine anonyme Anfrage an den Bucket abgelehnt wird

Unsicherer generierter IaC-Code — Trainingsschritte

1. Ein Bucket für Kunden-Uploads

   Ines, die Leiterin des Plattformteams, hat in Jotvane, dem Tracker des Teams, ein Issue angelegt: Für die Dateien, die Kunden im Portal hochladen, braucht sie Speicher, und zwar als Terraform-Code, damit die Pipeline ihn ausrollen kann.

2. Das Repository öffnen

   Im Editor öffnet sich das Infrastruktur-Repository: eine leere Moduldatei für den Bucket und der terraform-Workflow, der für jeden Pull Request einen Plan erstellt und ihn beim Merge anwendet.

3. Das Modul anfordern

   Öffnen Sie Claude und bitten Sie um das Bucket-Modul, so wie Ines es beschrieben hat.

4. Fünf Ressourcen, sauber geschrieben

   Claude liest das leere Modul und den Workflow und schlägt dann fünf Ressourcen vor: den Bucket, seine Einstellungen für Eigentümerschaft und öffentlichen Zugriff, eine ACL und eine Richtlinie für den Upload-Dienst. Das HCL ist sauber und idiomatisch, und laut Antwort läuft der Plan fehlerfrei durch.

5. Das Modul annehmen

   Wenn Sie den Diff annehmen, landet Claudes Modul in main.tf . Die Randleiste markiert jede Zeile violett als ungeprüft: vom Assistenten geschrieben, noch von niemandem gelesen.

6. Das Modul initialisieren

   Bevor der Pull Request erstellt wird, führen Sie denselben ersten Schritt aus wie der Workflow: Initialisieren Sie das Modul, damit Terraform über Provider und State-Backend verfügt.

7. Der Plan läuft fehlerfrei durch

   Jetzt der Plan, also die Prüfung, die der Workflow bei jedem Pull Request ausführt. Hält der Plan, was Claude versprochen hat, zeigt er fünf hinzuzufügende Ressourcen und keine Fehler. Dann wird der Pull Request grün, Ines gibt ihn frei, und mit dem Merge wird das Modul angewendet.

8. Ein Bucket, der Fremden antwortet

   Weit weg von Rushmarle schlägt ein Scanner, der das Internet nach Speicher mit anonymem Zugriff durchkämmt, beim neuen Bucket an. Der Bucket lässt sich ohne Schlüssel auflisten, und jedes Objekt darin liegt zum Mitnehmen bereit. Ein einziger rekursiver Kopierbefehl ohne Zugangsdaten, und der gesamte Inhalt landet auf einer Festplatte, die nicht Rushmarle gehört.

9. Kundendateien, anonym heruntergeladen

   Marit aus dem Sicherheitsteam hat ein Issue angelegt. Den vom Modul erstellten Bucket hat in der Nacht jemand ganz ohne Zugangsdaten von Rushmarle aufgelistet und heruntergeladen.

10. Ein Gate in die Plan-Phase einbauen

    Der Workflow prüft, ob Terraform den Code anwenden kann, und sonst nichts. Ergänzen Sie den Plan-Job um einen Policy-as-Code-Schritt: checkov scannt das Modul, bevor der Plan läuft, und ein fehlgeschlagener Check lässt den Job scheitern, sodass das Apply gar nicht erst startet.