Merge branch 'workshop-angaben-tls-windows' into 'main'
Workshop-Angaben, TLS-Fixes, Windows-Tauglichkeit und einheitliche Stack-Steuerung See merge request hkoeck/htl-reverse-proxy-tls-lab!1
This commit is contained in:
Herwig Koeck
@@ -1 +0,0 @@
|
||||
HTTP_PORT=8080
|
||||
@@ -1,29 +0,0 @@
|
||||
.PHONY: bootstrap up down logs redeploy proxy-reload reset reset-hard reset-origin
|
||||
|
||||
bootstrap:
|
||||
./scripts/bootstrap.sh
|
||||
|
||||
up:
|
||||
./scripts/compose.sh up -d --build
|
||||
|
||||
redeploy:
|
||||
./scripts/compose.sh up -d --build --remove-orphans
|
||||
./scripts/compose.sh restart reverse-proxy
|
||||
|
||||
proxy-reload:
|
||||
./scripts/compose.sh restart reverse-proxy
|
||||
|
||||
down:
|
||||
./scripts/compose.sh down
|
||||
|
||||
logs:
|
||||
./scripts/compose.sh logs -f
|
||||
|
||||
reset:
|
||||
./scripts/reset-lab.sh
|
||||
|
||||
reset-hard:
|
||||
./scripts/reset-lab.sh --hard
|
||||
|
||||
reset-origin:
|
||||
./scripts/reset-lab.sh --hard-origin
|
||||
@@ -47,11 +47,11 @@ winget install --id OpenSSL.OpenSSL -e
|
||||
winget install --id WiresharkFoundation.Wireshark -e
|
||||
```
|
||||
|
||||
Nach der Installation von Docker Desktop aktiviere die WSL-Integration in den Einstellungen.
|
||||
Nach der Installation von Docker Desktop die WSL-Integration in den Einstellungen aktivieren.
|
||||
|
||||
### Linux / macOS
|
||||
|
||||
Docker Engine oder Docker Desktop installieren (falls `make` fehlt auf macOS: `xcode-select --install`).
|
||||
Docker Engine oder Docker Desktop installieren.
|
||||
|
||||
Optional fuer TLS-Challenges:
|
||||
|
||||
@@ -82,7 +82,13 @@ Falls PowerShell das Script blockiert:
|
||||
Set-ExecutionPolicy -Scope Process Bypass
|
||||
```
|
||||
|
||||
Alternativ im WSL-Terminal:
|
||||
Wenn mehrere WSL-Distros installiert sind:
|
||||
|
||||
```powershell
|
||||
./scripts/workshop.ps1 -Action bootstrap -Distro Ubuntu-24.04
|
||||
```
|
||||
|
||||
Alternativ direkt im WSL-Terminal:
|
||||
|
||||
```bash
|
||||
./scripts/bootstrap.sh
|
||||
@@ -97,52 +103,35 @@ Alternativ im WSL-Terminal:
|
||||
Das Skript:
|
||||
|
||||
- prueft Docker + Compose
|
||||
- erstellt `.env` aus `.env.example` (falls nicht vorhanden)
|
||||
- startet den Stack
|
||||
|
||||
Hinweis zu Skriptnamen:
|
||||
|
||||
- `scripts/bootstrap.sh` ist der empfohlene Einstieg
|
||||
- intern nutzt es `scripts/bootstrap-unix.sh`
|
||||
- `scripts/bootstrap-wsl.sh` existiert nur noch als Kompatibilitaets-Wrapper
|
||||
Der PowerShell-Wrapper ruft intern `./scripts/lab.sh` in WSL auf - dieselbe Steuer-Oberflaeche wie unter Linux/WSL.
|
||||
|
||||
## Neu deployen / resetten
|
||||
|
||||
### Windows
|
||||
|
||||
Weitere Aktionen in PowerShell:
|
||||
|
||||
```powershell
|
||||
./scripts/workshop.ps1 -Action redeploy
|
||||
./scripts/workshop.ps1 -Action proxy-reload
|
||||
./scripts/workshop.ps1 -Action reset
|
||||
./scripts/workshop.ps1 -Action reset-hard
|
||||
./scripts/workshop.ps1 -Action reset-origin
|
||||
```
|
||||
|
||||
Wenn mehrere Distros installiert sind:
|
||||
|
||||
```powershell
|
||||
./scripts/workshop.ps1 -Action bootstrap -Distro Ubuntu-24.04
|
||||
```
|
||||
|
||||
### Linux / macOS
|
||||
Alle Aktionen laufen ueber `./scripts/lab.sh <aktion>` (in WSL/Linux). Windows-PowerShell-Nutzer nehmen `./scripts/workshop.ps1 -Action <aktion>` - dahinter steckt dasselbe Skript.
|
||||
|
||||
```bash
|
||||
make redeploy
|
||||
make proxy-reload
|
||||
make reset
|
||||
make reset-hard
|
||||
make reset-origin
|
||||
./scripts/lab.sh up
|
||||
./scripts/lab.sh redeploy
|
||||
./scripts/lab.sh proxy-reload
|
||||
./scripts/lab.sh down
|
||||
./scripts/lab.sh logs
|
||||
./scripts/lab.sh reset
|
||||
./scripts/lab.sh reset-hard
|
||||
./scripts/lab.sh reset-origin
|
||||
```
|
||||
|
||||
- `up`: build + start (entspricht dem, was `bootstrap` am Ende macht)
|
||||
- `redeploy`: build + restart aller Services
|
||||
- `proxy-reload`: nur Reverse Proxy restart
|
||||
- `down`: Stack stoppen (Container entfernen, Volumes bleiben)
|
||||
- `logs`: Logs aller Services folgen (`Strg+C` zum Beenden)
|
||||
- `reset`: Container/Netzwerk/Volumes aufraeumen
|
||||
- `reset-hard`: wie `reset`, plus lokale Git-Aenderungen verwerfen (falls Git-Repo)
|
||||
- `reset-origin`: wie `reset-hard`, aber bevorzugt Ruecksetzen auf `origin/main`
|
||||
|
||||
Hinweis: `make redeploy` startet zusaetzlich den Reverse Proxy neu, damit Nginx-Config-Aenderungen sicher aktiv sind.
|
||||
Hinweis: `redeploy` startet zusaetzlich den Reverse Proxy neu, damit Nginx-Config-Aenderungen sicher aktiv sind.
|
||||
|
||||
## Kurz testen
|
||||
|
||||
@@ -151,6 +140,8 @@ curl http://localhost:8080/service/a
|
||||
curl http://localhost:8080/service/b
|
||||
```
|
||||
|
||||
> **Windows:** Diese und alle weiteren Test-Kommandos (`curl`, `openssl`, `grep`, Schleifen) im **WSL-Terminal (bash)** ausfuehren, nicht in PowerShell. In PowerShell ist `curl` ein Alias fuer `Invoke-WebRequest` und versteht die genutzten Flags (`-I`, `-k`, `--cacert`) nicht. PowerShell nur fuer den Stack-Wrapper `scripts/workshop.ps1`.
|
||||
|
||||
## Fokus im Workshop
|
||||
|
||||
Die Basis ist bewusst nur HTTP. HTTPS ist Teil der Aufgaben:
|
||||
|
||||
@@ -64,6 +64,7 @@
|
||||
</style>
|
||||
</head>
|
||||
<body>
|
||||
<!-- INSTANCE=A -->
|
||||
<main>
|
||||
<span class="tag">Backend A</span>
|
||||
<h1>Reverse Proxy Target A</h1>
|
||||
|
||||
@@ -39,6 +39,7 @@
|
||||
</style>
|
||||
</head>
|
||||
<body>
|
||||
<!-- INSTANCE=A2 -->
|
||||
<main>
|
||||
<h1>Reverse Proxy Target A2</h1>
|
||||
<p>Use this page to validate load balancing between backend-a and backend-a2.</p>
|
||||
|
||||
+186
-61
@@ -8,13 +8,29 @@ Diese Aufgaben sind bewusst auf **manuelle Proxy-Konfiguration** ausgelegt.
|
||||
- Done-Check Command live ausfuehren
|
||||
- 2-3 Saetze erklaeren: was geaendert, warum, welche Wirkung
|
||||
|
||||
## Wo laufen die Kommandos? (besonders Windows)
|
||||
|
||||
Die meisten Teilnehmer arbeiten unter **Windows mit Docker Desktop + WSL**. Wichtig:
|
||||
|
||||
- **Stack steuern** (`./scripts/lab.sh ...` in WSL oder der PowerShell-Wrapper `scripts/workshop.ps1`): geht aus PowerShell **oder** aus dem WSL-Terminal.
|
||||
- **Alle Challenge-Kommandos** (`curl`, `openssl`, `grep`, `wget`, `for`-Schleifen, `./scripts/compose.sh ...`): laufen im **WSL-Terminal (bash)**, nicht in PowerShell.
|
||||
- **Warnung:** In PowerShell ist `curl` ein Alias fuer `Invoke-WebRequest` und versteht die hier genutzten Flags (`-I`, `-k`, `--cacert`) **nicht**. Immer im WSL-Terminal testen.
|
||||
- Das Repo liegt im WSL-Dateisystem oder unter `/mnt/c/...`; arbeite am besten aus dem WSL-Terminal im Projektordner.
|
||||
|
||||
## Arbeitsmodus
|
||||
|
||||
1. Dateien anpassen (`proxy/nginx.conf`, `docker-compose.yml`).
|
||||
2. Deployen mit `make redeploy` oder `make proxy-reload`.
|
||||
2. Deployen: nach reinen `nginx.conf`-Aenderungen reicht `./scripts/lab.sh proxy-reload`; nach Aenderungen an `docker-compose.yml` (z. B. neue Ports oder Services) immer `./scripts/lab.sh redeploy`, da der Container neu erstellt werden muss.
|
||||
3. Testen mit `curl` / `openssl` / Wireshark.
|
||||
4. Bei Problemen: `./scripts/compose.sh logs reverse-proxy`.
|
||||
|
||||
## Arbeitsweise (wichtig)
|
||||
|
||||
- Es wird **additiv in einer einzigen `proxy/nginx.conf`** gearbeitet: jede Challenge erweitert den Stand der vorherigen. Loesungen nicht wieder loeschen - die TLS-Challenges (10-12) bauen direkt aufeinander auf.
|
||||
- **Ausnahme Challenge 9** (Debugging): Diese ueberschreibt die `nginx.conf` bewusst. Vorher sichern (`cp proxy/nginx.conf proxy/nginx.conf.bak`), danach wiederherstellen.
|
||||
- Jede Angabe nennt einen **Ausgangszustand** (worauf baue ich auf) und einen **Zielzustand / Akzeptanz** (woran erkenne ich "fertig"). Der Done-Check ist die pruefbare Form des Zielzustands.
|
||||
- Komplett zuruecksetzen geht jederzeit mit `./scripts/lab.sh reset` (Container/Volumes) bzw. `./scripts/lab.sh reset-hard` (zusaetzlich lokale Datei-Aenderungen verwerfen).
|
||||
|
||||
---
|
||||
|
||||
## Easy
|
||||
@@ -24,45 +40,59 @@ Diese Aufgaben sind bewusst auf **manuelle Proxy-Konfiguration** ausgelegt.
|
||||
**Ziel**
|
||||
- Verstehen, wie Nginx Requests per Pfad an unterschiedliche Upstreams schickt.
|
||||
|
||||
**Muss**
|
||||
**Datei**
|
||||
- `proxy/nginx.conf` (nur lesen)
|
||||
|
||||
**Schritte (Muss)**
|
||||
- Vor dem Test in `proxy/nginx.conf` nachsehen, welche `location` auf welchen `upstream` zeigt.
|
||||
- Dann erst Requests ausfuehren.
|
||||
- In eigenen Worten erklaeren, warum die Antworten unterschiedlich sind.
|
||||
|
||||
**Warum wichtig**
|
||||
- Das ist die Kernkompetenz bei Reverse Proxys: Request-Fluss lesen und korrekt begruenden.
|
||||
**Zielzustand / Akzeptanz**
|
||||
- Du kannst fuer `/service/a` und `/service/b` jeweils Location -> Upstream -> Backend benennen und begruenden, warum die Antworten unterschiedlich sind.
|
||||
|
||||
**Done-Check**
|
||||
```bash
|
||||
curl http://localhost:8080/service/a
|
||||
curl http://localhost:8080/service/b
|
||||
curl http://localhost:8080/service/a # -> "Reverse Proxy Target A"
|
||||
curl http://localhost:8080/service/b # -> "Reverse Proxy Target B"
|
||||
```
|
||||
|
||||
**Warum wichtig**
|
||||
- Das ist die Kernkompetenz bei Reverse Proxys: Request-Fluss lesen und korrekt begruenden.
|
||||
|
||||
### 2) Drittes Backend manuell hinzufuegen
|
||||
|
||||
**Ziel**
|
||||
- Setup sicher erweitern, ohne bestehende Routen kaputt zu machen.
|
||||
|
||||
**Ausgangszustand**
|
||||
- Stack laeuft, `/service/a` und `/service/b` antworten.
|
||||
- `backends/c/index.html` liegt bereits im Repo (Starterseite).
|
||||
|
||||
**Dateien**
|
||||
- `docker-compose.yml`
|
||||
- `proxy/nginx.conf`
|
||||
- `backends/c/index.html` (vorhanden, darf angepasst werden)
|
||||
|
||||
**Muss**
|
||||
**Schritte (Muss)**
|
||||
- Service `backend-c` in Compose einbauen.
|
||||
- Upstream + Route `/service/c` in Nginx anlegen.
|
||||
- A/B muessen weiterhin funktionieren.
|
||||
- Deployen mit `./scripts/lab.sh redeploy` (Compose-Aenderung -> Container-Neustart noetig).
|
||||
|
||||
**Warum wichtig**
|
||||
- In realen Umgebungen kommen neue Services laufend dazu. Saubere Erweiterung ohne Regression ist entscheidend.
|
||||
**Zielzustand / Akzeptanz**
|
||||
- `/service/c` liefert Backend C.
|
||||
- `/service/a` und `/service/b` funktionieren unveraendert weiter (keine Regression).
|
||||
|
||||
**Done-Check**
|
||||
```bash
|
||||
curl http://localhost:8080/service/c
|
||||
curl http://localhost:8080/service/a
|
||||
curl http://localhost:8080/service/b
|
||||
curl http://localhost:8080/service/c # -> enthaelt "Reverse Proxy Target C"
|
||||
curl http://localhost:8080/service/a # -> weiterhin "Reverse Proxy Target A"
|
||||
curl http://localhost:8080/service/b # -> weiterhin "Reverse Proxy Target B"
|
||||
```
|
||||
|
||||
**Warum wichtig**
|
||||
- In realen Umgebungen kommen neue Services laufend dazu. Saubere Erweiterung ohne Regression ist entscheidend.
|
||||
|
||||
### 3) Eigene Route mit Rewrite oder Alias-Route
|
||||
|
||||
**Ziel**
|
||||
@@ -71,18 +101,22 @@ curl http://localhost:8080/service/b
|
||||
**Datei**
|
||||
- `proxy/nginx.conf`
|
||||
|
||||
**Muss**
|
||||
**Schritte (Muss)**
|
||||
- Route `/demo/a` anbieten, die auf Backend A fuehrt.
|
||||
- Entweder per rewrite oder per eigener proxy-Route loesen.
|
||||
- Deployen mit `./scripts/lab.sh proxy-reload`.
|
||||
|
||||
**Warum wichtig**
|
||||
- Der Proxy entkoppelt externe API-Pfade von internen Service-Pfaden und ermoeglicht saubere Migrationen.
|
||||
**Zielzustand / Akzeptanz**
|
||||
- `/demo/a` liefert dieselbe Antwort wie `/service/a` (Backend A), obwohl der externe Pfad ein anderer ist.
|
||||
|
||||
**Done-Check**
|
||||
```bash
|
||||
curl http://localhost:8080/demo/a
|
||||
curl http://localhost:8080/demo/a # -> "Reverse Proxy Target A"
|
||||
```
|
||||
|
||||
**Warum wichtig**
|
||||
- Der Proxy entkoppelt externe API-Pfade von internen Service-Pfaden und ermoeglicht saubere Migrationen.
|
||||
|
||||
---
|
||||
|
||||
## Medium
|
||||
@@ -95,7 +129,7 @@ curl http://localhost:8080/demo/a
|
||||
**Datei**
|
||||
- `proxy/nginx.conf`
|
||||
|
||||
**Muss**
|
||||
**Schritte (Muss)**
|
||||
- Mindestens setzen:
|
||||
- `X-Content-Type-Options: nosniff`
|
||||
- `X-Frame-Options: DENY`
|
||||
@@ -104,15 +138,24 @@ curl http://localhost:8080/demo/a
|
||||
- `Cross-Origin-Opener-Policy: same-origin`
|
||||
- `Cross-Origin-Resource-Policy: same-origin`
|
||||
- Optional (Bonus): `Content-Security-Policy` fuer statische Seiten (mit Inline-Styles bewusst beruecksichtigen)
|
||||
- Deployen mit `./scripts/lab.sh proxy-reload`.
|
||||
|
||||
**Warum wichtig**
|
||||
- Diese Header reduzieren typische Browser-Angriffsvektoren und gehoeren zu Security-Baselines.
|
||||
**Fallstrick (`add_header`-Vererbung)**
|
||||
- Header am besten **einmal im `server {}`-Block** setzen, dann gelten sie fuer alle Locations.
|
||||
- Achtung: Sobald in einem `location {}`-Block **ein** `add_header` steht, verwirft Nginx in dieser Location **alle** `add_header` aus dem `server`-Block. Dann muessen sie dort wiederholt werden. Pruefen mit `curl -I` direkt auf der jeweiligen Route.
|
||||
|
||||
**Zielzustand / Akzeptanz**
|
||||
- `curl -I http://localhost:8080/` zeigt alle geforderten Security-Header in der Antwort.
|
||||
|
||||
**Done-Check**
|
||||
```bash
|
||||
curl -I http://localhost:8080/
|
||||
# -> zeigt X-Content-Type-Options, X-Frame-Options, Referrer-Policy, Permissions-Policy, COOP, CORP
|
||||
```
|
||||
|
||||
**Warum wichtig**
|
||||
- Diese Header reduzieren typische Browser-Angriffsvektoren und gehoeren zu Security-Baselines.
|
||||
|
||||
### 5) Interne Route absichern
|
||||
|
||||
**Ziel**
|
||||
@@ -121,25 +164,29 @@ curl -I http://localhost:8080/
|
||||
**Datei**
|
||||
- `proxy/nginx.conf`
|
||||
|
||||
**Muss**
|
||||
**Schritte (Muss)**
|
||||
- Route `/internal/status` bauen.
|
||||
- Nur `127.0.0.1` erlauben, alle anderen verbieten.
|
||||
|
||||
**Warum wichtig**
|
||||
- Nicht jeder Endpoint soll oeffentlich sein; Zugriffskontrolle direkt am Proxy ist oft die erste Schutzschicht.
|
||||
- Deployen mit `./scripts/lab.sh proxy-reload`.
|
||||
|
||||
**Wichtiger Hinweis**
|
||||
- Host-Request ueber `localhost:8080` kommt aus Docker-Sicht oft **nicht** von `127.0.0.1`.
|
||||
|
||||
**Zielzustand / Akzeptanz**
|
||||
- Aufruf vom Host liefert `403`; Aufruf von innerhalb des Proxy-Containers (`127.0.0.1`) liefert die Antwort.
|
||||
|
||||
**Done-Check**
|
||||
```bash
|
||||
# Erwartet typischerweise 403 vom Host (by design)
|
||||
curl -i http://localhost:8080/internal/status
|
||||
# -> Erwartet typischerweise 403 vom Host (by design)
|
||||
|
||||
# Muss innerhalb des Proxy-Containers funktionieren
|
||||
./scripts/compose.sh exec -T reverse-proxy sh -lc "wget -qO- http://127.0.0.1/internal/status"
|
||||
# -> "internal ok" (funktioniert nur container-intern)
|
||||
```
|
||||
|
||||
**Warum wichtig**
|
||||
- Nicht jeder Endpoint soll oeffentlich sein; Zugriffskontrolle direkt am Proxy ist oft die erste Schutzschicht.
|
||||
|
||||
### 6) Logging verbessern
|
||||
|
||||
**Ziel**
|
||||
@@ -148,19 +195,27 @@ curl -i http://localhost:8080/internal/status
|
||||
**Datei**
|
||||
- `proxy/nginx.conf`
|
||||
|
||||
**Muss**
|
||||
**Schritte (Muss)**
|
||||
- Eigenes `log_format` mit Upstream-Infos anlegen.
|
||||
- Access-Log auf das neue Format umstellen.
|
||||
- Deployen mit `./scripts/lab.sh proxy-reload`.
|
||||
|
||||
**Warum wichtig**
|
||||
- Gute Logs verkuerzen Incident- und Debug-Zeit drastisch und sind zentral fuer Betrieb/Security.
|
||||
**Hinweis**
|
||||
- `log_format` gehoert in den `http {}`-Block (nicht in `server {}` oder `location {}`), sonst startet Nginx mit `"log_format" directive is not allowed here` nicht. `access_log` darf in `http`, `server` oder `location` stehen.
|
||||
|
||||
**Zielzustand / Akzeptanz**
|
||||
- Nach einem Request erscheint im Log eine Zeile im neuen Format inklusive Upstream-Infos (`upstream=...`, `urt=...`).
|
||||
|
||||
**Done-Check**
|
||||
```bash
|
||||
curl http://localhost:8080/service/a
|
||||
./scripts/compose.sh logs reverse-proxy
|
||||
# -> neue Log-Zeile mit upstream=... und urt=...
|
||||
```
|
||||
|
||||
**Warum wichtig**
|
||||
- Gute Logs verkuerzen Incident- und Debug-Zeit drastisch und sind zentral fuer Betrieb/Security.
|
||||
|
||||
### 7) Load Balancing konfigurieren
|
||||
|
||||
**Ziel**
|
||||
@@ -170,20 +225,29 @@ curl http://localhost:8080/service/a
|
||||
- `docker-compose.yml`
|
||||
- `proxy/nginx.conf`
|
||||
|
||||
**Muss**
|
||||
**Ausgangszustand**
|
||||
- `/service/a` zeigt aktuell nur eine Instanz (Backend A). `backends/a2/index.html` liegt bereits im Repo.
|
||||
|
||||
**Schritte (Muss)**
|
||||
- Zweite Instanz von Backend A (`backend-a2`) anlegen.
|
||||
- `upstream backend_a` auf beide Instanzen erweitern.
|
||||
- Mehrfach-Requests zeigen, dass beide Instanzen antworten.
|
||||
- Deployen mit `./scripts/lab.sh redeploy` (Compose-Aenderung).
|
||||
|
||||
**Warum wichtig**
|
||||
- Lastverteilung ist eine der wichtigsten Funktionen eines Reverse Proxys fuer Skalierung und Verfuegbarkeit.
|
||||
**Zielzustand / Akzeptanz**
|
||||
- Bei mehreren Aufrufen von `/service/a` antworten **beide** Instanzen (Round-Robin), also sowohl `Target A` als auch `Target A2`.
|
||||
|
||||
**Done-Check (Beispiel)**
|
||||
```bash
|
||||
for i in $(seq 1 8); do
|
||||
curl -s http://localhost:8080/service/a | grep -o "Target A2\|Target A"
|
||||
curl -s http://localhost:8080/service/a | grep -o "INSTANCE=[A-Za-z0-9]*"
|
||||
done
|
||||
# -> Mischung aus "INSTANCE=A" und "INSTANCE=A2" ueber die 8 Requests
|
||||
```
|
||||
- Der unsichtbare Marker `<!-- INSTANCE=A -->` bzw. `INSTANCE=A2` steckt im HTML der Backends. `[A-Za-z0-9]*` matched das ganze Token eindeutig (kein Prefix-Problem wie bei `A` vs. `A2`).
|
||||
|
||||
**Warum wichtig**
|
||||
- Lastverteilung ist eine der wichtigsten Funktionen eines Reverse Proxys fuer Skalierung und Verfuegbarkeit.
|
||||
|
||||
### 8) Response Header Minimization
|
||||
|
||||
@@ -193,51 +257,64 @@ done
|
||||
**Datei**
|
||||
- `proxy/nginx.conf`
|
||||
|
||||
**Muss**
|
||||
**Schritte (Muss)**
|
||||
- Mit `proxy_hide_header` mindestens einen durchgereichten Backend-Header ausblenden
|
||||
(z. B. `ETag`, `Last-Modified`).
|
||||
- Kurz erklaeren, warum weniger Fingerprinting-Infos hilfreich sind.
|
||||
- Deployen mit `./scripts/lab.sh proxy-reload`.
|
||||
|
||||
**Abgrenzung zu Challenge 4**
|
||||
- Challenge 4 setzt aktive Schutz-Header.
|
||||
- Challenge 8 entfernt unnoetige Header aus Upstream-Responses.
|
||||
|
||||
**Warum wichtig**
|
||||
- Weniger Response-Metadaten bedeuten weniger Angriffsoberflaeche fuer Fingerprinting und Reconnaissance.
|
||||
**Zielzustand / Akzeptanz**
|
||||
- Der gewaehlte Header (z. B. `ETag`) taucht in `curl -I http://localhost:8080/service/a` **nicht mehr** auf, vorher war er sichtbar.
|
||||
|
||||
**Done-Check**
|
||||
```bash
|
||||
curl -I http://localhost:8080/service/a
|
||||
# -> der ausgeblendete Header (z. B. ETag) fehlt jetzt in der Antwort
|
||||
```
|
||||
|
||||
**Warum wichtig**
|
||||
- Weniger Response-Metadaten bedeuten weniger Angriffsoberflaeche fuer Fingerprinting und Reconnaissance.
|
||||
|
||||
### 9) Debugging Challenge (kaputte Config reparieren)
|
||||
|
||||
**Ziel**
|
||||
- Fehlerdiagnose in Nginx ueben.
|
||||
|
||||
**Ausgangszustand**
|
||||
- Eigene `proxy/nginx.conf` ist in Betrieb. `proxy/nginx.broken.conf` enthaelt absichtlich mehrere Fehler.
|
||||
|
||||
**Datei**
|
||||
- `proxy/nginx.broken.conf`
|
||||
|
||||
**Muss**
|
||||
**Schritte (Muss)**
|
||||
- Zuerst die eigene `proxy/nginx.conf` sichern (z. B. `cp proxy/nginx.conf proxy/nginx.conf.bak`) - diese Challenge ueberschreibt sie.
|
||||
- Defekte Config testweise als aktive Config verwenden.
|
||||
- Mindestens 2-3 Fehler finden und fixen.
|
||||
- Symptome und Diagnoseweg erklaeren.
|
||||
- Am Ende die eigene Config wiederherstellen (`cp proxy/nginx.conf.bak proxy/nginx.conf`).
|
||||
|
||||
**Erwartete Fehlerarten (Beispiel aus `nginx.broken.conf`)**
|
||||
- Upstream-Name passt nicht zum referenzierten Namen in `proxy_pass`.
|
||||
- Falscher Upstream-Port (`8080` statt `80`).
|
||||
- Fehlender Trailing Slash in `proxy_pass` bei Prefix-Location.
|
||||
|
||||
**Warum wichtig**
|
||||
- Debugging unter Druck ist Praxisalltag; diese Aufgabe trainiert systematisches Vorgehen mit Logs und Config-Tests.
|
||||
**Zielzustand / Akzeptanz**
|
||||
- Nach den Fixes liefern `/service/a` und `/service/b` wieder ihre Backends; Nginx startet ohne Config-Fehler.
|
||||
|
||||
**Done-Check**
|
||||
```bash
|
||||
curl http://localhost:8080/service/a
|
||||
curl http://localhost:8080/service/b
|
||||
curl http://localhost:8080/service/a # -> "Reverse Proxy Target A"
|
||||
curl http://localhost:8080/service/b # -> "Reverse Proxy Target B"
|
||||
./scripts/compose.sh logs reverse-proxy
|
||||
```
|
||||
|
||||
**Warum wichtig**
|
||||
- Debugging unter Druck ist Praxisalltag; diese Aufgabe trainiert systematisches Vorgehen mit Logs und Config-Tests.
|
||||
|
||||
---
|
||||
|
||||
## Hard (TLS)
|
||||
@@ -247,23 +324,40 @@ curl http://localhost:8080/service/b
|
||||
**Ziel**
|
||||
- Eigene CA + Server-Zertifikat fuer `localhost` erstellen.
|
||||
|
||||
**Ausgangszustand**
|
||||
- Stack laeuft auf HTTP (`8080`). Noch kein TLS, kein Port `8443`.
|
||||
- `easy-rsa` und `openssl` sind installiert (siehe `challenges/easyrsa-hints.md`).
|
||||
|
||||
**Dateien**
|
||||
- `docker-compose.yml`
|
||||
- `proxy/nginx.conf`
|
||||
- `docker-compose.yml` (Port `8443:443` + Cert-Volume)
|
||||
- `proxy/nginx.conf` (TLS-Serverblock)
|
||||
- `certs/easyrsa/*` (PKI), `certs/live/*` (Runtime-Cert + Key)
|
||||
|
||||
**Muss**
|
||||
- Zertifikat fuer `localhost` erstellen.
|
||||
- Proxy auf `443` erweitern (z. B. `8443:443`).
|
||||
- Root-CA importieren und ohne `-k` testen.
|
||||
**Schritte (Muss)**
|
||||
- CA + Server-Zertifikat fuer `localhost` mit SAN erstellen (`--subject-alt-name="DNS:localhost,IP:127.0.0.1"`).
|
||||
- Nur Runtime-Cert + Key bereitstellen (nicht die ganze PKI mounten).
|
||||
- Proxy auf `443` erweitern (Mapping `8443:443`) und TLS in Nginx aktivieren.
|
||||
- Mit `./scripts/lab.sh redeploy` deployen (Compose-Aenderung -> Container-Neustart noetig).
|
||||
- Root-CA in den System-Trust-Store importieren.
|
||||
|
||||
**Warum wichtig**
|
||||
- TLS korrekt einzurichten ist Basis fuer Vertraulichkeit, Integritaet und Vertrauensaufbau im Netzwerk.
|
||||
**Zielzustand / Akzeptanz**
|
||||
- `curl https://localhost:8443/service/a` liefert Backend A **ohne** `-k` (CA wird vertraut).
|
||||
- Kein SAN-/Hostname-Fehler.
|
||||
|
||||
**Done-Check**
|
||||
```bash
|
||||
curl https://localhost:8443/service/a
|
||||
# Erwartet: HTML von Backend A, KEIN "SSL certificate problem"
|
||||
# Falls CA noch nicht global importiert:
|
||||
curl --cacert certs/easyrsa/pki/ca.crt https://localhost:8443/service/a
|
||||
```
|
||||
|
||||
**Warum wichtig**
|
||||
- TLS korrekt einzurichten ist Basis fuer Vertraulichkeit, Integritaet und Vertrauensaufbau im Netzwerk.
|
||||
|
||||
**Haeufigster Blocker**
|
||||
- Ohne SAN scheitert curl mit `no alternative certificate subject name matches target host name` -> beim Signieren `--subject-alt-name` setzen (Details in `challenges/easyrsa-hints.md`).
|
||||
|
||||
### 11) HTTP -> HTTPS Redirect
|
||||
|
||||
**Voraussetzung**
|
||||
@@ -273,21 +367,29 @@ curl https://localhost:8443/service/a
|
||||
**Ziel**
|
||||
- HTTP sauber auf HTTPS umlenken.
|
||||
|
||||
**Ausgangszustand**
|
||||
- Aus Challenge 10: HTTPS laeuft auf `8443`, HTTP auf `8080` liefert noch direkt Inhalte.
|
||||
|
||||
**Datei**
|
||||
- `proxy/nginx.conf`
|
||||
|
||||
**Muss**
|
||||
- HTTP Requests auf HTTPS redirecten.
|
||||
**Schritte (Muss)**
|
||||
- HTTP Requests auf HTTPS redirecten (`return 301 https://$host:8443$request_uri;`).
|
||||
- `/healthz` darf optional auf HTTP bleiben.
|
||||
- Deployen mit `./scripts/lab.sh proxy-reload` (reine `nginx.conf`-Aenderung).
|
||||
|
||||
**Warum wichtig**
|
||||
- Redirect erzwingt verschluesselten Zugriff und verhindert versehentliche Nutzung unsicherer HTTP-Endpunkte.
|
||||
**Zielzustand / Akzeptanz**
|
||||
- HTTP-Aufrufe auf `8080` antworten mit `301` und `Location: https://localhost:8443/...`.
|
||||
|
||||
**Done-Check**
|
||||
```bash
|
||||
curl -I http://localhost:8080/service/a
|
||||
# Erwartet: HTTP/1.1 301 ... und Location: https://localhost:8443/service/a
|
||||
```
|
||||
|
||||
**Warum wichtig**
|
||||
- Redirect erzwingt verschluesselten Zugriff und verhindert versehentliche Nutzung unsicherer HTTP-Endpunkte.
|
||||
|
||||
### 12) TLS Haertung + Chain Check + HSTS
|
||||
|
||||
**Voraussetzung**
|
||||
@@ -300,23 +402,39 @@ curl -I http://localhost:8080/service/a
|
||||
**Datei**
|
||||
- `proxy/nginx.conf`
|
||||
|
||||
**Muss**
|
||||
- TLS auf 1.2/1.3 beschraenken.
|
||||
**Ausgangszustand**
|
||||
- Aus Challenge 10+11: HTTPS auf `8443` laeuft, HTTP wird umgeleitet. TLS ist aber noch ungehaertet (keine Protokoll-Beschraenkung, kein HSTS).
|
||||
|
||||
**Schritte (Muss)**
|
||||
- TLS auf 1.2/1.3 beschraenken (`ssl_protocols TLSv1.2 TLSv1.3;`).
|
||||
- HSTS setzen (`Strict-Transport-Security`).
|
||||
- Zertifikatskette pruefen und kurz erklaeren.
|
||||
|
||||
**Warum wichtig**
|
||||
- Reines "HTTPS an" reicht nicht: erst Haertung + HSTS reduzieren Downgrade- und Fehlkonfigurationsrisiken.
|
||||
- Deployen mit `./scripts/lab.sh proxy-reload`.
|
||||
|
||||
**Hinweis**
|
||||
- Im HTTP-Basissetup ist HSTS absichtlich **noch nicht** aktiv. Das ist Teil der Aufgabe.
|
||||
|
||||
**Warnung (HSTS-Falle im Browser)**
|
||||
- HSTS merkt sich der Browser **host-weit** (`localhost`), nicht pro Port. Nach einem Besuch von `https://localhost:8443` erzwingt der Browser `https` auch fuer `http://localhost:8080` -> das HTTP-Lab scheint dann "kaputt".
|
||||
- Zum Pruefen daher `curl` nutzen (curl speichert HSTS nicht).
|
||||
- Falls der Browser haengt: HSTS fuer `localhost` zuruecksetzen (Chrome: `chrome://net-internals/#hsts` -> "Delete domain security policies" -> `localhost`).
|
||||
- `max-age` ist im Lab bewusst kurz (1h), damit der Effekt von selbst verfaellt.
|
||||
|
||||
**Zielzustand / Akzeptanz**
|
||||
- `curl -I` zeigt den `Strict-Transport-Security`-Header.
|
||||
- `openssl s_client` verhandelt TLSv1.2 oder TLSv1.3 und endet mit `Verify return code: 0 (ok)`.
|
||||
|
||||
**Done-Check**
|
||||
```bash
|
||||
curl -I https://localhost:8443/service/a
|
||||
# -> enthaelt: Strict-Transport-Security: max-age=3600; includeSubDomains
|
||||
openssl s_client -connect localhost:8443 -servername localhost
|
||||
# -> Protocol: TLSv1.3 (oder 1.2), Verify return code: 0 (ok)
|
||||
```
|
||||
|
||||
**Warum wichtig**
|
||||
- Reines "HTTPS an" reicht nicht: erst Haertung + HSTS reduzieren Downgrade- und Fehlkonfigurationsrisiken.
|
||||
|
||||
---
|
||||
|
||||
## Bonus Expert
|
||||
@@ -326,14 +444,18 @@ openssl s_client -connect localhost:8443 -servername localhost
|
||||
**Ziel**
|
||||
- Nachweisbar zeigen, was im Klartext sichtbar ist und was durch TLS geschuetzt wird.
|
||||
|
||||
**Muss**
|
||||
**Ausgangszustand**
|
||||
- HTTPS laeuft (Challenge 10), `8080` und `8443` sind erreichbar. Wireshark/tshark ist installiert (siehe `challenges/wireshark-hints.md`).
|
||||
|
||||
**Schritte (Muss)**
|
||||
- HTTP auf `8080` mitschneiden.
|
||||
- HTTPS auf `8443` mitschneiden.
|
||||
- `ClientHello`, `ServerHello`, `Certificate` markieren.
|
||||
- Technisch erklaeren, warum HTTP lesbar ist und HTTPS ohne Keys nicht.
|
||||
|
||||
**Warum wichtig**
|
||||
- Wer den Unterschied auf Paketebene gesehen hat, versteht TLS nicht nur theoretisch, sondern praktisch.
|
||||
**Zielzustand / Akzeptanz**
|
||||
- HTTP-Mitschnitt: Pfad und Header sind im Klartext lesbar (Follow Stream).
|
||||
- HTTPS-Mitschnitt: nur der TLS-Handshake ist sichtbar, die Nutzdaten sind ohne Key nicht lesbar.
|
||||
|
||||
**Vorgehen (empfohlen)**
|
||||
1. Capture auf passendem Interface starten (lokal meist `lo`).
|
||||
@@ -347,6 +469,9 @@ openssl s_client -connect localhost:8443 -servername localhost
|
||||
**Done-Check**
|
||||
- 3-4 Screenshots + 3-5 Bulletpoints Auswertung.
|
||||
|
||||
**Warum wichtig**
|
||||
- Wer den Unterschied auf Paketebene gesehen hat, versteht TLS nicht nur theoretisch, sondern praktisch.
|
||||
|
||||
**Typische Fehler**
|
||||
- falsches Interface gewaehlt
|
||||
- HTTPS noch nicht korrekt aktiv
|
||||
|
||||
@@ -36,9 +36,11 @@ cd certs/easyrsa
|
||||
|
||||
```bash
|
||||
./easyrsa gen-req localhost nopass
|
||||
./easyrsa sign-req server localhost
|
||||
./easyrsa --subject-alt-name="DNS:localhost,IP:127.0.0.1" sign-req server localhost
|
||||
```
|
||||
|
||||
Wichtig: Das `--subject-alt-name` ist nicht optional. Moderne Clients (curl, Browser) ignorieren den CN und pruefen ausschliesslich den SAN. Ohne SAN scheitert `curl https://localhost:8443` trotz korrekt importierter CA mit `no alternative certificate subject name matches target host name`.
|
||||
|
||||
## 5) Nur Runtime-Zertifikate bereitstellen (nicht komplette PKI mounten)
|
||||
|
||||
Nutze fuer den Container nur die benoetigten Laufzeitdateien:
|
||||
@@ -101,7 +103,7 @@ server {
|
||||
ssl_certificate /etc/nginx/certs/localhost.crt;
|
||||
ssl_certificate_key /etc/nginx/certs/localhost.key;
|
||||
ssl_protocols TLSv1.2 TLSv1.3;
|
||||
add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;
|
||||
add_header Strict-Transport-Security "max-age=3600; includeSubDomains" always;
|
||||
|
||||
add_header X-Content-Type-Options "nosniff" always;
|
||||
add_header X-Frame-Options "DENY" always;
|
||||
@@ -122,6 +124,10 @@ server {
|
||||
|
||||
## 6) Root-CA importieren (Trust Store)
|
||||
|
||||
Wichtig: In den Trust-Store **der Umgebung importieren, in der du testest**.
|
||||
- Test mit `curl` aus **WSL** (der Standardweg im Workshop): in den **Linux**-Trust-Store importieren -> Ubuntu/Debian-Befehle unten.
|
||||
- Test im **Windows-Browser**: zusaetzlich der Windows-Import (`certutil`).
|
||||
|
||||
Fedora:
|
||||
|
||||
```bash
|
||||
|
||||
@@ -22,6 +22,20 @@ sudo apt install -y wireshark tshark
|
||||
- Linux lokal: meist `lo` (Loopback) fuer `localhost`
|
||||
- Docker-Welt: ggf. `docker0` bzw. Bridge-Interface
|
||||
|
||||
**Windows (Docker Desktop + WSL) - empfohlener Weg:**
|
||||
|
||||
- Capture **innerhalb WSL** machen, dort verhaelt sich `lo` wie unter Linux. Sowohl der `curl`-Request als auch der Mitschnitt laufen im WSL-Terminal:
|
||||
|
||||
```bash
|
||||
# Terminal 1 (WSL): Mitschnitt starten
|
||||
sudo tshark -i lo -f "tcp port 8080"
|
||||
# Terminal 2 (WSL): Request senden
|
||||
curl http://localhost:8080/service/a
|
||||
```
|
||||
|
||||
- Natives Windows-Wireshark kann `localhost` nur ueber den npcap-Adapter "Adapter for loopback traffic capture" mitschneiden, und Docker-Desktop-Portforwarding macht das unzuverlaessig. Fuer den Workshop daher in WSL bleiben.
|
||||
- Wireshark-GUI unter WSL braucht WSLg (Windows 11) oder ein X-Server; einfacher ist `tshark` (CLI) plus spaeter `.pcap` in der Wireshark-GUI oeffnen (`tshark -w mitschnitt.pcap ...`).
|
||||
|
||||
## 3) HTTP zuerst (Klartext)
|
||||
|
||||
1. Mitschnitt starten
|
||||
@@ -85,12 +99,14 @@ tls.handshake.type == 11
|
||||
|
||||
## 6) Optional: TLS in Wireshark entschluesseln
|
||||
|
||||
1. Vor Browser-Start setzen:
|
||||
1. Vor Browser-Start setzen (WSL/bash):
|
||||
|
||||
```bash
|
||||
export SSLKEYLOGFILE="$HOME/sslkeys.log"
|
||||
```
|
||||
|
||||
In PowerShell waere es stattdessen `$env:SSLKEYLOGFILE = "$HOME\sslkeys.log"` - der einfachste Weg ist aber, alles in WSL zu machen.
|
||||
|
||||
2. Browser aus derselben Shell starten und HTTPS-Request erzeugen.
|
||||
3. In Wireshark unter TLS-Preferences `sslkeys.log` als Key Log File setzen.
|
||||
4. Mitschnitt erneut laden.
|
||||
|
||||
+1
-1
@@ -8,7 +8,7 @@ services:
|
||||
- backend-a
|
||||
- backend-b
|
||||
ports:
|
||||
- "${HTTP_PORT:-8080}:80"
|
||||
- "8080:80"
|
||||
volumes:
|
||||
- ./proxy/nginx.conf:/etc/nginx/nginx.conf:ro,z
|
||||
- ./proxy/html:/usr/share/nginx/html:ro,z
|
||||
|
||||
+42
-18
@@ -176,6 +176,12 @@
|
||||
</div>
|
||||
</section>
|
||||
|
||||
<section class="panel">
|
||||
<h2>Wo laufen die Kommandos? (Windows)</h2>
|
||||
<p>Stack steuern geht aus PowerShell (<code>scripts/workshop.ps1</code>) <b>oder</b> WSL. Aber <b>alle</b> Test-Kommandos (<code>curl</code>, <code>openssl</code>, <code>grep</code>, <code>for</code>-Schleifen, <code>./scripts/compose.sh</code>) laufen im <b>WSL-Terminal (bash)</b>.</p>
|
||||
<p><span class="kw">Warnung:</span> In PowerShell ist <code>curl</code> ein Alias fuer <code>Invoke-WebRequest</code> und versteht <code>-I</code>/<code>-k</code>/<code>--cacert</code> nicht. Immer im WSL-Terminal testen.</p>
|
||||
</section>
|
||||
|
||||
<section class="panel">
|
||||
<h2>Abgabe-Format</h2>
|
||||
<ul>
|
||||
@@ -196,8 +202,9 @@
|
||||
<li>Welche <code>location</code> matched <code>/service/a</code>?</li>
|
||||
<li>Welcher <code>upstream</code> wird verwendet?</li>
|
||||
</ul>
|
||||
<pre><code>curl http://localhost:8080/service/a
|
||||
curl http://localhost:8080/service/b</code></pre>
|
||||
<p><span class="kw">Zielzustand:</span> Du kannst Location → Upstream → Backend benennen und begruenden, warum A und B unterschiedlich antworten.</p>
|
||||
<pre><code>curl http://localhost:8080/service/a # -> "Target A"
|
||||
curl http://localhost:8080/service/b # -> "Target B"</code></pre>
|
||||
</details>
|
||||
|
||||
<details id="challenge-2-backend-c">
|
||||
@@ -205,16 +212,18 @@ curl http://localhost:8080/service/b</code></pre>
|
||||
<p><span class="kw">Muss:</span> Compose-Service + Upstream + Route <code>/service/c</code>.</p>
|
||||
<p><span class="kw">Zusatz:</span> <code>backends/c/index.html</code> ist vorhanden und darf angepasst werden.</p>
|
||||
<p><span class="kw">Warum wichtig:</span> Neue Services kommen laufend dazu; Erweiterungen ohne Seiteneffekte sind Praxisalltag.</p>
|
||||
<pre><code>curl http://localhost:8080/service/c
|
||||
curl http://localhost:8080/service/a
|
||||
curl http://localhost:8080/service/b</code></pre>
|
||||
<p><span class="kw">Zielzustand:</span> <code>/service/c</code> liefert Backend C; A und B laufen unveraendert weiter.</p>
|
||||
<pre><code>curl http://localhost:8080/service/c # -> "Reverse Proxy Target C"
|
||||
curl http://localhost:8080/service/a # -> weiterhin "Target A"
|
||||
curl http://localhost:8080/service/b # -> weiterhin "Target B"</code></pre>
|
||||
</details>
|
||||
|
||||
<details>
|
||||
<summary><span class="badge easy">Easy</span> 3) Eigene Route /demo/a</summary>
|
||||
<p><span class="kw">Muss:</span> Alias-Route bauen, die auf Backend A fuehrt.</p>
|
||||
<p><span class="kw">Warum wichtig:</span> Der Proxy entkoppelt externe Pfade von internen Backend-Implementierungen.</p>
|
||||
<pre><code>curl http://localhost:8080/demo/a</code></pre>
|
||||
<p><span class="kw">Zielzustand:</span> <code>/demo/a</code> liefert dieselbe Antwort wie <code>/service/a</code>.</p>
|
||||
<pre><code>curl http://localhost:8080/demo/a # -> "Target A"</code></pre>
|
||||
</details>
|
||||
</section>
|
||||
|
||||
@@ -226,7 +235,9 @@ curl http://localhost:8080/service/b</code></pre>
|
||||
<p>Setze mindestens <code>nosniff</code>, <code>DENY</code>, <code>strict-origin-when-cross-origin</code>, <code>Permissions-Policy</code>, <code>COOP</code>, <code>CORP</code>.</p>
|
||||
<p><span class="kw">Optional:</span> CSP fuer statische Seiten.</p>
|
||||
<p><span class="kw">Warum wichtig:</span> Diese Header reduzieren konkrete Browser-Angriffsvektoren und gehoeren zur Security-Baseline.</p>
|
||||
<pre><code>curl -I http://localhost:8080/</code></pre>
|
||||
<p><span class="kw">Fallstrick:</span> Header im <code>server {}</code>-Block setzen. Sobald in einem <code>location {}</code> ein <code>add_header</code> steht, verwirft Nginx dort <b>alle</b> Server-Header → dann erneut setzen.</p>
|
||||
<p><span class="kw">Zielzustand:</span> <code>curl -I /</code> zeigt alle geforderten Security-Header.</p>
|
||||
<pre><code>curl -I http://localhost:8080/ # -> nosniff, DENY, Referrer-Policy, Permissions-Policy, COOP, CORP</code></pre>
|
||||
</details>
|
||||
|
||||
<details>
|
||||
@@ -234,25 +245,29 @@ curl http://localhost:8080/service/b</code></pre>
|
||||
<p><span class="kw">Muss:</span> <code>/internal/status</code> nur fuer <code>127.0.0.1</code>.</p>
|
||||
<p><span class="kw">Wichtig:</span> Host-Request zeigt typischerweise 403 (Docker-Netzwerk).</p>
|
||||
<p><span class="kw">Warum wichtig:</span> Nicht jeder Endpoint darf oeffentlich erreichbar sein; Netzsegmentierung beginnt oft am Proxy.</p>
|
||||
<pre><code>curl -i http://localhost:8080/internal/status
|
||||
./scripts/compose.sh exec -T reverse-proxy sh -lc "wget -qO- http://127.0.0.1/internal/status"</code></pre>
|
||||
<p><span class="kw">Zielzustand:</span> Host → 403; container-intern (127.0.0.1) → Antwort.</p>
|
||||
<pre><code>curl -i http://localhost:8080/internal/status # -> 403 (vom Host)
|
||||
./scripts/compose.sh exec -T reverse-proxy sh -lc "wget -qO- http://127.0.0.1/internal/status" # -> "internal ok"</code></pre>
|
||||
</details>
|
||||
|
||||
<details>
|
||||
<summary><span class="badge medium">Medium</span> 6) Logging verbessern</summary>
|
||||
<p>Eigenes <code>log_format</code> mit Upstream-Infos einbauen.</p>
|
||||
<p><span class="kw">Hinweis:</span> <code>log_format</code> gehoert in den <code>http {}</code>-Block, sonst startet Nginx nicht.</p>
|
||||
<p><span class="kw">Warum wichtig:</span> Ohne brauchbare Logs dauert Fehleranalyse deutlich laenger und Incident-Response wird unzuverlaessig.</p>
|
||||
<p><span class="kw">Zielzustand:</span> Log-Zeile im neuen Format mit Upstream-Infos (<code>upstream=...</code>, <code>urt=...</code>).</p>
|
||||
<pre><code>curl http://localhost:8080/service/a
|
||||
./scripts/compose.sh logs reverse-proxy</code></pre>
|
||||
./scripts/compose.sh logs reverse-proxy # -> neue Zeile mit upstream=... urt=...</code></pre>
|
||||
</details>
|
||||
|
||||
<details>
|
||||
<summary><span class="badge medium">Medium</span> 7) Load Balancing</summary>
|
||||
<p>Zweite Instanz von Backend A (<code>backend-a2</code>) einbauen und Round-Robin zeigen.</p>
|
||||
<p><span class="kw">Warum wichtig:</span> Lastverteilung ist Kernnutzen eines Reverse Proxys fuer Skalierung und Verfuegbarkeit.</p>
|
||||
<p><span class="kw">Zielzustand:</span> Ueber mehrere Requests antworten <b>beide</b> Instanzen (Mischung aus A und A2).</p>
|
||||
<pre><code>for i in $(seq 1 8); do
|
||||
curl -s http://localhost:8080/service/a | grep -o "Target A2\|Target A"
|
||||
done</code></pre>
|
||||
curl -s http://localhost:8080/service/a | grep -o "INSTANCE=[A-Za-z0-9]*"
|
||||
done # -> Mischung aus "INSTANCE=A" und "INSTANCE=A2"</code></pre>
|
||||
</details>
|
||||
|
||||
<details>
|
||||
@@ -260,16 +275,19 @@ done</code></pre>
|
||||
<p>Mindestens einen Backend-Response-Header per <code>proxy_hide_header</code> ausblenden.</p>
|
||||
<p><span class="kw">Abgrenzung zu #4:</span> #4 setzt Schutz-Header, #8 entfernt unnoetige Header aus Upstream-Responses.</p>
|
||||
<p><span class="kw">Warum wichtig:</span> Weniger preisgegebene Metadaten erschweren Fingerprinting und zielgerichtete Angriffe.</p>
|
||||
<pre><code>curl -I http://localhost:8080/service/a</code></pre>
|
||||
<p><span class="kw">Zielzustand:</span> Der ausgeblendete Header (z. B. <code>ETag</code>) fehlt jetzt in der Antwort.</p>
|
||||
<pre><code>curl -I http://localhost:8080/service/a # -> ETag/Last-Modified nicht mehr vorhanden</code></pre>
|
||||
</details>
|
||||
|
||||
<details>
|
||||
<summary><span class="badge medium">Medium</span> 9) Debugging Challenge</summary>
|
||||
<p>Mit <code>proxy/nginx.broken.conf</code> arbeiten, Fehler finden und reparieren.</p>
|
||||
<p><span class="kw">Zuerst sichern:</span> diese Challenge ueberschreibt deine <code>nginx.conf</code> → vorher <code>cp proxy/nginx.conf proxy/nginx.conf.bak</code>, am Ende zurueckkopieren.</p>
|
||||
<p><span class="kw">Warum wichtig:</span> In der Praxis geht es oft um Diagnose unter Zeitdruck, nicht nur um Greenfield-Konfiguration.</p>
|
||||
<p><span class="kw">Typische Fehler in der kaputten Datei:</span> Upstream-Name-Mismatch, falscher Port, fehlender Trailing Slash in <code>proxy_pass</code>.</p>
|
||||
<pre><code>curl http://localhost:8080/service/a
|
||||
curl http://localhost:8080/service/b
|
||||
<p><span class="kw">Zielzustand:</span> Nach den Fixes liefern A und B wieder ihre Backends; Nginx startet fehlerfrei.</p>
|
||||
<pre><code>curl http://localhost:8080/service/a # -> "Target A"
|
||||
curl http://localhost:8080/service/b # -> "Target B"
|
||||
./scripts/compose.sh logs reverse-proxy</code></pre>
|
||||
</details>
|
||||
</section>
|
||||
@@ -280,22 +298,27 @@ curl http://localhost:8080/service/b
|
||||
<details>
|
||||
<summary><span class="badge hard">Hard</span> 10) HTTPS von 0 (Easy-RSA)</summary>
|
||||
<p>Zertifikat fuer <code>localhost</code>, Port <code>8443:443</code>, Root-CA importiert.</p>
|
||||
<p><span class="kw">Wichtig:</span> Der neue Port ist eine Compose-Aenderung → mit <code>./scripts/lab.sh redeploy</code> deployen, nicht nur <code>./scripts/lab.sh proxy-reload</code>.</p>
|
||||
<p><span class="kw">Warum wichtig:</span> TLS-Grundaufbau ist Voraussetzung fuer vertrauliche und manipulationssichere Kommunikation.</p>
|
||||
<pre><code>curl https://localhost:8443/service/a</code></pre>
|
||||
<p><span class="kw">Zielzustand:</span> Aufruf liefert Backend A <b>ohne</b> <code>-k</code> (kein SAN-/Zertifikatsfehler). Zertifikat mit SAN signieren!</p>
|
||||
<pre><code>curl https://localhost:8443/service/a # -> Backend A, KEIN "SSL certificate problem"</code></pre>
|
||||
</details>
|
||||
|
||||
<details>
|
||||
<summary><span class="badge hard">Hard</span> 11) HTTP -> HTTPS Redirect</summary>
|
||||
<p><span class="kw">Voraussetzung:</span> Challenge 10 abgeschlossen. Bestehende Config weiterverwenden.</p>
|
||||
<p><span class="kw">Warum wichtig:</span> Redirect verhindert unabsichtliche Klartext-Nutzung und erzwingt den sicheren Transport.</p>
|
||||
<pre><code>curl -I http://localhost:8080/service/a</code></pre>
|
||||
<p><span class="kw">Zielzustand:</span> HTTP auf <code>8080</code> antwortet mit <code>301</code> und <code>Location: https://localhost:8443/...</code>.</p>
|
||||
<pre><code>curl -I http://localhost:8080/service/a # -> 301, Location: https://localhost:8443/service/a</code></pre>
|
||||
</details>
|
||||
|
||||
<details>
|
||||
<summary><span class="badge hard">Hard</span> 12) TLS Haertung + Chain + HSTS</summary>
|
||||
<p><span class="kw">Voraussetzung:</span> Challenge 10 und 11 abgeschlossen. Gleiche Config weiter erweitern.</p>
|
||||
<p><span class="kw">Warum wichtig:</span> Erst Haertung + HSTS reduzieren Downgrade-Risiken und sorgen fuer dauerhaft sichere Clients.</p>
|
||||
<pre><code>curl -I https://localhost:8443/service/a
|
||||
<p><span class="kw">Warnung (HSTS-Falle):</span> Der Browser merkt sich HSTS host-weit fuer <code>localhost</code> (nicht pro Port). Nach <code>https://localhost:8443</code> wird auch <code>http://localhost:8080</code> auf https erzwungen. Zum Testen <code>curl</code> nutzen; Browser-HSTS ggf. unter <code>chrome://net-internals/#hsts</code> fuer <code>localhost</code> loeschen. <code>max-age</code> ist im Lab bewusst kurz (1h).</p>
|
||||
<p><span class="kw">Zielzustand:</span> <code>curl -I</code> zeigt <code>Strict-Transport-Security</code>; <code>s_client</code> verhandelt TLSv1.2/1.3 mit <code>Verify return code: 0 (ok)</code>.</p>
|
||||
<pre><code>curl -I https://localhost:8443/service/a # -> enthaelt Strict-Transport-Security
|
||||
openssl s_client -connect localhost:8443 -servername localhost</code></pre>
|
||||
</details>
|
||||
</section>
|
||||
@@ -313,6 +336,7 @@ openssl s_client -connect localhost:8443 -servername localhost</code></pre>
|
||||
<li>3-5 Bulletpoints: was ist sichtbar, was ist geschuetzt?</li>
|
||||
</ol>
|
||||
<p><span class="kw">Optional:</span> TLS Decrypt mit <code>SSLKEYLOGFILE</code>.</p>
|
||||
<p><span class="kw">Zielzustand:</span> HTTP-Mitschnitt zeigt Pfad/Header im Klartext; HTTPS zeigt nur den Handshake, Nutzdaten ohne Key nicht lesbar.</p>
|
||||
<p><span class="kw">Abgabe:</span> mind. 3 Screenshots + technische Interpretation.</p>
|
||||
</details>
|
||||
</section>
|
||||
|
||||
@@ -149,14 +149,14 @@
|
||||
</article>
|
||||
<article class="card">
|
||||
<h3>Neu deployen</h3>
|
||||
<pre><code>make redeploy
|
||||
make proxy-reload</code></pre>
|
||||
<pre><code>./scripts/lab.sh redeploy
|
||||
./scripts/lab.sh proxy-reload</code></pre>
|
||||
<p>PowerShell: <code>./scripts/workshop.ps1 -Action redeploy</code></p>
|
||||
</article>
|
||||
<article class="card">
|
||||
<h3>Reset</h3>
|
||||
<pre><code>make reset
|
||||
make bootstrap</code></pre>
|
||||
<pre><code>./scripts/lab.sh reset
|
||||
./scripts/lab.sh bootstrap</code></pre>
|
||||
<p>PowerShell: <code>./scripts/workshop.ps1 -Action reset</code></p>
|
||||
</article>
|
||||
</div>
|
||||
@@ -173,7 +173,7 @@ cd certs/easyrsa
|
||||
./easyrsa init-pki
|
||||
./easyrsa build-ca nopass
|
||||
./easyrsa gen-req localhost nopass
|
||||
./easyrsa sign-req server localhost</code></pre>
|
||||
./easyrsa --subject-alt-name="DNS:localhost,IP:127.0.0.1" sign-req server localhost</code></pre>
|
||||
<p>Nur Runtime-Certs mounten (z. B. <code>certs/live</code>), nicht die komplette PKI.</p>
|
||||
</article>
|
||||
<article class="card">
|
||||
|
||||
@@ -104,7 +104,7 @@
|
||||
<section class="panel">
|
||||
<h1>HTL Reverse Proxy & TLS Lab</h1>
|
||||
<p>
|
||||
Basis läuft mit HTTP. Ziel im Workshop: Reverse Proxy verstehen und HTTPS/TLS manuell
|
||||
Basis laeuft mit HTTP. Ziel im Workshop: Reverse Proxy verstehen und HTTPS/TLS manuell
|
||||
aufbauen.
|
||||
</p>
|
||||
<div class="top-links">
|
||||
@@ -125,6 +125,10 @@
|
||||
<li><code>curl http://localhost:8080/service/b</code></li>
|
||||
<li><code>./scripts/compose.sh ps</code></li>
|
||||
</ul>
|
||||
<p>
|
||||
<b>Windows:</b> Diese Kommandos im <b>WSL-Terminal (bash)</b> ausfuehren, nicht in PowerShell
|
||||
(dort ist <code>curl</code> ein Alias fuer <code>Invoke-WebRequest</code>).
|
||||
</p>
|
||||
</section>
|
||||
|
||||
<section class="panel">
|
||||
|
||||
@@ -165,7 +165,7 @@
|
||||
<section class="panel">
|
||||
<h1>Solutions Board (detailliert)</h1>
|
||||
<p>Hier stehen absichtlich konkrete Musterloesungen mit Snippets, Checks und typischen Stolperfallen.</p>
|
||||
<p><span class="kw">Workflow:</span> Nach jeder Konfig-Aenderung mindestens <code>make proxy-reload</code>, bei Compose-Aenderungen <code>make redeploy</code>.</p>
|
||||
<p><span class="kw">Workflow:</span> Nach jeder Konfig-Aenderung mindestens <code>./scripts/lab.sh proxy-reload</code>, bei Compose-Aenderungen <code>./scripts/lab.sh redeploy</code>.</p>
|
||||
<div class="top-links">
|
||||
<a class="pill" href="/">Startseite</a>
|
||||
<a class="pill" href="/challenges.html">Challenges</a>
|
||||
@@ -215,7 +215,7 @@ location /service/c {
|
||||
</details>
|
||||
|
||||
<details>
|
||||
<summary><span class="badge easy">Easy</span> 3) Rewrite Route</summary>
|
||||
<summary><span class="badge easy">Easy</span> 3) Alias-Route /demo/a</summary>
|
||||
<p><span class="kw">Dateien:</span> <code>proxy/nginx.conf</code></p>
|
||||
<p><span class="kw">Commands noetig:</span> ja</p>
|
||||
<pre><code>location = /demo/a {
|
||||
@@ -238,6 +238,7 @@ add_header Referrer-Policy "strict-origin-when-cross-origin" always;
|
||||
add_header Permissions-Policy "camera=(), microphone=(), geolocation=()" always;
|
||||
add_header Cross-Origin-Opener-Policy "same-origin" always;
|
||||
add_header Cross-Origin-Resource-Policy "same-origin" always;</code></pre>
|
||||
<p><span class="kw">Platzierung:</span> in den <code>server {}</code>-Block, damit alle Locations sie erben. Sobald eine Location ein eigenes <code>add_header</code> hat, verwirft Nginx dort die Server-Header und sie muessen wiederholt werden.</p>
|
||||
<p><span class="kw">Optional CSP (statisch, inline styles erlaubt):</span></p>
|
||||
<pre><code>add_header Content-Security-Policy "default-src 'self'; style-src 'self' 'unsafe-inline'; img-src 'self' data:; object-src 'none'; base-uri 'none'; frame-ancestors 'none'" always;</code></pre>
|
||||
<p><span class="kw">Check:</span> <code>curl -I http://localhost:8080/</code></p>
|
||||
@@ -262,6 +263,7 @@ add_header Cross-Origin-Resource-Policy "same-origin" always;</code></pre>
|
||||
<summary><span class="badge medium">Medium</span> 6) Logging verbessern</summary>
|
||||
<p><span class="kw">Dateien:</span> <code>proxy/nginx.conf</code></p>
|
||||
<p><span class="kw">Commands noetig:</span> ja</p>
|
||||
<p><span class="kw">Platzierung:</span> <code>log_format</code> muss in den <code>http {}</code>-Block (sonst startet Nginx nicht). <code>access_log</code> darf in <code>http</code>, <code>server</code> oder <code>location</code>.</p>
|
||||
<pre><code>log_format workshop '$remote_addr - $request '
|
||||
'status=$status upstream=$upstream_addr '
|
||||
'rt=$request_time urt=$upstream_response_time';
|
||||
@@ -289,8 +291,9 @@ access_log /var/log/nginx/access.log workshop;</code></pre>
|
||||
}</code></pre>
|
||||
<p><span class="kw">Check:</span></p>
|
||||
<pre><code>for i in $(seq 1 8); do
|
||||
curl -s http://localhost:8080/service/a | grep -o "Target A2\|Target A"
|
||||
curl -s http://localhost:8080/service/a | grep -o "INSTANCE=[A-Za-z0-9]*"
|
||||
done</code></pre>
|
||||
<p><span class="kw">Marker:</span> Backend A/A2 enthalten unsichtbar <code><!-- INSTANCE=A --></code> bzw. <code>INSTANCE=A2</code>. <code>[A-Za-z0-9]*</code> matched das ganze Token (kein Prefix-Problem A vs. A2).</p>
|
||||
</details>
|
||||
|
||||
<details>
|
||||
@@ -298,6 +301,7 @@ done</code></pre>
|
||||
<p><span class="kw">Dateien:</span> <code>proxy/nginx.conf</code></p>
|
||||
<p><span class="kw">Commands noetig:</span> ja</p>
|
||||
<p><span class="kw">Abgrenzung zu #4:</span> #4 fuegt Schutz-Header hinzu, #8 entfernt unnoetige Upstream-Metadaten.</p>
|
||||
<p><span class="kw">Gut zu wissen:</span> <code>proxy_hide_header</code> ist kein <code>add_header</code> → es loest die Vererbungsfalle aus #4 nicht aus. Die Server-Header bleiben in dieser Location erhalten.</p>
|
||||
<pre><code>location /service/a {
|
||||
proxy_pass http://backend_a/;
|
||||
proxy_hide_header ETag;
|
||||
@@ -310,10 +314,14 @@ done</code></pre>
|
||||
<summary><span class="badge medium">Medium</span> 9) Debugging Challenge</summary>
|
||||
<p><span class="kw">Dateien:</span> <code>proxy/nginx.broken.conf</code>, <code>proxy/nginx.conf</code></p>
|
||||
<p><span class="kw">Commands noetig:</span> ja</p>
|
||||
<p><span class="kw">Ablauf:</span> Kopiere testweise <code>proxy/nginx.broken.conf</code> auf <code>proxy/nginx.conf</code>, behebe die Fehler und stelle danach die funktionierende Konfiguration wieder her.</p>
|
||||
<pre><code>cp proxy/nginx.broken.conf proxy/nginx.conf
|
||||
make proxy-reload
|
||||
./scripts/compose.sh logs reverse-proxy</code></pre>
|
||||
<p><span class="kw">Ablauf:</span> Zuerst die eigene Config sichern (diese Challenge ueberschreibt sie!), dann die kaputte aktivieren, Fehler beheben und am Ende die eigene Config wiederherstellen.</p>
|
||||
<pre><code>cp proxy/nginx.conf proxy/nginx.conf.bak # 1. eigene Config sichern
|
||||
cp proxy/nginx.broken.conf proxy/nginx.conf # 2. kaputte aktivieren
|
||||
./scripts/lab.sh proxy-reload
|
||||
./scripts/compose.sh logs reverse-proxy # 3. Fehler finden + fixen</code></pre>
|
||||
<p><span class="kw">Am Ende eigene Config zurueck:</span></p>
|
||||
<pre><code>cp proxy/nginx.conf.bak proxy/nginx.conf
|
||||
./scripts/lab.sh proxy-reload</code></pre>
|
||||
<p><span class="kw">Konkrete Fehler und Fixes:</span></p>
|
||||
<ol>
|
||||
<li><span class="kw">Upstream-Mismatch:</span> <code>backend_a_typo</code> ist definiert, aber <code>backend_a</code> wird referenziert -> Namen angleichen.</li>
|
||||
@@ -340,7 +348,7 @@ cd certs/easyrsa
|
||||
./easyrsa init-pki
|
||||
./easyrsa build-ca nopass
|
||||
./easyrsa gen-req localhost nopass
|
||||
./easyrsa sign-req server localhost</code></pre>
|
||||
./easyrsa --subject-alt-name="DNS:localhost,IP:127.0.0.1" sign-req server localhost</code></pre>
|
||||
<p><span class="kw">Compose:</span></p>
|
||||
<pre><code>reverse-proxy:
|
||||
ports:
|
||||
@@ -349,6 +357,7 @@ cd certs/easyrsa
|
||||
volumes:
|
||||
- ./certs/live:/etc/nginx/certs:ro,z</code></pre>
|
||||
<p><span class="kw">Wichtig:</span> Nicht die komplette PKI in den Container mounten. Nur Runtime-Zertifikat + Key bereitstellen.</p>
|
||||
<p><span class="kw">Deploy:</span> Port- und Volume-Aenderungen sind Compose-Aenderungen → <code>./scripts/lab.sh redeploy</code> (nicht <code>./scripts/lab.sh proxy-reload</code>), sonst greift der neue Port nicht.</p>
|
||||
<p><span class="kw">Nginx TLS-Pfade:</span> <code>ssl_certificate /etc/nginx/certs/localhost.crt;</code> und <code>ssl_certificate_key /etc/nginx/certs/localhost.key;</code></p>
|
||||
<p><span class="kw">Check:</span> <code>curl https://localhost:8443/service/a</code> (ohne <code>-k</code> nach CA-Import)</p>
|
||||
</details>
|
||||
@@ -381,7 +390,7 @@ cd certs/easyrsa
|
||||
<p><span class="kw">Commands noetig:</span> ja</p>
|
||||
<pre><code>ssl_protocols TLSv1.2 TLSv1.3;
|
||||
ssl_prefer_server_ciphers on;
|
||||
add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;</code></pre>
|
||||
add_header Strict-Transport-Security "max-age=3600; includeSubDomains" always;</code></pre>
|
||||
<p><span class="kw">Check:</span></p>
|
||||
<pre><code>curl -I https://localhost:8443/service/a
|
||||
openssl s_client -connect localhost:8443 -servername localhost</code></pre>
|
||||
|
||||
@@ -39,7 +39,10 @@ http {
|
||||
ssl_protocols TLSv1.2 TLSv1.3;
|
||||
ssl_prefer_server_ciphers on;
|
||||
|
||||
add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;
|
||||
# max-age im Lab bewusst kurz (1h). In Produktion eher 1 Jahr (31536000).
|
||||
# includeSubDomains weitet HSTS auf alle Subdomains aus (Produktions-Best-Practice).
|
||||
# Achtung: HSTS bleibt im Browser host-weit haengen -> siehe Warnhinweis in Challenge 12.
|
||||
add_header Strict-Transport-Security "max-age=3600; includeSubDomains" always;
|
||||
add_header X-Content-Type-Options "nosniff" always;
|
||||
add_header X-Frame-Options "DENY" always;
|
||||
add_header Referrer-Policy "strict-origin-when-cross-origin" always;
|
||||
|
||||
@@ -1,36 +0,0 @@
|
||||
#!/usr/bin/env bash
|
||||
set -euo pipefail
|
||||
|
||||
SCRIPT_DIR="$(cd -- "$(dirname -- "${BASH_SOURCE[0]}")" && pwd)"
|
||||
PROJECT_ROOT="$(cd -- "$SCRIPT_DIR/.." && pwd)"
|
||||
|
||||
cd "$PROJECT_ROOT"
|
||||
|
||||
if ! command -v docker >/dev/null 2>&1; then
|
||||
echo "[error] docker nicht gefunden. Bitte Docker installieren (Linux/macOS) oder Docker Desktop + WSL Integration aktivieren."
|
||||
exit 1
|
||||
fi
|
||||
|
||||
if ! docker info >/dev/null 2>&1; then
|
||||
echo "[error] Docker Daemon nicht erreichbar. Bitte Docker starten."
|
||||
exit 1
|
||||
fi
|
||||
|
||||
if ! "$SCRIPT_DIR/compose.sh" version >/dev/null 2>&1; then
|
||||
echo "[error] Weder docker compose noch docker-compose verfuegbar."
|
||||
exit 1
|
||||
fi
|
||||
|
||||
if [[ ! -f .env ]]; then
|
||||
cp .env.example .env
|
||||
echo "[ok] .env aus .env.example erstellt"
|
||||
else
|
||||
echo "[skip] .env existiert bereits"
|
||||
fi
|
||||
|
||||
"$SCRIPT_DIR/compose.sh" up -d --build
|
||||
|
||||
echo
|
||||
echo "[ok] Workshop-Stack laeuft"
|
||||
echo " Landing Page: http://localhost:8080"
|
||||
echo " Test (backend-a): curl http://localhost:8080/service/a"
|
||||
@@ -1,6 +0,0 @@
|
||||
#!/usr/bin/env bash
|
||||
set -euo pipefail
|
||||
|
||||
SCRIPT_DIR="$(cd -- "$(dirname -- "${BASH_SOURCE[0]}")" && pwd)"
|
||||
echo "[warn] scripts/bootstrap-wsl.sh ist deprecated. Nutze bitte scripts/bootstrap.sh"
|
||||
"$SCRIPT_DIR/bootstrap-unix.sh"
|
||||
+25
-1
@@ -2,4 +2,28 @@
|
||||
set -euo pipefail
|
||||
|
||||
SCRIPT_DIR="$(cd -- "$(dirname -- "${BASH_SOURCE[0]}")" && pwd)"
|
||||
"$SCRIPT_DIR/bootstrap-unix.sh"
|
||||
PROJECT_ROOT="$(cd -- "$SCRIPT_DIR/.." && pwd)"
|
||||
|
||||
cd "$PROJECT_ROOT"
|
||||
|
||||
if ! command -v docker >/dev/null 2>&1; then
|
||||
echo "[error] docker nicht gefunden. Bitte Docker installieren (Linux/macOS) oder Docker Desktop + WSL Integration aktivieren."
|
||||
exit 1
|
||||
fi
|
||||
|
||||
if ! docker info >/dev/null 2>&1; then
|
||||
echo "[error] Docker Daemon nicht erreichbar. Bitte Docker starten."
|
||||
exit 1
|
||||
fi
|
||||
|
||||
if ! "$SCRIPT_DIR/compose.sh" version >/dev/null 2>&1; then
|
||||
echo "[error] Weder docker compose noch docker-compose verfuegbar."
|
||||
exit 1
|
||||
fi
|
||||
|
||||
"$SCRIPT_DIR/compose.sh" up -d --build
|
||||
|
||||
echo
|
||||
echo "[ok] Workshop-Stack laeuft"
|
||||
echo " Landing Page: http://localhost:8080"
|
||||
echo " Test (backend-a): curl http://localhost:8080/service/a"
|
||||
|
||||
Executable
+27
@@ -0,0 +1,27 @@
|
||||
#!/usr/bin/env bash
|
||||
set -euo pipefail
|
||||
|
||||
# Zentrale Steuer-Oberflaeche fuer den Workshop-Stack.
|
||||
# Eine einzige Quelle der Wahrheit fuer alle Aktionen - der PowerShell-Wrapper
|
||||
# (scripts/workshop.ps1) ruft genau dieses Skript in WSL auf.
|
||||
|
||||
SCRIPT_DIR="$(cd -- "$(dirname -- "${BASH_SOURCE[0]}")" && pwd)"
|
||||
|
||||
usage() {
|
||||
echo "usage: lab.sh {bootstrap|up|redeploy|proxy-reload|down|logs|reset|reset-hard|reset-origin}"
|
||||
}
|
||||
|
||||
case "${1:-}" in
|
||||
bootstrap) "$SCRIPT_DIR/bootstrap.sh" ;;
|
||||
up) "$SCRIPT_DIR/compose.sh" up -d --build ;;
|
||||
redeploy) "$SCRIPT_DIR/compose.sh" up -d --build --remove-orphans
|
||||
"$SCRIPT_DIR/compose.sh" restart reverse-proxy ;;
|
||||
proxy-reload) "$SCRIPT_DIR/compose.sh" restart reverse-proxy ;;
|
||||
down) "$SCRIPT_DIR/compose.sh" down ;;
|
||||
logs) "$SCRIPT_DIR/compose.sh" logs -f ;;
|
||||
reset) "$SCRIPT_DIR/reset-lab.sh" ;;
|
||||
reset-hard) "$SCRIPT_DIR/reset-lab.sh" --hard ;;
|
||||
reset-origin) "$SCRIPT_DIR/reset-lab.sh" --hard-origin ;;
|
||||
-h|--help|"") usage ;;
|
||||
*) echo "[error] unbekannte Aktion: $1"; usage; exit 2 ;;
|
||||
esac
|
||||
+1
-11
@@ -18,17 +18,7 @@ if (-not $repoWslPath) {
|
||||
exit 1
|
||||
}
|
||||
|
||||
switch ($Action) {
|
||||
"bootstrap" { $linuxCommand = "./scripts/bootstrap.sh" }
|
||||
"up" { $linuxCommand = "./scripts/compose.sh up -d --build" }
|
||||
"redeploy" { $linuxCommand = "./scripts/compose.sh up -d --build --remove-orphans && ./scripts/compose.sh restart reverse-proxy" }
|
||||
"proxy-reload" { $linuxCommand = "./scripts/compose.sh restart reverse-proxy" }
|
||||
"down" { $linuxCommand = "./scripts/compose.sh down" }
|
||||
"logs" { $linuxCommand = "./scripts/compose.sh logs -f" }
|
||||
"reset" { $linuxCommand = "./scripts/reset-lab.sh" }
|
||||
"reset-hard" { $linuxCommand = "./scripts/reset-lab.sh --hard" }
|
||||
"reset-origin" { $linuxCommand = "./scripts/reset-lab.sh --hard-origin" }
|
||||
}
|
||||
$linuxCommand = "./scripts/lab.sh $Action"
|
||||
|
||||
$wslArgs = @()
|
||||
if ($Distro) {
|
||||
|
||||
Reference in New Issue
Block a user