Montag, 6:00 Uhr. TruffleHog-Alert: AWS Access Key in öffentlichem Repo-Commit-History entdeckt. Developer hat versehentlich vor einer Woche Datei mit Credentials committet, dann gelöscht - aber Git-History erinnert sich. Jetzt ist dieser Key in GitGuardians Public-Leaks-Datenbank. AWS Cost Explorer zeigt unbekannte EC2-Instanzen - Crypto Mining. Account kompromittiert.
GitGuardian-Forschung zeigt, dass 2024 über 12 Millionen Secrets in öffentlichen GitHub-Repositories entdeckt wurden. API-Keys, Datenbank-Passwörter, Private Keys, Tokens. Jedes ist potenzieller Angriffsvektor. Und das sind nur öffentliche Repos - in privaten gibt es mehr.
CI/CD-Pipeline ist besonders riskant: Build-Server haben Zugang zu allem (Code, Secrets, Produktion). Eine kompromittierte CI = voller Infrastrukturzugang. Secrets Management in der Pipeline ist kein “Nice to Have” - es ist Sicherheitsfundament.
Warum sind Secrets in CI/CD so problematisch?
CI/CD braucht Secrets um zu funktionieren. Deploy auf AWS erfordert Credentials. Push zu Registry erfordert Token. Test auf Staging-Datenbank erfordert Passwort. Secrets müssen für Pipeline verfügbar sein - Frage ist, wie man sie sicher liefert.
Viele Stellen für Fehler. Secrets können leaken durch: Code-Commits, Log-Output, Environment Variables in UI, Docker-Images, Artifact-Repositories, Shared Runners. Jede Pipeline-Stufe ist potenzielles Leck.
Persistenz von Leaks. Secret in Git-History ist dort “für immer” (ohne History-Rewrite). Secret in Docker-Image-Layer ist dort, selbst nach “Löschung” im nächsten Layer. Secret in Logs kann jahrelang archiviert sein.
Ausufernde Berechtigungen. Pipeline hat oft mehr Berechtigungen als nötig (“weil es einfacher war”). Root-Zugang zu Produktion, Admin auf Cloud-Account. Kompromittierte CI = voller Blast Radius.
Geteilte Umgebungen. Self-hosted Runners zwischen Projekten geteilt. Eine Vulnerability in einem Projekt = potenzieller Zugang zu Secrets anderer Projekte.
Developer-Convenience vs. Security. Secrets hardzucodieren ist “schneller” als ordentliches Secrets Management. Entwickler unter Zeitdruck wählen Convenience.
Was sind die häufigsten Secrets-Management-Fehler?
Secrets im Code-Repository. Offensichtlichster und häufigster Fehler. .env-Datei im Repo. Config-Datei mit Klartext-Passwort. SQL-Script mit Credentials.
Secrets in Docker-Images. COPY .env /app/ oder ENV DATABASE_PASSWORD=secret im Dockerfile. Image wird zu Registry gepusht, Secrets sind extrahierbar.
Secrets in CI-Logs. echo $SECRET_TOKEN zum Debugging. Passwort erscheint in Stack Trace. Verbose-Mode loggt alles.
Environment Variables in CI-UI. Manche CI/CD-Plattformen erlauben Setzen von Env-Vars, die für jeden mit Projektzugang sichtbar sind. “Secret” das kein Secret ist.
Hardcodierte Secrets in Tests. “Es ist nur ein Test, wir nehmen echten API-Key.” Test wird committet, Key geleakt.
Geteilte Secrets über Umgebungen. Ein API-Key für Dev, Staging und Produktion. Dev kompromittiert Key = Produktion gefährdet.
Keine Rotation. Secret vor 3 Jahren gesetzt, nie rotiert. Wenn es geleakt ist - ist es immer noch gültig.
Wie übergibt man Secrets korrekt an CI/CD-Pipeline?
CI/CD-native Secrets (GitHub Secrets, GitLab CI Variables, etc.). Secrets in CI/CD-Plattform gespeichert, at rest verschlüsselt, als Env-Variables während Build injiziert. Basis-Level-Security, geeignet für weniger kritische Secrets.
Externer Secrets Manager (HashiCorp Vault, AWS Secrets Manager, Azure Key Vault, GCP Secret Manager). Secrets außerhalb von CI/CD gespeichert, Pipeline ruft sie zur Laufzeit ab. Bessere Security, zentralisiertes Management, Audit Trail.
Just-in-time Credentials. Statt statischer Secrets - kurzlebige, dynamisch generierte Credentials. Vault Dynamic Secrets: Pipeline fordert Credentials an, Vault generiert temporäre, Credentials verfallen nach Nutzung.
OIDC Federation. Pipeline authentifiziert sich beim Cloud-Provider ohne statische Credentials. GitHub Actions OIDC mit AWS: GitHub liefert Token, AWS verifiziert, gewährt temporäre Credentials. Null statische Secrets.
Sealed Secrets / SOPS. Verschlüsselte Secrets im Repo gespeichert, nur von autorisierten Systemen entschlüsselbar. GitOps-freundlicher Ansatz.
Wie konfiguriert man HashiCorp Vault für CI/CD?
Vault als zentraler Secrets Store. Alle Secrets in Vault, Applications und Pipelines holen von Vault. Single Source of Truth.
Authentifizierungsmethoden für CI/CD:
- AppRole: Pipeline hat role_id (statisch) und secret_id (dynamisch), nutzt für Auth
- JWT/OIDC: CI-Plattform liefert JWT, Vault verifiziert und gewährt Token
- Kubernetes Auth: für K8s-basierte CI, Service-Account-Auth
- AWS/GCP/Azure Auth: Pipeline läuft in Cloud, authentifiziert via Cloud IAM
Policies und Access Control. Principle of Least Privilege: Pipeline für Projekt X hat nur Zugang zu Secrets von Projekt X. Policies definieren, wer was lesen/schreiben kann.
Dynamic Secrets. Statt statischem Datenbank-Passwort - Vault generiert temporäre Credentials auf Anfrage. Pipeline fordert DB-Zugang → Vault erstellt User/Passwort mit 1h TTL → Pipeline nutzt → Credentials verfallen automatisch.
Audit Logging. Jeder Secrets-Zugriff wird geloggt. Wer, wann, was. Forensik-Fähigkeit.
Wie verhindert man versehentliches Secret-Committen?
Pre-commit Hooks. Tools, die Code vor Commit scannen:
- TruffleHog: Entropie-basierte Erkennung + bekannte Muster
- git-secrets: AWS-fokussiert, anpassbare Muster
- detect-secrets: Yelps Tool, Baseline-Fähigkeit
- Gitleaks: schnell, umfassend
CI/CD-Scanning. Backup für Pre-commit - Scanning in Pipeline:
- GitHub Advanced Security (Secret Scanning)
- GitLab Secret Detection
- Dedizierte Tools (TruffleHog, Gitleaks) in CI
.gitignore Best Practices. .env*, *.pem, *.key, credentials.json - immer ignorieren. Template-Dateien (.env.example) ohne echte Werte.
Wie handhabt man Secrets in Docker-Builds?
Problem: Secrets im Image. Docker-Layers sind gecacht und inspizierbar. Selbst RUN rm /secrets entfernt Secrets nicht aus vorherigem Layer.
BuildKit Secrets (—secret). Secret ist nicht im Image-Layer, nur während Build verfügbar.
Multi-stage Builds für Compile-time Secrets. Finales Image hat keine Secrets.
Runtime Secrets Injection. Secrets nicht ins Image backen. Zur Laufzeit injizieren via Environment Variables, Docker Secrets, Kubernetes Secrets oder externen Secrets Manager.
Wie verwaltet man Secrets in Kubernetes?
Native Kubernetes Secrets. Base64-encoded (nicht verschlüsselt!). In etcd gespeichert. Basis-Isolation.
Problem: K8s Secrets sind standardmäßig nicht at rest verschlüsselt. Jeder mit etcd-Zugang oder ausreichendem RBAC kann lesen.
Encryption at Rest. Encryption Provider aktivieren (aesgcm, kms).
External Secrets Operator. Synct Secrets von externen Stores (Vault, AWS SM, Azure KV) zu K8s Secrets.
Sealed Secrets (Bitnami). Secrets mit Public Key verschlüsseln, verschlüsselte Version ins Repo committen, Controller entschlüsselt im Cluster. GitOps-freundlich.
Tabelle: Secrets Management Maturity Model
| Level | Charakteristik | Beispiel | Risiko-Level | Nächster Schritt |
|---|---|---|---|---|
| 0 - Chaos | Secrets in Code/Repo | Hardcodierte Passwörter in committeter .env | Kritisch | Pre-commit Hooks, aus History entfernen |
| 1 - Basic | CI-native Secrets | GitHub Secrets, GitLab CI Variables | Hoch | In externem Secrets Manager zentralisieren |
| 2 - Zentralisiert | Externer Secrets Manager | Vault oder Cloud-native (AWS SM) | Mittel | Rotation, Dynamic Secrets implementieren |
| 3 - Dynamisch | Kurzlebige Credentials | Vault Dynamic DB Creds, OIDC Federation | Niedrig | Volle Auditierung, Zero Standing Privileges |
| 4 - Zero Trust | Just-in-time, voll auditiert | Dynamic Creds + Approval Workflow + volle Auditierung | Minimal | Kontinuierliche Verbesserung, Red Team Testing |
Secrets Management in CI/CD ist Sicherheitsfundament für Software Delivery. Ein Credential-Leak kann gesamte Infrastruktur kompromittieren. Gute Praktiken sind nicht schwer - sie erfordern Awareness und Konsequenz.
Wichtige Erkenntnisse:
- Niemals Secrets committen - Pre-commit Hooks sind Must-have
- CI-native Secrets ist Baseline - externer Secrets Manager ist besser
- OIDC Federation eliminiert statische Credentials für Cloud
- Docker Secrets (BuildKit —secret) schützt vor Layer-Leaks
- Rotation muss geplant werden - Dual-Secret-Periode, Dynamic Secrets
- Alles auditieren - wer, was, wann auf Secrets zugegriffen hat
- Test-Umgebung-Isolation - Test-Secrets ≠ Produktions-Secrets
- Kubernetes Secrets sind standardmäßig nicht verschlüsselt - externe Lösungen nutzen
Investition in ordentliches Secrets Management zahlt sich beim ersten vermiedenen Incident aus. Kosten für Vault oder AWS Secrets Manager-Deployment sind Bruchteil der Breach-Response-Kosten.
ARDURA Consulting bietet DevSecOps-Spezialisten über Body Leasing mit Erfahrung in der Implementierung von Secrets Management für Enterprise CI/CD-Pipelines. Unsere Experten helfen bei der Bereitstellung von HashiCorp Vault, Konfiguration von Cloud-nativen Secrets Managern und dem Aufbau sicherer Delivery-Pipelines. Sprechen wir über die Absicherung eurer CI/CD.