Wenn Sie Zugangsdaten in ein AMI einbetten, reisen diese mit jeder Kopie des Images mit, bleiben in den Snapshots eingebrannt und können in Konten oder Regionen landen, an die Sie nie gedacht hätten. Es genügt, dass jemand mit Lesezugriff auf das Image sie extrahiert. Und da Images versioniert aufbewahrt werden, kann das Secret lange überleben, nachdem Sie es rotiert zu haben glaubten.
Die goldene Regel: Das Image definiert die Maschine; Secrets werden zur Laufzeit geliefert.
Wo Secrets leben sollten
| Dienst | Cloud oder Umgebung | Ideal für |
|---|---|---|
| AWS Secrets Manager | AWS | Rotierbare Zugangsdaten, native Integration |
| AWS SSM Parameter Store | AWS | Einfache Parameter und Secrets, geringe Kosten |
| HashiCorp Vault | Multicloud | Dynamische Secrets und feine Steuerung |
| Azure Key Vault / Google Secret Manager | Azure / GCP | Native Entsprechungen je Cloud |
Bewahren Sie Secrets in einem dedizierten Manager auf, nie im Image oder im Klartext in user-data.
Das richtige Muster: Identität statt Passwörter
Am sichersten greift eine Instanz auf Ressourcen zu, wenn man ihr kein Passwort gibt, sondern eine Identität. In AWS erlaubt eine an die Instanz gebundene IAM-Rolle, temporäre und automatisch rotierte Zugangsdaten zu erhalten, ohne dass ein Schlüssel im Image mitreist.
- IAM-Rollen für Instanzen: Die Instanz nimmt eine Rolle an und erhält temporäre Zugangsdaten.
- IRSA in Kubernetes: Identität je Pod, ohne geteilte Schlüssel auf dem Knoten.
- Dynamische Secrets mit Vault: kurzlebige Zugangsdaten auf Anforderung erzeugt.
- Injektion zur Laufzeit: Die Anwendung liest das Secret beim Start aus dem Manager, nicht aus einer eingebackenen Datei.
Schützen Sie die Metadaten: IMDSv2
Die temporären Zugangsdaten der Rolle werden über den Metadatendienst der Instanz bezogen. Wer eine SSRF-Lücke ausnutzt, könnte versuchen, sie zu stehlen. IMDSv2 verlangt ein Sitzungstoken und entschärft diese Angriffsklasse: Machen Sie es bei Ihren Starts verpflichtend.
Hygiene: keine Spuren im Image hinterlassen
- Löschen Sie vor dem Versiegeln des AMI Shell-Historien, Logs mit Zugangsdaten, temporäre SSH-Schlüssel und Konfigurationsdateien mit Secrets.
- Scannen Sie das Image auf Secrets mit Werkzeugen wie gitleaks oder trufflehog, an Dateisysteme angepasst.
- Lassen Sie keine überzähligen autorisierten Schlüssel in
~/.ssh/authorized_keys. - Vermeiden Sie öffentliche AMIs mit Secrets: Wenn Sie veröffentlichen, prüfen Sie, dass nichts durchsickert.
Kurze Checkliste
- Null eingebackene Secrets im Image.
- Secrets-Manager mit Rollen oder föderierter Identität.
- IMDSv2 verpflichtend.
- Secret-Scan in der Pipeline.
- Spurenbereinigung vor dem Versiegeln.
Häufig gestellte Fragen
Und wenn meine Anwendung das Secret beim Start braucht?
Dann soll sie es zur Laufzeit über die Instanzidentität aus dem Secrets-Manager lesen. So reist das Secret nie im Image mit und lässt sich ohne Neubau rotieren.
Ist es sicher, Secrets über user-data zu übergeben?
Nicht im Klartext: user-data ist über die Metadaten lesbar. Nutzen Sie es höchstens, um anzugeben, welches Secret aus dem Manager zu ziehen ist – und schützen Sie die Metadaten mit IMDSv2.
Wie erkenne ich, ob ein Image bereits eingebackene Secrets hat?
Indem Sie es mit Secret-Erkennungswerkzeugen über sein Dateisystem scannen und vor dem Einsatz Konfigurationsdateien, Historien und autorisierte Schlüssel prüfen.
Bei imaxe.cloud bauen wir Images ohne Zugangsdaten, ausgelegt auf die Integration mit Secrets-Managern und föderierter Identität.
