Files

Carsten Rüthel 131ad11b09 initialer Commit

2026-04-01 23:41:02 +02:00

9.3 KiB

Raw Blame History

Aufgabenstellung

ich betreibe verschiedene Dienste auf einen Raspberry Pi hinter einem Caddy, ein Teil der Dienste wird mit Portainer verwaltet. Jetzt möchte ich noch ein nodeRED hinzufügen und quasi öffentlich zugänglich machen. Wie kann ich den Zugang auf ausgewählte Benutzer beschränken und auch die Dienste nur für diese zugänglich machen?

Du hast im Prinzip zwei saubere Ebenen, auf denen du Zugriff beschränken kannst:

Reverse Proxy (Caddy) → zentrale Zugangskontrolle
Applikation selbst (Node-RED, Portainer etc.) → zusätzliche Absicherung

Die robuste Lösung kombiniert beide.

🔐 1. Zugriff zentral über Caddy absichern (empfohlen)

Da du bereits Caddy nutzt, ist das der beste Ort für Authentifizierung.

Option A: Basic Auth (einfach & effektiv)

Beispiel für deine Caddyfile:

nodered.example.com {
    reverse_proxy localhost:1880

    basicauth {
        user1 JDJhJDE0JHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHg
    }
}

Hash erzeugen mit:

caddy hash-password

👉 Vorteil:

Schnell eingerichtet
Schützt ALLE dahinterliegenden Dienste sofort

👉 Nachteil:

Nur Benutzer/Passwort, kein Feingranularität

Option B: Forward Auth (professionell / skalierbar)

Hier lagerst du Authentifizierung an einen Dienst aus, z. B.:

Authelia
Authentik

Caddy-Konfiguration (Beispiel mit Forward Auth):

nodered.example.com {
    route {
        forward_auth authelia:9091 {
            uri /api/verify?rd=https://login.example.com
            copy_headers Remote-User Remote-Groups
        }
        reverse_proxy localhost:1880
    }
}

👉 Vorteil:

Benutzerverwaltung
2FA möglich
Zugriff nach Gruppen steuerbar (z. B. nur „admin“ darf Node-RED)

👉 Das ist die beste Lösung, wenn du mehrere Dienste öffentlich machst.

🔐 2. Node-RED selbst absichern

Zusätzlich solltest du Node-RED selbst schützen.

In settings.js:

adminAuth: {
    type: "credentials",
    users: [{
        username: "admin",
        password: "$2b$08$hash...",
        permissions: "*"
    }]
}

Passwort-Hash erzeugen mit:

node-red admin hash-pw

👉 Wichtig:

Das schützt den Editor (/)
Nicht automatisch alle HTTP-In-Nodes!

🔐 3. Zugriff auf Flows / APIs absichern

Wenn du HTTP-Endpunkte in Node-RED nutzt:

Variante A: Token / API-Key im Flow prüfen

Typischer Flow:

HTTP In
Function (Token prüfen)
HTTP Response

Variante B: Zugriff komplett über Caddy regeln

👉 Besser: alle Endpoints durch den Proxy schützen

🔐 4. Netzwerk-Ebene (sehr empfehlenswert)

Zusätzlich:

Nur intern laufen lassen

Node-RED auf localhost:1880
Kein direkter Port nach außen

Docker (falls über Portainer)

Mit Portainer:

Kein ports: Mapping nach außen
Nur über Caddy erreichbar

🔐 5. Best Practice Architektur

So sollte dein Setup aussehen:

Internet
   ↓
Caddy (TLS + Auth)
   ↓
[Authelia / Authentik] (optional, empfohlen)
   ↓
Node-RED / Portainer / andere Dienste
   (nur intern erreichbar)

🔒 Konkrete Empfehlung für dich

Wenn du „ausgewählte Benutzer“ willst:

👉 Minimal:

Caddy + BasicAuth

👉 Sauber & zukunftssicher:

Caddy + Authelia
Gruppen definieren:
- user → Zugriff auf Node-RED
- admin → Zugriff auf Portainer

👉 Zusätzlich:

Node-RED adminAuth aktivieren

⚠️ Häufige Fehler

❌ Node-RED direkt ins Internet exposen
❌ Nur Node-RED Auth nutzen (leicht zu umgehen bei APIs)
❌ Ports in Docker offen lassen
❌ Kein HTTPS (Caddy löst das aber für dich)

Wenn du willst, kann ich dir eine konkrete Caddyfile + Authelia docker-compose für dein Setup bauen (inkl. Portainer + Node-RED sauber getrennt).

Erkläre und zeige Beispiele für Authelia bzw. Authentik

Ja — das ist problemlos möglich. Authelia läuft sauber unter Docker auf Windows und eignet sich gut zum Testen, bevor du es auf deinen Raspberry Pi bringst.

Ich zeige dir eine minimal lauffähige Testumgebung, die du lokal aufsetzen kannst.

🧰 Voraussetzungen

Docker Desktop installiert
WSL2 aktiviert (Standard bei neueren Setups)

🚀 1. Projektstruktur

Erstelle einen Ordner, z. B.:

authelia-test/
├── docker-compose.yml
└── config/
    ├── configuration.yml
    └── users_database.yml

📦 2. docker-compose.yml

version: "3.8"

services:
  authelia:
    image: authelia/authelia
    container_name: authelia
    volumes:
      - ./config:/config
    ports:
      - 9091:9091
    restart: unless-stopped

👉 Danach starten mit:

docker compose up -d

⚙️ 3. Minimal-Konfiguration

`config/configuration.yml`

server:
  address: tcp://0.0.0.0:9091

authentication_backend:
  file:
    path: /config/users_database.yml

access_control:
  default_policy: deny
  rules:
    - domain: "localhost"
      policy: one_factor

session:
  secret: "insecure_test_secret"
  cookies:
    - domain: "localhost"
      authelia_url: "http://localhost:9091"

storage:
  local:
    path: /config/db.sqlite3

notifier:
  filesystem:
    filename: /config/notification.txt

👤 `users_database.yml`

users:
  testuser:
    password: "$2y$05$replace_with_hash"
    groups:
      - users

🔑 4. Passwort erzeugen

Im Terminal:

docker run --rm authelia/authelia authelia crypto hash generate argon2 --password "MeinSicheresPasswort"

liefert

Digest: $argon2id$v=19$m=65536,t=3,p=4$c87AqKINtBkJ6ajQiIiz5A$e27srHc5hnPlT0unJyFoYNg6pTf2CxuLK4WqQMC8cYI

👉 Hash in die Datei einfügen, d.h. alles beginnend mit $argon...

🌐 5. Test im Browser

Öffne:

http://localhost:9091

👉 Du solltest das Authelia-Login sehen

🔄 Optional: Dummy-Service zum Absichern

Wenn du das echte Verhalten testen willst, ergänze z. B.:

whoami:
  image: traefik/whoami
  container_name: whoami
  ports:
    - 8080:80

Dann später mit Reverse Proxy kombinieren.

⚠️ Wichtige Unterschiede zu deinem Pi-Setup

Auf Windows fehlt dir erstmal:

❌ echtes HTTPS (Caddy später!)
❌ echte Domains
❌ ForwardAuth Integration

👉 Das hier ist nur zum Verstehen & Testen der Auth-Logik

🧪 Typische Tests, die du machen kannst

Login funktioniert?
Benutzer/Gruppen greifen?
Zugriff verweigert bei falschem User?
Config-Änderungen live nachvollziehen

🧭 Fazit

✔ Ja, ideal zum Einstieg ✔ Läuft stabil unter Docker Desktop ✔ Perfekt zum Experimentieren mit Policies

👉 Für dein finales Setup (Pi + Caddy) musst du dann nur noch:

Domains anpassen
ForwardAuth aktivieren

Wenn du willst, kann ich dir als nächsten Schritt eine 1:1 übertragbare Konfiguration von Windows → Raspberry Pi bauen, damit du nichts doppelt machen musst.

Erkläre Schritt 4

Schritt 4 ist zentral, weil Authelia keine Klartext-Passwörter akzeptiert. Stattdessen erwartet es stark gehashte Passwörter (Argon2) in der Benutzerdatei.

Ich erkläre dir das präzise:

🔐 Was passiert in Schritt 4?

Du erzeugst einen sicheren Passwort-Hash, der dann in users_database.yml gespeichert wird.

👉 Authelia vergleicht später:

eingegebenes Passwort
mit diesem Hash

→ ohne das Passwort jemals im Klartext zu speichern

⚙️ Der Befehl im Detail

docker run --rm authelia/authelia authelia crypto hash generate argon2

Zerlegt:

docker run --rm → startet temporär einen Container und löscht ihn danach wieder
authelia/authelia → offizielles Image
authelia crypto hash generate argon2 → internes CLI-Tool von Authelia zur Hash-Erzeugung

🧪 Ablauf beim Ausführen

Nach dem Start wirst du interaktiv gefragt:

Enter password:
Confirm password:

👉 Du gibst dein gewünschtes Passwort ein (z. B. meinGeheimesPasswort)

📦 Ergebnis

Du bekommst eine Ausgabe wie:

$argon2id$v=19$m=65536,t=3,p=4$...

Das ist dein Hash.

🧾 Verwendung in `users_database.yml`

Vorher:

testuser:
  password: "$2y$05$replace_with_hash"

Nachher:

testuser:
  password: "$argon2id$v=19$m=65536,t=3,p=4$..."