Docker und Sie :)

Zufällig
1

Hallo zusammen :partying_face:

Ich weiß, dass viele von euch Docker privat und/oder beruflich nutzen.
Ich muss bald eine Testinfrastruktur auf Docker aufsetzen und habe daher einige Fragen zu eurer Nutzung. :slight_smile:

Beim Lesen der Empfehlungen der ANSSI bin ich auf ein paar Dinge im Bereich Sicherheit gestoßen:

  • UID-Neuzuordnung
  • Unprivileged

UID-Neuzuordnung

Bei der UID-Neuzuordnung: Wenn man LXC unprivileged einrichtet,

  • Benutzer LXC = 1000, Benutzer Host = 101000

Dann gibt es im Falle eines Ausbruchs kein Problem. Macht ihr das häufig? Immer?

Unprivileged

Nutzt ihr das häufig? In meiner Vorstellung sollte es nie mit vollen Privilegien laufen. Wenn z. B. 4 USB-Ports benötigt werden, würde ich diese lieber explizit einrichten.

Speicherung

Soweit ich mich erinnere, ist ein Docker-Container volatil, die Anwendungsdaten müssen also gebunden werden. Sie müssen also woanders gespeichert werden. Wie handhabt ihr diesen Teil? Exportiert ihr z. B. eure Logs?

Cloud

Nutzt ihr öffentlichen Cloud- oder privaten Cloud-Speicher?

Ich werde auf eine selbstgehostete Infrastruktur / Bilder etc. setzen und die externen Abhängigkeiten auf ein Minimum beschränken. Dabei bin ich auf OKD gestoßen, das scheint nicht schlecht zu sein

Falls jemand Empfehlungen hat, bin ich dankbar :slight_smile:

Das Endziel ist es, eine Plattform für einige Entwickler anzubieten, damit sie mit dem Deployment von Bildern autonom sein können.

Kurz gesagt… wenn ihr eure Docker-Erfahrungen, eure Nutzung, eure Anforderungen / Einschränkungen teilen könnt, hilft mir das, einen Überblick zu bekommen.

Die Personen, für die ich das mache, wollen Docker nutzen, aber ich glaube nicht, dass sie Funktionen wie HA im Kopf haben etc. :slight_smile:

Danke euch!

2

Im privaten oder beruflichen Kontext?

3

Beide sind interessant.

Meine Lösung wird im professionellen Rahmen eingesetzt, daher steht die Sicherheit an erster Stelle :slight_smile:

4

Hallo

Entschuldige, ich habe deinen Post noch nie gesehen!

Persönlich verwende ich Docker mit mehreren Optionen, um die Root-Rechte standardmäßig zu entfernen.

Dafür:

  1. Option Benutzerbereich (UID- und GID-Remapping)
    Das ist super, denn ein Prozess mit Root-Rechten im Container ist dann nicht mehr Root auf deinem OS. Das verwenden übrigens auch öffentliche CI/CD-Plattformen, glaube ich.
    Einziger Nachteil: Einige Anwendungen müssen angepasst werden, um keine privilegierten Ports wie Port 80 oder 443 zu verwenden oder bestimmte Systemaktionen funktionieren nicht (wie das Erstellen einer Netzwerkkarte).

  2. Alle CAPABILITIES standardmäßig mit drop_cap=all entfernen und dann nur die hinzufügen, die notwendig sind.

  3. Die maximale Leistung des Containers in CPU, RAM und Anzahl der gestarteten Prozesse begrenzen.
    Das verhindert, dass ein fehlerhafter oder kompromittierter Container alle Ressourcen des Hosts verbraucht.

  4. Docker in der userland-Version installieren, ohne den Daemon, der mit root-Rechten läuft. Das ist radikal, aber sicherer.

Das ist, was mir im Moment einfällt :sweat_smile:

Ein Beispiel für eine Docker-compose-Datei mit diesen Elementen, aber ohne die PID-Begrenzung:

5

Kein Problem :slight_smile:

Das verwende ich auch mit LXC

Danke, das wird mir wahrscheinlich nützlich sein

Ich werde wahrscheinlich noch vor Jahresende ein Lab zu OKD machen, um zu sehen, wie sich das entwickelt.

Da wir den Entwicklern benutzerdefinierte Docker-Images bereitstellen, mit benutzerdefiniertem Apache, PHP, PHP-FPM usw., sehe ich ein Problem, das auftreten könnte.

Zum Beispiel, wenn es ein Image apache2/php7.4 mit bestimmten PHP-Modulen gibt. Wenn ein Entwickler für ein bestimmtes Projekt eine Erweiterung benötigt, die nicht enthalten ist, ein anderer Entwickler eine andere Erweiterung benötigt… das könnte unübersichtlich werden. Das würde bedeuten, ein Image pro Projekt zu erstellen. Ich habe etwas Schwierigkeiten, diesen Teil zu visualisieren.

6

Genau, normalerweise wird dieses Paradigma verwendet.

Ein Projekt = ein Docker-Image.

Der Entwickler des Projekts erstellt sein Docker-Image und entwickelt sein Dockerfile weiter, während das Projekt wächst.

Die Dockerfile wird wie jede andere Code-Datei behandelt, genau wie du Abhängigkeiten zu deiner package.json (oder dem Äquivalent für PHP-Projekte) hinzufügst, fügst du Systemabhängigkeiten zu deiner Dockerfile hinzu, während das Projekt wächst.

7

In unserem Fall ist das nicht so, wir sind eher in der Rolle des Hosting-Anbieters und daher ist die Konfiguration des Webservers, Mailservers oder anderer Dienste unsere Verantwortung, falls dort eine Schwachstelle besteht. Es geht mehr um den Umfang und die Verantwortung.

Heute stellen wir VMs bereit, um den Code gemäß ihren Anforderungen zu hosten. Ich beginne, mit Ansible zu arbeiten, um den VM-Erstellungsprozess zu automatisieren. Morgen wollen sie mit Docker auf einer Lab-Plattform beginnen, um zu sehen, was sie damit machen können. Daher wird dieser Ansatz, bei dem das Image vom Hosting-Anbieter bereitgestellt wird, natürlich bestehen bleiben. Das könnte kompliziert werden :slight_smile:

8

Ach, ich verstehe, okay! :slight_smile: Ich dachte, du sprichst über die interne Entwicklung. In diesem Fall liegt es an dir, ein möglichst umfassendes Bild zu erstellen, das für alle passt, oder verschiedene Versionen mit unterschiedlichen Umfängen je nach Projekt anzubieten.

9

Es wäre eher der zweite Fall. Es wird sehr viel Diskussion geben, um eine Organisation zu finden.

Sogar mit mehreren Bildern ist es kompliziert. Im Sinne, dass du ein Projekt haben kannst, das exec benötigt, was von Grund auf nicht empfohlen wird.
Daher setzt du ein Bild mit exec und eines ohne und der Entwickler kann seine Wahl treffen.

Bei exec arbeiten wir standardmäßig gesperrt. Wenn es wirklich nötig ist, warnen wir vor dem Risiko und aktivieren es. Wenn der Entwickler die Wahl treffen kann, habe ich Angst, dass es zu einer Bildnutzung ohne Bewusstsein des Risikos dieser Bilder usw. usw. führt.

Ohne ins Klischee zu verfallen, habe ich bereits einen Entwickler gesehen, der ein chmod 777 gemacht hat, weil er blockiert war … Euhhhhhhhh :nauseated_face: :crazy_face:

10

Hardening

Dass du die Empfehlungen der ANSSI gelesen hast, war gut. Ich kann dir auch die des CIS BENCHMARK empfehlen (Docker, aber auch alle Arten von Systemen).

Remap

Das geht direkt in der Docker-Konfiguration. Beispiel meiner Konfiguration:

/etc/docker/daemon.json

{
     "dns": ["9.9.9.9", "1.0.0.1"],
     "live-restore": true,
     "log-level": "debug",
     "max-concurrent-downloads": 30,
     "selinux-enabled": true,
     "no-new-privileges": true,
     "userland-proxy": false,
     "userns-remap" : "default"
}

Unprivileged

Ich möchte hinzufügen, dass es auch eine Suite von Mikro-Executables gibt, die sehr praktisch ist, um dieses Problem zu adressieren: GitHub - just-containers/s6-overlay: s6 overlay for containers (includes execline, s6-linux-utils & a custom init) · GitHub

Zusammengefasst ermöglicht dieses Projekt die Erstellung von Containern, die eine Reihe von Aktionen als root ausführen, wenn nötig (Ändern von Berechtigungen, Erstellen bestimmter spezifischer Dateien, Erstellen eines einfachen Benutzers im Container usw.), und dann das Programm mit den niedrigsten Privilegien ausführen, das im Container gestartet werden muss.
Das ist sehr gut durchdacht und praktisch. Das ist, was ich in meinem Image hier verwende: Dockerfiles/seedbox/flood at master · LM1LC3N7/Dockerfiles · GitHub

Speicherung

Ich bestätige, dass die Speicherung in einem Container standardmäßig nicht persistent ist. Das ist der Sinn von Docker-Volumes, um Speicher auch nach der Löschung eines Containers zu behalten.
Der Vorteil ist, dass du rm -rf / ausführen kannst, ohne dass etwas auf dem Host-Server passiert (aber dein Container ist dann außer Betrieb).
Die meisten meiner Anwendungen müssen persistenten Speicher verwenden, zum Beispiel für Datenbanken.
Ich verwende Docker ein wenig im Sinne von: ein Container = ein Prozess.

Daher habe ich für einen Blog, der einen Webserver-Teil und einen Datenbank-Teil hat, zwei Container:

  1. Webserver mit HTML-, JS-, Bilddateien usw.
    Nichts ist persistent (da es in das Image eingebettet ist), außer dem Ordner logs, uploads und images, die sich ändern können.
  2. Die Datenbank.
    Gleiches Prinzip, nichts ist persistent außer dem Ordner, der die Datenbankdateien speichert (z. B. /var/lib/mysql.

Mein Server verwendet eine kostenlose Distribution auf Basis von RedHat (Oracle Linux), die standardmäßig SELinux integriert. Dadurch werden die Volumes geschützt, damit ein Container nicht entkommen oder auf eingeschränkte Dateien im System zugreifen kann. Das funktioniert übrigens sehr gut!

Plattform

Da es sich um eine private Nutzung handelt, verwende ich einen dedizierten Server bei Online.net (jetzt Scaleway.fr). Es ist aber auch möglich, Kubernetes-Cloud-Instanzen zu verwenden oder direkt Container mit AWS, Azure, Google Cloud usw. zu erstellen.

11

Ich hatte dieses Thema über Docker nicht gesehen.
Es ist sehr interessant, danke. :slight_smile:
Ich arbeite ein bisschen damit bei der Arbeit.
Habt ihr Tools zur Verwaltung der Instanzen und zur Erstellung von Hochverfügbarkeit, bitte?

12

Am bekanntesten ist das Projekt Kubernetes, wobei ich selbst keine Erfahrung damit habe. Wenn du eine Anwendung darauf anpasst, kannst du tatsächlich eine hohe Verfügbarkeit, automatische Lastverteilung und Ähnliches verwalten.
Aber soweit ich verstanden habe, ist das alles andere als einfach.

Etwas einfacher sind Web-Interfaces wie https://www.rancher.com/ (davon gibt es auch eine Open-Source-Version), die dir helfen könnten.

13

@lmilcent danke für dein Feedback. Ich werde es mir in den Ferien mal ansehen. :slight_smile: