Beispiel-Dokumentation: Kubernetes Security hardening
1. Ziel
RBAC, Pod Security, NetworkPolicy, Secrets, Supply Chain und Runtime Detection härten.
2. Was gemacht wird
Das Beispiel wird über Manifest-Review, kubectl-Ausgaben, Events, Logs und Cleanup-Notiz untersucht. Ohne Cluster wird die Controller-Wirkung begründet simuliert.
3. Warum es gemacht wird
Kubernetes ist deklarativ und controllerbasiert. Ein Manifest kann Workloads, Netzwerk, Storage, Rechte oder Policies verändern und braucht deshalb Validierung.
4. Typische Kommandos
kubectl get all -A 2>/dev/null || true
kubectl get events -A --sort-by=.lastTimestamp 2>/dev/null || true
kubectl describe deploy -A 2>/dev/null || true
kubectl auth can-i --list 2>/dev/null || true
5. Erfolg prüfen
- Ressourcen existieren im erwarteten Namespace.
- Status, Conditions und Events sind plausibel.
- Service, Storage, NetworkPolicy oder SecurityContext verhalten sich wie dokumentiert.
- Rollback und Owner sind dokumentiert.
6. Typische Fehler
- falscher Namespace oder Selector.
- fehlende Requests/Limits.
- Secret als Klartext in Git.
- Service ohne Endpoints.
- zu breite RBAC- oder privileged-Workloads.
7. Sicherheitsaspekte
Keine echten Secrets verwenden. RBAC, NetworkPolicy, Pod Security Restricted, Image-Signaturen und Admission Policies bewerten.
8. Realistischer Einsatz
Das Beispiel wird in GitOps, Plattform-Runbooks, Review-Checklisten, Incident Response, DR-Tests und Audit-Nachweise übertragen.