1. Prüfen

kubectl apply --dry-run=client -f manifests/

2. Aufgaben

1. Vergleiche 20-secure-pod.yaml und 90-risky-pod.yaml.
2. Erkläre, warum hostPath, privileged und hostNetwork riskant sind.
3. Prüfe die RBAC-Rechte mit kubectl auth can-i.
4. 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-run geprü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

1. Lies die README dieses Beispiels.
2. Prüfe Skripte oder Konfigurationen vor der Ausführung.
3. Führe nur nicht-destruktive Befehle direkt aus.
4. 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.