04 Security Hardening
Dieses Lab zeigt RBAC, sichere Pod-Defaults, NetworkPolicy und ein bewusst riskantes Manifest.
1. Prüfen
kubectl apply --dry-run=client -f manifests/
2. Aufgaben
- Vergleiche
20-secure-pod.yamlund90-risky-pod.yaml. - Erkläre, warum
hostPath,privilegedundhostNetworkriskant sind. - Prüfe die RBAC-Rechte mit
kubectl auth can-i. - Prüfe, warum DNS-Egress trotz Default-Deny explizit erlaubt werden muss.
3. Ziel
Dieses Beispiel zeigt einen konkreten, lokal nachvollziehbaren Anwendungsfall für das jeweilige Workshop-Thema.
4. Voraussetzungen
- Ubuntu-basierte Lab-Umgebung.
- Die Workshop-Dateien liegen lokal vor.
- Provisionierung wurde bei Bedarf mit
scripts/provision.sh --dry-rungeprüft. - Keine echten Secrets oder produktiven Daten verwenden.
5. Dateien
Die Dateien in diesem Verzeichnis bilden zusammen ein kleines, reviewbares Lab. Konfigurationen und Skripte sind bewusst klein gehalten, damit sie im Training besprochen werden können.
6. Ausführung
- Lies die README dieses Beispiels.
- Prüfe Skripte oder Konfigurationen vor der Ausführung.
- Führe nur nicht-destruktive Befehle direkt aus.
- Dokumentiere Abweichungen der lokalen Umgebung.
7. Erwartetes Ergebnis
Das Beispiel soll den beschriebenen Zielzustand nachvollziehbar machen und eine klare Validierung über Statusausgabe, Dateiinhalt, Testkommando oder Logeintrag erlauben.
8. Erklärung
Die Umsetzung demonstriert einen typischen Praxisbaustein. Wichtige Entscheidungen sind Reproduzierbarkeit, Lesbarkeit, sichere Dummy-Werte und einfache Rückbaubarkeit.
9. Typische Fehler
- Voraussetzungen oder Tools fehlen.
- Pfade werden aus einem anderen Arbeitsverzeichnis ausgeführt.
- Lokale Ports, Namen oder IP-Bereiche kollidieren.
- Beispielwerte werden versehentlich für produktive Systeme gehalten.
10. Erweiterungsmöglichkeiten
- Beispiel um eine zweite Umgebung erweitern.
- Validierung automatisieren.
- Security- und Troubleshooting-Notizen ergänzen.
- In eine Workshop-Übung oder Assessment-Frage überführen.