Detaillierte Erläuterung der Sicherheitskonfigurationselemente des Docker-Daemons

Dieser Artikel stellt Ihnen die relevanten Sicherheitskonfigurationselemente des Docker-Daemon-Prozesses vor.

1. Testumgebung

1.1 CentOS 7 installieren

CentOS Linux Version 7.7.1908 (Core)

Aktualisieren Sie den Kernel und starten Sie neu

# yum Kernel aktualisieren
[root@localhost Docker]# uname -a
Linux localhost 3.10.0-1062.12.1.el7.x86_64 #1 SMP Dienstag, 4. Februar 2020, 23:02:59 UTC x86_64 x86_64 x86_64 GNU/Linux
[root@localhost-Docker]# cat /etc/redhat-release
CentOS Linux Version 7.7.1908 (Core)

1.2 Installieren Sie Docker CE 19.03

# yum install -y yum-utils device-mapper-persistent-data lvm2
# yum-config-manager --add-repo https://download.docker.com/linux/centos/docker-ce.repo

# yum install -y docker-ce

[root@localhost docker]# docker --version
Docker-Version 19.03.8, Build afacb8b

2. Daemon-Sicherheitskonfiguration

Standardmäßig gibt es keine Konfigurationsdatei. Sie müssen /etc/docker/daemon.json separat erstellen. Die folgenden Konfigurationen sind alle in dieser Datei konfiguriert und sind lokale Testbeispiele.

{
 "icc": falsch,
 "log-level": "Informationen",
 "log-driver": "JSON-Datei",
 "log-opts": {
 "max-size": "10m",
 "max-Datei": "5",
 "Labels": "irgendeinLabel",
 "env": "Betriebssystem, Kunde"
 },
 "iptables": wahr,
 "userns-remap": "Standard",
 "userland-proxy": falsch,
 "experimentell": falsch,
 "selinux-enabled": wahr,
 "Live-Wiederherstellung": wahr,
 "keine neuen Privilegien": wahr,
 "cgroup-parent": "/foobar",
 "seccomp-Profil": "/etc/docker/seccomp/default-no-chmod.json",
 "tls": wahr,
 "tlsverify": wahr,
 "tlscacert": "/etc/docker/CA/ca.pem",
 "tlscert": "/etc/docker/CA/server-cert.pem",
 "tlskey": "/etc/docker/CA/server-key.pem"
}

2.1 Zugriff auf den Docker-Daemon über HTTPS und Zertifikatsauthentifizierung konfigurieren

Server-Zertifikate

Erstellen Sie einen HOST und definieren Sie die Domäne (IP ist auch OK). Das entsprechende Zertifikat wird entsprechend der Domäne generiert, die im Allgemeinen zur Registrierung des CN im Zertifikat verwendet wird:

Erstellen Sie ein Zertifikatsverzeichnis:

$ mkdir -p /etc/docker/dockerd/CA und cd /etc/docker/dockerd/CA

Generieren Sie ein Schlüsselzertifikat und geben Sie das Schlüsselzertifikatkennwort zweimal ein:

$ openssl genrsa -aes256 -out ca-key.pem 4096

Um ein CA-Zertifikat zu generieren, müssen Sie die grundlegenden Informationen des Registrierungszertifikats eingeben:

$ openssl req -new -x509 -days 365 -key ca-key.pem -sha256 -out ca.pem

Erstellen Sie ein Serverzertifikat:

$ openssl genrsa -out server-key.pem 4096

$ openssl req -subj "/CN=localhsot" -sha256 -new -key server-key.pem -out server.csr

Legen Sie die im Zertifikat angegebene IP-Adresse fest:

$ echo subjectAltName = DNS:localhost,IP:127.0.0.1 >> extfile.cnf

Legen Sie die erweiterte Verwendungseigenschaft des Docker-Daemon-Schlüssels so fest, dass er nur für die Serverauthentifizierung verwendet wird:

$ echo extendedKeyUsage = serverAuth >> extfile.cnf

Server-Zertifikat generieren:

$ openssl x509 -req -days 3650 -sha256 -in server.csr -CA ca.pem -CAkey ca-key.pem -CAcreateserial -out server-cert.pem -extfile extfile.cnf

Client-Zertifikate

Erstellen Sie ein Client-Zertifikat: (immer noch im aktuellen Verzeichnis)

$ openssl genrsa -out key.pem 4096
$ openssl req -subj '/CN=localhost' -new -key key.pem -out client.csr

Um den Schlüssel für die Client-Authentifizierung geeignet zu machen, erstellen Sie eine erweiterte Konfigurationsdatei:

$ echo extendedKeyUsage = clientAuth >> extfile.cnf

Generieren Sie das Client-Zertifikat:

$ openssl x509 -req -days 3650 -sha256 -in client.csr -CA ca.pem -CAkey ca-key.pem -CAcreateserial -out cert.pem -extfile extfile.cnf

verwenden

Erteilen Sie dem Zertifikat entsprechende Berechtigungen:

$ chmod -v 0400 ca-key.pem key.pem server-key.pem
$ chmod -v 0444 ca.pem server-cert.pem cert.pem

[root@localhost CA]# ls
ca-key.pem ca.pem ca.srl cert.pem client.csr extfile.cnf key.pem server-cert.pem server.csr server-key.pem

Serverkonfiguration /etc/docker/daemon.json

"tls": wahr,
"tlsverify": wahr,
"tlscacert": "/etc/docker/CA/ca.pem",
"tlscert": "/etc/docker/CA/server-cert.pem",
"tlskey": "/etc/docker/CA/server-key.pem"

Client-Konfiguration

Stellen Sie das Client-Zertifikat auf dem Server ein und platzieren Sie es am entsprechenden Ort:

$ cp -v {ca,cert,key}.pem ~/.docker
$ export DOCKER_HOST=tcp://$HOST:2376 DOCKER_TLS_VERIFY=1

Der Simulationstest wird wie folgt durchgeführt:

$ curl https://$HOST:2376/images/json \
 --cert ~/.docker/cert.pem \
 --key ~/.docker/key.pem \
 --cacert ~/.docker/ca.pem
 
[{"Container":-1,"Erstellt":1540777343,"Id":"sha256:55e7b305dc477345434ce3bd3941940481f982eea31c8f28c0670d59c63d544b","Labels":nu

2.2 Verwenden der Namespace-Isolationstechnologie

Namespace ist eine Isolationstechnologie. Docker verwendet Isolationstechnologie, um einen bestimmten Namespace zu öffnen und einige spezielle Prozesse zu erstellen. Die Verwendung von Namespaces ist jedoch an Bedingungen geknüpft. Das System erstellt Dockremap und ordnet es dem Container über /etc/subuid und den entsprechenden ID-Wert von /etc/subuid zu. Tatsächlich wird weiterhin die normale Berechtigung von Dockremap verwendet, um den Effekt der automatischen Isolierung zu erzielen.

Ändern Sie zuerst /etc/sysctl.conf

# echo "Benutzer.max_user_namespaces=15076" >> /etc/sysctl.conf

Fügen Sie das Konfigurationselement "userns-remap": "default" in /etc/docker/daemon.json hinzu

Beim Ändern dieser Konfiguration ist Vorsicht geboten. Wenn Sie bereits eine Docker-Umgebung bereitgestellt haben, wechseln Sie nach dem Aktivieren dieser Option zu einer isolierten Umgebung und der vorherige Docker-Container ist nicht verfügbar!

[root@localhost Docker]# cat /etc/subuid
dockremap:100000:65536

2.3 Einrichten von Docker-Partitionen

Erstellen Sie eine separate Partition für den Container. Die Standardpartition befindet sich in \var\lib\docker\ und enthält lokale Images, Container, Netzwerke und andere zugehörige Dinge.

[root@localhost Docker]# ls /var/lib/docker

100000.100000 Builder Buildkit Container Image Netzwerk Overlay2 Plugins Laufzeiten Schwarm TMP Vertrauen Volumes
Der Standardspeicherort der Partition kann mit „data-root“: „“ konfiguriert werden.

2.4 Begrenzen des Datenverkehrs zwischen Standard-Bridge-Containern

Wenn der Docker-Dienst gestartet wird, wird der FORWARD-Kette von iptables standardmäßig eine Weiterleitungsrichtlinie hinzugefügt. Die Richtlinie ist entweder ACCEPT oder DROP, je nachdem, ob --icc=true (Standard) oder --icc=false konfiguriert ist. Wenn Sie --iptables=false manuell angeben, werden keine iptables-Regeln hinzugefügt.

Standardmäßig ist die gesamte Netzwerkkommunikation zwischen Containern auf demselben Host auf der Standardbrücke zulässig. Wenn dies nicht erforderlich ist, beschränken Sie die Kommunikation zwischen allen Containern. Verknüpfen Sie bestimmte Container, die kommunizieren müssen, oder erstellen Sie ein benutzerdefiniertes Netzwerk und verbinden Sie nur die Container, die mit diesem benutzerdefinierten Netzwerk kommunizieren müssen.

Konfigurieren Sie die Begrenzung des Datenverkehrs zwischen Containern auf der Standardbrücke „icc“: false

2.5 Protokollierung konfigurieren

Konfigurieren Sie die zentrale Remote-Protokollierung, legen Sie den Protokollierungsprozess fest – Log-Level auf Info, Protokollformat auf JSON, lokale Protokollierung

"log-level": "Informationen",
"log-driver": "JSON-Datei",
"log-opts": {
 "max-size": "10m",
 "max-Datei": "5",
 "Labels": "irgendeinLabel",
 "env": "Betriebssystem, Kunde"
},

Konfigurieren der Remote-Protokollierung

Der Docker-Protokollierungstreiber empfängt Containerprotokolle und leitet sie an ein Remoteziel oder eine Remotedatei weiter. Der Standardprotokollierungstreiber ist json-file . Es speichert Containerprotokolle im JSON-Format auf der lokalen Festplatte. Docker verfügt über eine Plugin-Architektur für die Protokollierung, daher gibt es Plugins sowohl für Open Source als auch für kommerzielle Tools:

Journald – Speichert Containerprotokolle im Systemjournal.
Syslog-Treiber – Unterstützt UDP, TCP, TLS
Fluentd – Unterstützt die Verbindung von TCP- oder Unix-Sockets mit Fluentd
Splunk – HTTP/HTTPS-Weiterleitung zum Splunk-Server
Gelf – UDP-Log-Weiterleitung an Graylog2

Beispiel fließend

{
 "log-driver": "fluentd",
 "log-opts": {
 "fluentd-Adresse": "fluentdhost:24224"
 }
 }

Verwenden von Syslog

{
 "log-driver": "syslog",
 "log-opts": {
 "Syslog-Adresse": "udp://1.2.3.4:1111"
 }
}

2.6 ulimit einstellen

{
 "Standard-ulimits": {
 "keine Datei": {
  "Name": "keine Datei",
  "Schwer": 64000,
  "Weich": 64000
 }
 }
}

2.7 Einstellen der Kontrollgruppe

Mit der Option --cgroup-parent können Sie die übergeordnete Standard-Cgroup festlegen, die für Container verwendet werden soll. Wenn diese Option nicht festgelegt ist, wird standardmäßig /docker für den fs-Cgroup-Treiber und system.slice für den systemd-Cgroup-Treiber verwendet.

Wenn die Kontrollgruppe einen Schrägstrich ( / ) hat, wird die Kontrollgruppe unter der Stamm-Kontrollgruppe erstellt, andernfalls wird die Kontrollgruppe unter der Daemon-Kontrollgruppe erstellt.

Angenommen, der Daemon läuft in der Kontrollgruppe daemoncgroup, dann erstellt --cgroup-parent=/foobar eine Kontrollgruppe in /sys/fs/cgroup/memory/foobar, während --cgroup-parent=foobar eine Kontrollgruppe in /sys/fs/cgroup/memory/daemoncgroup/foobar erstellt.

Der systemd-cgroup-Treiber hat andere Regeln für --cgroup-parent. Systemd stellt die Hierarchie in Slices dar, wobei der Name des Slices die Position im Baum kodiert. Daher sollte --cgroup-parent der systemd-cgroup der Slice-Name sein. Der Name kann aus einer Reihe von durch Bindestriche getrennten Namen bestehen, die den Pfad vom Stamm-Slice zum Slice beschreiben. Beispielsweise bedeutet --cgroup-parent=user-ab.slice, dass die Speicher-Cgroup des Containers in /sys/fs/cgroup/memory/user.slice/user-a.slice/user-ab.slice/docker-<id>.scope erstellt wird.

Es kann auch mithilfe der Containerlaufzeit festgelegt werden, indem die Option --cgroup-parent bei docker create und docker run verwendet wird. Dies hat Vorrang vor der Option --cgroup-parent beim Daemon.

2.8 Konfigurieren von seccomp

Die verwendete Testkonfigurationsdatei verbietet die Verwendung des Befehls chmod in Docker

https://github.com/docker/labs/blob/master/security/seccomp/seccomp-profiles/default-no-chmod.json
[root@localhost Docker]# Docker run --rm -it alpine sh
/ # ls bin etc lib mnt proc run srv tmp var
dev home media opt root sbin sys usr / # touch foo.sh
/ # chmod +x foo.sh
chmod: foo.sh: Vorgang nicht zulässig
/ # Ausfahrt

Es kann tatsächlich bestimmte systembezogene Aufrufe verbieten, zulassen und vor ihnen warnen, siehe: https://github.com/torvalds/linux/blob/master/arch/x86/entry/syscalls/syscall_64.tbl

2.9 Konfigurieren von Containern ohne Daemon-Unterstützung

--live-restore stellt sicher, dass der Docker-Daemon heruntergefahren wird, ohne den Container zu beeinträchtigen.

Während des Tests kann der Nginx-Container nach dem Herunterfahren des Docker-Daemons weiterhin normalen Zugriff gewähren.

2.10 Experimentelle Funktionen von Docker deaktivieren

Setze "experimentell": false

2.11 Begrenzung der Container-Berechtigungsausweitung über suid oder sgid

Die Sicherheitsoption „No-New-Privileges“ verhindert, dass Anwendungsprozesse innerhalb eines Containers während der Ausführung neue Berechtigungen erhalten.

Wenn beispielsweise im Image ein Programm mit gesetztem Setuid/Setgid-Bit vorhanden ist, wie etwa sudo, hat der Prozess im Container auch (Datei-)Berechtigungen, dieses Programm auszuführen. Jeder Versuch, über Einrichtungen wie Setuid/Setgid Privilegien zu erlangen, wird abgelehnt.

3. Beispiel für eine Daemon-Konfiguration (Linux)

{
 "authorization-plugins": [], // Zugriff auf das Autorisierungs-Plugin "data-root": "", // Das Stammverzeichnis für die dauerhafte Speicherung von Docker-Daten, der Standard ist /var/lib/docker
 "dns": [], //DNS-Server"dns-opts": [], //DNS-Konfigurationsoptionen, wie Port usw. "dns-search": [], //DNS-Suchdomänenname"exec-opts": [], //Ausführungsoptionen"exec-root": "", //Das Stammverzeichnis der ausgeführten Datei"experimental": false, //Ob experimentelle Funktionen aktiviert werden sollen"features": {}, //Bestimmte Funktionen aktivieren oder deaktivieren. Beispiel: {"buildkit": true} macht Buildkit zum standardmäßigen Docker-Image-Builder.
 "storage-driver": "",//Speichertreibertyp "storage-opts": [],//Speicheroptionen "labels": [],//Schlüssel-Wert-Paar zum Markieren von Docker-Metadaten "live-restore": true,//Ob der Container am Leben bleiben soll, wenn Dockerd auflegt (Vermeidung des Container-Beendens aufgrund einer Docker-Dienstausnahme)
 "log-driver": "json-file", //Container-Protokolltreiber "log-opts": {
 "max-size": "10m",
 "max-Datei": "5",
 "Labels": "irgendeinLabel",
 "env": "Betriebssystem, Kunde"
 }, //Container-Protokolloptionen "mtu": 0, //MTU (Maximum Transmission Unit) des Containernetzwerks festlegen
 "pidfile": "", //Speicherort der Daemon-PID-Datei "cluster-store": "", //URL des Cluster-Speichersystems
 "cluster-store-opts": {},//Clusterspeicher konfigurieren"cluster-advertise": "",//Externer Adressname"max-concurrent-downloads": 3,//Maximale Parallelität jedes Pull-Prozesses festlegen"max-concurrent-uploads": 5,//Maximale Parallelität jedes Push-Prozesses festlegen"default-shm-size": "64M",//Standardgröße des gemeinsam genutzten Speichers festlegen"shutdown-timeout": 15,//Timeout-Limit für das Herunterfahren festlegen"debug": true,//Debug-Modus aktivieren"hosts": [],//Abhöradresse des Dockerd-Daemon-Prozesses"log-level": "",//Protokollebene"tls": true,//Transport Layer Security-Protokoll TLS aktivieren
 "tlsverify": true, // Transport Layer Security-Protokoll aktivieren und Remote-Adresse verifizieren "tlscacert": "", // CA-Signaturdateipfad "tlscert": "", // TLS-Zertifikatdateipfad "tlskey": "", // TLS-Schlüsseldateipfad "swarm-default-advertise-addr": "", // Swarm-externe Adresse "api-cors-header": "", // CORS-Header (Cross-Origin Resource Sharing) festlegen "selinux-enabled": false, // Selinux aktivieren (obligatorische Zugriffskontrolle für Benutzer, Prozesse, Anwendungen und Dateien)
 "userns-remap": "", //Benutzer/Gruppen für Benutzernamensraum festlegen "group": "", //Docker-Gruppe "cgroup-parent": "", //Die übergeordnete Klasse der cgroup für alle Container festlegen "default-ulimits": {
 "keine Datei": {
  "Name": "keine Datei",
  "Schwer": 64000,
  "Weich": 64000
 }
 }, //ulimit für alle Container festlegen
 "init": false, //Container führt Initialisierung durch, um Signale weiterzuleiten oder Prozesse zu steuern (reapen) "init-path": "/usr/libexec/docker-init", //Pfad zur Docker-Init-Datei "ipv6": false, //Unterstützt IPV6-Netzwerk "iptables": false, //Öffne Firewall-Regeln "ip-forward": false, //Öffne net.ipv4.ip_forward
 "ip-masq": false, // IP-Maskierung aktivieren (eine Technik zum Umschreiben von Quell- oder Ziel-IP-Adressen, wenn IP-Pakete einen Router oder eine Firewall passieren)
 "userland-proxy": false, //Userland-Proxy "userland-proxy-path": "/usr/libexec/docker-proxy", //Userland-Proxy-Pfad "ip": "0.0.0.0", //Standard-IP
 "bridge": "", // Den Container an das Bridge-Netzwerk anhängen "bip": "", // Die Bridge-IP angeben
 "fixed-cidr": "", // (IPv4) Subnetzaufteilung, d. h. Begrenzung des Bereichs der IP-Adresszuweisung, um das Netzwerksegment zu steuern, zu dem der Container gehört, um Netzwerkzugriff zwischen Containern (gleicher Host oder unterschiedliche Hosts) zu erreichen"fixed-cidr-v6": "", // (IPv6) Subnetzaufteilung"default-gateway": "", // Standard-Gateway"default-gateway-v6": "", // Standard-IPv6-Gateway"icc": false, // Kommunikation zwischen Containern"raw-logs": false, // Rohprotokolle (keine Farbe, vollständiger Zeitstempel)
 "allow-nondistributable-artifacts": [],//Registry-Repositorys, die für Produkte übermittelt wurden, die nicht extern verteilt werden"registry-mirrors": [],//Beschleunigungsadresse für Spiegel der Registrierungsrepository"seccomp-profile": "",//seccomp-Konfigurationsdatei"insecure-registries": [],//Nicht-https-Registry-Adresse konfigurieren"no-new-privileges": false,//Neue Prioritäten verbieten"default-runtime": "runc",//Standardlaufzeitumgebung der OCI Alliance (The Open Container Initiative)"oom-score-adjust": -500,//Priorität für Beenden aufgrund von Speicherüberlauf (-1000~1000)
 "node-generic-resources": ["NVIDIA-GPU=UUID1", "NVIDIA-GPU=UUID2"], //Öffentlich veröffentlichte Ressourcenknoten "runtimes": {
 "cc-Laufzeit": {
  "Pfad": "/usr/bin/cc-runtime"
 },
 "Brauch": {
  "Pfad": "/usr/local/bin/my-runc-replacement",
  "LaufzeitArgs": [
  "--debuggen"
  ]
 }
 }, //Laufzeit "Standardadresspools":[
 {"base":"172.80.0.0/16","size":24}, //Standardmäßig per DHCP zugewiesene Adresse {"base":"172.90.0.0/16","size":24}
 ]
}

Zusammenfassen

Dies ist das Ende dieses Artikels mit der detaillierten Erläuterung des Docker-Daemon-Sicherheitskonfigurationsprojekts. Weitere relevante Docker-Daemon-Inhalte finden Sie in früheren Artikeln auf 123WORDPRESS.COM oder in den folgenden verwandten Artikeln. Ich hoffe, dass jeder 123WORDPRESS.COM in Zukunft unterstützen wird!