Schotten Dicht

Ben2003

New member
Hallo,

aufgrund dieses alten Artikels will ich meine Docker Container nach und nach abdichten.

Derzeit laufen alle Docker Container mit Admin-Berechtigung und Rolle.

Die Docker-Administration erfolgt via Portainer.

Als erstes wurden einige Benutzer und Teams angelegt.

Wenn in einem Container der "Access-Control" auf "Restricted" umgestellt wird, erscheinen gleich zwei Fehlermeldungen:

Authorized teams You have not yet created any teams. Head over to the Teams view to manage teams.
Authorized users You have not yet created any users. Head over to the Users view to manage users.

In den Teams und Benutzern wurden bereits mehrere Test-Nutzer erstellt:

Portainer-Users.png
In den Teams wurden ebenfalls einige Test-Teams erstellt:
Portainer-Teams.png
Portainer-Team-Users.png

Dennoch wird immer die Meldung angezeigt, dass keine Teams und Users vorhanden sein würden.

Kann mir jemand hier einen Tip (oder Neudeutsch: Tipp :) ) geben?
 
Zuletzt bearbeitet:
Ich hab lange überlegt, was der Post mit dem Artikel zu tun hat, da der Post im Kern bisher ein Portainer Rechtemanagement Thema ist.
Da ich Portainer nicht aktiv verwende, kann ich dir dazu leider keine Tipps geben.

Solange ein Host-Verzeichnis als (Bind) Volume für den Container-Pfad /data beim Erzeugen des Containers angegeben wurden, sollten keine Daten abhandenkommen. Selbst dann nicht, wenn man den Container löscht und neu erzeugt (solange das selbe Host-Verzeichnis gegen /data gemapped wurde)

Im Grunde sind die beiden gröbsten Schnitzer aus dem Artikel den Docker Socket aus dem Internet ohne Authentifizierung erreichbar zu machen (was per Default nicht aktiviert ist) und Container im --privileged Mode zu betreiben, da dieser nahe alle Isolationsmechanismen von Docker aufweicht.

Im Artikel fehlt noch das hier: https://docs.docker.com/engine/security/userns-remap/. Es bewirkt, dass die UserID im Container eine andere ist als die UserID auf dem Host. Wenn man es einsetzt, ist root im Container, nur noch ein nicht privilegierter Benutzer auf dem Host.
 
Vielen Dank für die Infos.

Wenn man im Container in der Tat die Bind-Verweise beim Neuanlegen wieder verwendet, können keine Daten-Verluste entstehen. Bei einigen Containern existiert ein Bash-Script, welches bei einem Update den neuen Container von docker holt (Pull-Verfahren) und anschließend mit dem gleichen Daten-Verzeichnissen neu erstellt.

In keinem dieser Scripts wird der Parameter --privileged verwendet.

Portainer wurde nur eingesetzt, da es bequemer ist, einfach in die entsprechenden Felder die Angaben einzutragen, als wenn man sich mit den Docker Parametern erst auseinandersetzen muss.

Vielen Dank für den Veweis auf userns-remap. Hier werde ich mich weiter belesen, um zu erfahren, wie das eingesetzt werden kann.
 
Man könnte das Spiel mit der Abhärtung auch noch weiter treiben, in dem man ein auth-z Plugin wie OpenPolicyAgent verwendet. Damit kann man Polices erstellen, in denen man nicht erlaubte Konfigurationselemente verbieten kann.

Allerdings muss man den Docker Socket über https mit Zertifikatsauthentizierung aktivieren, da es für die Unterscheidung der User in OPA notwendig ist: https://docs.docker.com/engine/secu...tls-https-to-protect-the-docker-daemon-socket

/Update/
geht auch ohne Docker Socket via Zertifikatsauth, aber dann muss die Benutzerinfo in ~/.docker/config.json konfiguriert werden
/Update-Ende/


Statt Bash-Skripten geht die Empfehlung klar Richtung Compose Dateien. Dort kann man dann auch pull_policy: always, damit bei jedem Compose deployment das aktuellste Image verwendet wird, auf dass das Tag gerade zeigt. Natürlich geht das auch mit docker run --pull=always

Rootless Docker (hat nichts mit root im Container bei dem normalen "rootfull" Docker zu tun) bringt tatsächlich auch nochmal eine Abhärtung, aber es ist in der Nutzung dann doch schon deutlich unkomfortabler, da dort die Docker Engine als unprivilegierter Benutzer gestartet wird. Nicht jedes Image läuft damit (es muss im Container als root starten, ist auf dem Host dann ein unprivilegierter Benutzer -> herausforderung beim volume mappen). mal eben ein Container-Netzwerk anlegen oder ein Remote-Volume mounten per docker cli ist dann nicht mehr.
 
Zuletzt bearbeitet:

Zurzeit aktive Besucher

Letzte Anleitungen

Statistik des Forums

Themen
4.534
Beiträge
46.473
Mitglieder
4.171
Neuestes Mitglied
bendermaier
Zurück
Oben