Thema: cloud
-
Cloud-Instance-Metadata-Endpunkte: warum IMDSv2-Token und ein Hop-Limit von 1 SSRF entschärfen
Cloud-VMs stellen einen link-lokalen Metadata-Dienst bereit, der temporäre Zugangsdaten für die Rolle der Instanz liefern kann. Eine Server-Side-Request-Forgery-Schwachstelle oder das Fetch-Werkzeug eines Agenten kann ihn erreichen. Bei AWS beseitigt das Erzwingen von IMDSv2-Sitzungstoken und ein auf 1 belassenes Hop-Limit der PUT-Antwort die einfachsten Zugriffswege.
-
Kostenzuordnungs-Tags: ein Tagging-Standard, der den Abrechnungs-Export übersteht
Cloud-Rechnungen lassen sich nur nach Tags gruppieren, die auf der Ressource existieren, für die Abrechnung aktiviert und einheitlich geschrieben sind; einen kurzen Pflicht-Schlüsselsatz definieren, ihn bei der Erstellung per Policy erzwingen, über Infrastructure-Code anwenden und ungetaggte Ausgaben jeden Monat abgleichen.
-
Provisioning-Agents für den ersten Windows-Start in der Cloud: EC2Launch v2, Azure VM Agent und cloudbase-init
AWS, Azure und die meisten anderen Clouds betreiben in Windows-Images einen kleinen Agenten, der beim ersten Start User Data bzw. Custom Data verarbeitet. Gängig sind EC2Launch v2, die Provisioning- und Windows-VM-Agents von Azure (sie legen Custom Data in CustomData.bin ab, führen es aber nicht aus) sowie das Open-Source-Tool cloudbase-init. Jeder protokolliert an einem anderen Ort, den man prüfen sollte, wenn die Provisionierung scheinbar stillschweigend gescheitert ist.
-
Terraform State: was er speichert, weshalb er gesperrt wird und wie sich Drift zeigt
State bildet Ressourcenadressen in der Konfiguration auf reale Objekte ab und speichert Attributwerte, einschliesslich Geheimnissen, in einfachem JSON; ein Remote-Backend mit Sperrung verhindert, dass gleichzeitige Schreibvorgänge ihn beschädigen, und Drift (ausserhalb von Terraform vorgenommene Änderungen) zeigt sich als unerwartete Abweichungen in einem Plan oder in einem Refresh-only-Lauf.
Maschinenlesbar: JSON