Portainer sicher konfigurieren: Zugriff, HTTPS, Konten, Firewall

Kurz gesagt: Erreichbar sein sollte Portainer nur im LAN oder über ein VPN, nie direkt aus dem Internet. Binde Port 9443 an eine konkrete IP-Adresse, weil Docker ufw und firewalld umgeht, lass Port 9000 unveröffentlicht und Port 8000 weg, solange du keine Edge Agents nutzt. Gib dem Admin-Konto einen eigenen Namen und ein langes Passwort, verkürze bei Bedarf die Sitzungsdauer und ersetze das selbstsignierte Zertifikat, sobald du Portainer regelmäßig nutzt.

Nach der Installation läuft Portainer mit brauchbaren Voreinstellungen: Setup-Token, Mindestlänge für Passwörter, HTTPS mit selbstsigniertem Zertifikat. Das reicht für den ersten Login, aber nicht für den Dauerbetrieb. Dieser Guide geht die Stellschrauben in der Reihenfolge durch, in der sie wirken: zuerst, wer Portainer überhaupt erreicht, dann, wer sich anmelden darf, und zuletzt, was angemeldete Benutzer tun dürfen.

Voraussetzungen #

• Portainer CE läuft, wie in Portainer installieren beschrieben, per Compose-Datei in /opt/portainer.
• Du bist als Administrator angemeldet und hast SSH-Zugriff auf den Host.
• Grundbegriffe wie Port, IP-Adresse und Firewall sind dir vertraut.

Lernziel: Du kannst begründen, über welchen Weg Portainer bei dir erreichbar ist, und hast Konten, Zertifikat, Ports und Firewall passend dazu eingestellt.

Warum Portainer besonders schützenswert ist #

Portainer bekommt den Docker-Socket /var/run/docker.sock hineingereicht. Über diese Datei nimmt die Docker Engine Befehle entgegen, und wer sie bedienen kann, startet beliebige Container, auch solche mit dem kompletten Dateisystem des Hosts. Ein Portainer-Admin hat damit faktisch Root-Rechte auf dem Server. Jede Schwäche bei Erreichbarkeit oder Anmeldung ist deshalb eine Schwäche des ganzen Hosts. Wie du das Socket-Risiko selbst begrenzt, ist Thema von Docker und Portainer absichern.

Portainer beschreibt seine Sicherheit selbst als geteilte Verantwortung. Portainer setzt seine Rechteprüfung durch. Ob die Oberfläche aus dem Internet erreichbar ist und welche Einstellungen offen bleiben, entscheidest du.

Zugriffsweg festlegen: LAN, VPN oder öffentlich #

Die wichtigste Entscheidung fällt vor jeder Einstellung in Portainer: Von wo aus soll die Weboberfläche erreichbar sein?

Nur LAN ist der einfachste und sicherste Fall. Noch besser ist ein eigenes Netzsegment für Verwaltungsoberflächen, etwa ein VLAN (ein logisch getrenntes Teilnetz), in dem nur deine Admin-Geräte hängen. Wie das geht, zeigt VLANs in OPNsense einrichten.

VPN heißt: Dein Laptop oder Smartphone baut von unterwegs einen verschlüsselten Tunnel ins Heimnetz auf und verhält sich danach, als wäre es im LAN. Portainer selbst bleibt dabei unsichtbar für das Internet, offen ist nur der VPN-Zugang. Welche Lösung passt, vergleicht Tailscale vs. WireGuard.

Öffentlich bedeutet, dass jeder im Internet die Anmeldeseite sieht und Passwörter durchprobieren kann. Die Portainer-Doku zählt fehlendes HTTPS, fehlenden Reverse Proxy oder fehlendes VPN und zu lange Sitzungen ausdrücklich zu den Risiken, für die der Betreiber verantwortlich ist. Wenn du Portainer trotzdem öffentlich brauchst, dann nur mit allen drei Schichten:

1. ein Reverse Proxy (ein vorgeschalteter Webserver, der HTTPS übernimmt und Anfragen weiterreicht) mit gültigem Zertifikat,
2. eine zusätzliche Schutzschicht vor der Portainer-Anmeldung, etwa eine Freigabeliste für bekannte IP-Adressen oder eine vorgeschaltete Anmeldung am Proxy,
3. ein starkes Admin-Passwort und kurze Sitzungsdauer.

Den Aufbau mit Nginx Proxy Manager oder Traefik zeigt Portainer hinter einem Reverse Proxy. Für entfernte Server, etwa einen gemieteten VPS, ist oft der Edge Agent die bessere Wahl: Der entfernte Host baut die Verbindung selbst auf und braucht keinen eingehenden Port. Dafür muss umgekehrt dein Portainer-Server für den VPS auf 9443 und 8000 erreichbar sein, also über ein VPN oder mit einer bewusst abgesicherten Freigabe. Die Abwägung steht in Portainer mit mehreren Servern.

Ports bewusst veröffentlichen #

Portainer nutzt bis zu drei Ports. Die offizielle Compose-Datei veröffentlicht 9443 und 8000, Port 9000 nicht. Im Test mit Portainer CE 2.45.2 lauschte Port 9000 im Container trotzdem: Vom Host aus war er nicht erreichbar, aus demselben Docker-Netzwerk heraus über die Container-IP aber schon. Für einen Reverse Proxy im selben Docker-Netzwerk ist genau das nützlich, für alle anderen ist es nur eine Erinnerung, Port 9000 nicht nachträglich zu veröffentlichen.

Eine sichere Port-Konfiguration ist die angepasste compose.yaml aus Portainer installieren. Der entscheidende Teil ist nur der ports-Abschnitt:

    ports:
      - "192.168.10.20:9443:9443"

Drei Entscheidungen stecken darin:

• 9443 nur auf der LAN-Adresse. Ohne IP-Angabe veröffentlicht Docker den Port auf allen Adressen des Hosts, IPv4 wie IPv6, also auch auf einer zweiten Netzwerkkarte oder einer öffentlichen Schnittstelle. Die Bindung legt aber nur die Zieladresse fest: Laut Docker-Doku können Geräte hinter einer anderen Schnittstelle desselben Hosts die gebundene Adresse per Routing trotzdem erreichen. Sie ersetzt also keine Firewall-Regel.
• Kein Port 8000. Der Tunnel für Edge Agents ist nur nötig, wenn du Edge Agents einsetzt.
• Kein Port 9000. Unverschlüsseltes HTTP würde Passwort und Sitzung im Klartext übertragen.

Nach einer Änderung übernimmst du sie mit sudo docker compose up -d im Verzeichnis /opt/portainer. Compose erstellt den Container neu, die Daten im Volume bleiben erhalten.

HTTP komplett abschalten #

Willst du sichergehen, dass Port 9000 auch intern nichts mehr ausliefert, gibt es in den Settings im Abschnitt SSL certificate den Schalter Force HTTPS only. Laut Doku hört Portainer dann nicht mehr auf Port 9000. Die Kommandozeilen-Entsprechung ist die Option --http-disabled. Prüfe vorher zwei Dinge: HTTPS muss funktionieren, und kein Reverse Proxy darf Portainer noch über http://portainer:9000 ansprechen. Auch Edge Agents müssen laut Doku vorher auf HTTPS eingestellt sein.

Firewall-Realität mit Docker #

Viele richten auf dem Host ufw ein und glauben, damit seien auch Container geschützt. Die Docker-Dokumentation stellt klar: Werden Container-Ports veröffentlicht, laufen sie an den Regeln von ufw und firewalld vorbei. Docker leitet die Pakete per Adressumschreibung (NAT) weiter, bevor die Regeln dieser Werkzeuge greifen. Eine Regel „9443 nur aus dem LAN“ in ufw bewirkt für einen Container also nichts.

Es gibt zwei wirksame Wege:

1. Port an eine IP binden (wie oben). Das ist die einfachste und robusteste Lösung, weil sie in der Compose-Datei steht und mit dem Container wandert.

2. Eigene Regeln in der Kette DOCKER-USER. Docker legt diese iptables-Kette (eine Regelliste der Linux-Firewall) eigens dafür an, dass du dort Regeln eintragen kannst, die vor Dockers eigenen Regeln greifen. Nach dem Muster der Docker-Doku sperrst du so alle Zugriffe auf veröffentlichte Container-Ports, die über die Schnittstelle eth0 und nicht aus 192.168.10.0/24 kommen:

sudo iptables -I DOCKER-USER -i eth0 ! -s 192.168.10.0/24 -j DROP
sudo iptables -I DOCKER-USER -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT

Die Reihenfolge ist wichtig: -I fügt jede Regel ganz oben ein, die zweite Regel landet also vor der ersten. Sie lässt Antworten auf bestehende Verbindungen durch, sonst würden auch Antworten auf Anfragen blockiert, die deine Container selbst ins Internet schicken. Ersetze eth0 durch den Namen deiner Netzwerkschnittstelle (ip -br link zeigt ihn).

Bevor du das übernimmst, beachte:

• Die Regel gilt für alle veröffentlichten Container-Ports auf dieser Schnittstelle, nicht nur für Portainer.
• Die Regel gilt nur für IPv4. Ohne IP-Bindung lauscht der Port auch auf IPv6 ([::]); diese Verbindungen nimmt laut Docker-Doku bei einem reinen IPv4-Docker-Netz docker-proxy direkt an, sie laufen nicht durch DOCKER-USER. Binde den Port deshalb an eine IPv4-Adresse oder filtere IPv6 mit ip6tables in der Kette INPUT. Die Regeln wurden hier nicht im Testhost angewendet.
• Mit iptables gesetzte Regeln überleben keinen Neustart, solange du sie nicht dauerhaft speicherst. Wie das geht, hängt von deinem System ab; prüfe nach einem Test-Neustart mit sudo iptables -L DOCKER-USER -n, ob die Regeln noch da sind. Laut Docker-Doku funktionieren nur Regeln über iptables oder ip6tables, nicht direkt mit nft angelegte.
• Probiere Firewall-Regeln zuerst an einem Testsystem aus und halte eine zweite Zugangsmöglichkeit bereit (lokale Konsole oder Proxmox-Konsole). Eine falsche Regel kann dich aussperren.

Für ein Homelab reicht in aller Regel die IP-Bindung. DOCKER-USER lohnt sich, wenn mehrere Container gemeinsam eingeschränkt werden sollen.

Admin-Konto, Passwörter und Sitzungen #

Das erste Konto #

Das Admin-Konto legst du bei der Ersteinrichtung an. Zwei Punkte sind dabei wichtig:

• Eigener Benutzername statt des vorgegebenen admin. Das ersetzt kein gutes Passwort, entwertet aber Rateversuche mit dem Standardnamen.
• Langes, zufälliges Passwort aus einem Passwortmanager. Portainer verlangt standardmäßig mindestens 12 Zeichen; im Test mit Portainer CE 2.45.2 lehnte die Einrichtung kürzere Passwörter mit Password does not meet the requirements ab.

Arbeiten mehrere Personen mit Portainer, bekommt jede ein eigenes Konto. Ein geteiltes Admin-Passwort lässt sich nicht gezielt entziehen, wenn jemand nicht mehr mitarbeitet.

Passwortlänge und Sitzungsdauer #

In den Settings unter Authentication stellst du ein, wie Portainer anmeldet. Ab Werk ist das die interne Authentifizierung: Portainer speichert die Benutzer in seiner eigenen Datenbank, die Passwörter nur als Hash, nicht im Klartext. Dort findest du zwei Einstellungen:

• Mindestlänge für Passwörter per Schieberegler, Standard 12 Zeichen. Erhöhst du den Wert, müssen Benutzer mit zu kurzem Passwort es laut Doku beim nächsten Login ändern.
• Sitzungsdauer (session lifetime), Standard acht Stunden. Danach muss man sich neu anmelden. Arbeitest du an geteilten oder mobilen Geräten, verkürze den Wert. Änderungen gelten nur für neue Anmeldungen.

Diese Standardwerte (12 Zeichen, acht Stunden) zeigte auch die Testinstanz.

Der Setup-Token und seine Alternativen #

Neue Instanzen verlangen bei der Ersteinrichtung einen Setup-Token aus dem Container-Log. Er verhindert, dass jemand anderes eine frisch gestartete Instanz vor dir übernimmt. Laut Doku gibt es Alternativen, die du beim ersten Start als Option übergibst:

Bleib im Zweifel beim Standard. Wer --no-setup-token setzt, ist in den ersten Minuten nach dem Start auf das Netz angewiesen: Wer die Seite zuerst aufruft, legt den Admin an. Unabhängig davon gilt die Fünf-Minuten-Frist: Wird das Konto nicht rechtzeitig angelegt, sperrt Portainer die Einrichtung, bis der Container neu gestartet wird.

HTTPS mit eigenem Zertifikat #

Portainer erzeugt beim ersten Start ein selbstsigniertes Zertifikat. Im Test war es fünf Jahre gültig und hatte ein leeres Subject, also keinen eingetragenen Namen. Die Verbindung ist verschlüsselt, der Browser kann aber nicht prüfen, ob er wirklich mit deinem Portainer spricht. Wer die Warnung jedes Mal wegklickt, gewöhnt sich genau das Verhalten an, das ein Angreifer mit einem untergeschobenen Zertifikat ausnutzen würde.

Du hast drei Wege zu einem vertrauenswürdigen Zertifikat:

1. Reverse Proxy. Er besorgt sich das Zertifikat, etwa von Let's Encrypt, und Portainer bleibt dahinter. Das ist der bequemste Weg, wenn du ohnehin einen Proxy betreibst.
2. Hochladen in der Oberfläche. In den Settings im Abschnitt SSL certificate kannst du laut Doku ein eigenes Zertifikat samt Schlüssel hinterlegen und mit Save SSL settings speichern.
3. Beim Start übergeben. Mit den Optionen --sslcert und --sslkey liest Portainer Zertifikat und Schlüssel aus Dateien. Per Kommandozeile übergebene Zertifikate haben laut Doku Vorrang vor hochgeladenen.

Für Weg 3 brauchst du Zertifikat und Schlüssel als Dateien, etwa von einer eigenen Zertifizierungsstelle (CA) oder per Certbot mit DNS-01. Bequemer ist meist der Reverse Proxy aus Weg 1. Hast du die Dateien, legst du sie auf dem Host ab, zum Beispiel unter /opt/portainer/certs, und schützt den Schlüssel:

sudo mkdir -p /opt/portainer/certs
sudo cp portainer.crt portainer.key /opt/portainer/certs/
sudo chmod 600 /opt/portainer/certs/portainer.key

Der erste Befehl legt das Verzeichnis an, der zweite kopiert Zertifikat und Schlüssel aus dem aktuellen Verzeichnis hinein, der dritte macht den Schlüssel nur für root lesbar. In der Compose-Datei bindest du das Verzeichnis schreibgeschützt ein und übergibst die Pfade:

services:
  portainer:
    container_name: portainer
    image: portainer/portainer-ce:2.45.2
    restart: always
    command: --sslcert /certs/portainer.crt --sslkey /certs/portainer.key
    volumes:
      - /var/run/docker.sock:/var/run/docker.sock
      - portainer_data:/data
      - /opt/portainer/certs:/certs:ro
    ports:
      - "192.168.10.20:9443:9443"
 
volumes:
  portainer_data:
    name: portainer_data
 
networks:
  default:
    name: portainer_network

Portainer erwartet beide Dateien im PEM-Format, also als Textdateien mit BEGIN CERTIFICATE-Blöcken. Stammt das Zertifikat von einer externen Stelle, muss die Zertifikatsdatei laut Doku die vollständige Kette enthalten, einschließlich Zwischenzertifikaten. Nutzt du Certbot, verlangt die Doku, die Verzeichnisse live und archive einzubinden, weil die Dateien in live nur Verweise sind. Der Name im Zertifikat muss zu der Adresse passen, unter der du Portainer aufrufst: etwa portainer.example.com bei Let's Encrypt oder portainer.example.lan mit einer eigenen CA, deren Stammzertifikat deine Geräte kennen. Für interne Endungen wie .lan stellen öffentliche Stellen keine Zertifikate aus.

Benutzer, Teams und Rechte in der Community Edition #

Hier liegt der größte Unterschied zwischen den Editionen. Laut Portainer-Doku gibt es rollenbasierte Zugriffskontrolle (RBAC), also Rollen wie Operator, Helpdesk oder Read-Only User mit fein abgestuften Rechten, nur in der Business Edition. In der Community Edition stehen dir diese Bausteine zur Verfügung:

• Benutzer legst du unter User-related → Users an. Ein Benutzer ist Administrator oder nicht; den Schalter Administrator findest du in den Benutzerdetails. Administratoren dürfen alles, auf allen Environments.
• Teams unter User-related → Teams fassen Benutzer zusammen, damit du Zugriffe nicht für jede Person einzeln vergeben musst.
• Zugriff auf Environments vergibst du unter Environment-related → Environments über Manage access.
• Zugriffssteuerung pro Ressource: Container, Stacks, Volumes und Netzwerke, die über Portainer angelegt werden, sind wahlweise nur für Administratoren, für alle Benutzer oder eingeschränkt auf bestimmte Teams und Benutzer sichtbar. Ressourcen, die außerhalb von Portainer entstanden sind, etwa per docker compose auf der Kommandozeile, sind standardmäßig nur für Administratoren sichtbar.

Die entscheidende Grenze: Ein Nicht-Admin, der Container anlegen darf, kann mit den falschen Optionen trotzdem Root auf dem Host werden, etwa mit einem privilegierten Container oder einem Bind Mount (eingebundenes Host-Verzeichnis) auf /. Deshalb gibt es in den Einstellungen des Environments laut Doku eigene Sicherheitsschalter für Nicht-Administratoren, zum Beispiel Hide bind mounts for non-administrators und Hide privileged mode for non-administrators. Schalte sie ein, bevor du anderen Personen Zugriff gibst.

Im typischen Homelab mit einer Person reicht ein persönliches Admin-Konto. Mehrere Konten lohnen sich, sobald jemand anderes nur bestimmte Stacks sehen oder neu starten soll. Brauchst du echte Nur-Lese-Rechte, reicht die CE dafür nicht aus.

Typische Probleme #

Nach Force HTTPS only ist Portainer hinter dem Proxy nicht mehr erreichbar: Der Proxy sprach Portainer über http://…:9000 an, und dieser Port ist jetzt abgeschaltet. Lösung: Proxy auf https://…:9443 umstellen und dort das Backend-Zertifikat akzeptieren, siehe Reverse-Proxy-Guide.

ufw deny 9443 wirkt nicht, Portainer bleibt von außen erreichbar: Das ist das beschriebene Docker-Verhalten. Lösung: Port in der Compose-Datei an die LAN-IP binden oder eine Regel in DOCKER-USER setzen.

Nach dem Einbinden des eigenen Zertifikats startet Portainer nicht: Häufig stimmen Pfade nicht oder der Schlüssel passt nicht zum Zertifikat. sudo docker logs portainer zeigt die Fehlermeldung. Prüfe, ob die Pfade hinter --sslcert und --sslkey im Container existieren, also unter /certs/…, nicht unter dem Host-Pfad.

Browser meldet trotz eigenem Zertifikat einen Fehler: Der Name im Zertifikat passt nicht zur aufgerufenen Adresse, oder die Kette ist unvollständig. Rufe Portainer über den Namen auf, der im Zertifikat steht, nicht über die IP.

Ein Benutzer sieht nach dem Login keine Container: Ihm fehlt der Zugriff auf das Environment oder auf die Ressourcen. Vergib ihn über Manage access beim Environment und prüfe die Zugriffseinstellung des Stacks oder Containers.

Sicherheit und Betrieb #

• Updates einplanen. Sicherheitslücken in Portainer schließt nur ein Update. Mit fester Version in der Compose-Datei entscheidest du bewusst, wann es eingespielt wird; prüfe die Release Notes regelmäßig. Wie du dabei vorgehst, zeigt Portainer aktualisieren.
• Agents nicht offen lassen. Ein Portainer Agent auf Port 9001 gibt volle Kontrolle über seinen Host und koppelt sich ohne AGENT_SECRET mit dem ersten Portainer-Server, der sich meldet. Gib Port 9001 deshalb nur für den Portainer-Server frei, Details in Portainer mit mehreren Servern.
• Konten aufräumen. Konten von Personen, die nicht mehr mitarbeiten, sofort entfernen.
• Socket-Risiko kennen. Selbst die beste Anmeldung ändert nichts daran, dass Portainer Root-Zugriff auf den Host hat. Weitere Maßnahmen rund um Socket, Rechte und Container-Härtung stehen in Docker und Portainer absichern.
• Nicht nebenbei erweitern. Jeder neue Port, jede Freigabe nach außen und jeder zusätzliche Benutzer verändert die Lage. Geh die Abschnitte dieses Guides danach erneut durch.

Weiterlesen #

• Portainer hinter einem Reverse Proxy: gültiges Zertifikat, eigener Name und zusätzliche Schutzschicht für Portainer.
• Docker und Portainer absichern: das Socket-Risiko im Detail und wie du Container mit möglichst wenig Rechten betreibst.
• Tailscale vs. WireGuard: der bessere Weg für den Zugriff von unterwegs als eine öffentliche Freigabe.
• Portainer installieren: falls du die Installation noch einmal sauber mit IP-Bindung und fester Version aufsetzen willst.