nicholasjackson/cnitchContainer Snitch überprüft laufende Prozesse unter der Docker Engine und alarmiert, wenn welche als root ausgeführt werden.
cnitch (Snitch oder Container Snitch) ist ein einfaches Framework und Kommandozeilen-Tool zur Überwachung von Docker-Containern, um Prozesse zu identifizieren, die als root ausgeführt werden.
Warum ist das problematisch? Falls du noch nicht auf can I haz non-privileged containers? von mhausenblas warst, empfehle ich dir, jetzt dorthin zu gehen, um alle Informationen zu erhalten.
Als ich cnitch entwickelte, stieß ich auf ein vermeintliches Bug in der Anwendung: cnitch meldete sich selbst als root-Prozess in einem Docker-Container. Ich war mir nicht sicher, wie das möglich sein sollte, da das Dockerfile explizit einen Benutzer erstellte und nicht als root lief. Nach viel Debugging und Überprüfung entschied ich, das Dockerfile noch einmal zu prüfen, und fand Folgendes:
FROM alpine
RUN adduser -h /home/cnitch -D cnitch cnitch
COPY ./cmd/cnitch /home/cnitch/
RUN chmod +x /home/cnitch/cnitch
#USER cnitch
ENTRYPOINT ["/home/cnitch/cnitch"]
Als ich den Anwendungscontainer testete, um ein Problem mit den Berechtigungen des Docker-Sockets zu beheben, muss ich den Befehl USER versehentlich auskommentiert haben. Ziemlich meta: cnitch half dabei, ein Problem mit cnitch zu finden. Das kommt definitiv in die Integrationstests.
cnitch verbindet sich über die API mit der Docker Engine, fragt die aktuell laufenden Container ab, untersucht dann die Prozesse innerhalb dieser Container und identifiziert diejenigen, die als root ausgeführt werden.
Wenn ein root-Prozess gefunden wird, werden diese Informationen an die konfigurierbaren Reporting-Module gesendet, sodass du diese Informationen prüfen oder Maßnahmen ergreifen kannst.
2017/07/29 16:04:27 Starting Cnitch: Monitoring Docker Processes at: tcp://172.16.255.128:2376
2017/07/29 16:04:27 Checking for root processes every: 10s
2017/07/29 16:05:08 Checking image: ubuntu, id: 7bd489560a310343c39186500daa680290289c27f7a730524a31355a3aaf0430
2017/07/29 16:05:08 >> WARNING: found process running as root: tail -f /dev/null pid: 365
Derzeit verfügt cnitch über die Möglichkeit, an StatsD und StdOut zu melden. Die Reporting-Backends sind erweiterbar, sodass jedes Backend einfach unterstützt werden kann; zum Beispiel wäre es ein relativ trivialer Prozess, ein Backend für Logstash oder ein anderes Log-Aggregationstool zu bauen.
Die Ausnahmen werden als Count mit der Metrik cnitch.exception.root_process an den StatsD-Endpunkt gesendet. Die Metriken sind zusätzlich mit dem host-Namen der cnitch-Instanz und dem container-Namen getaggt.
Der StdOut-Logger ist ein einfacher Ausgabe-Logger, der die gemeldeten Ausnahmen an StdOut sendet.
Egal, ob du cnitch in einem Docker-Container oder als Binärdatei ausführst – es benötigt Zugriff auf die Docker-API, indem die URL des Servers oder der Pfad zum Socket mit der Umgebungsvariablen DOCKER_HOST gesetzt wird.
--hostname=[hostname] der Name oder die IP-Adresse, die für die Metrik-Aggregation verwendet werden soll--statsd-server=[hostname:port] die URI des StatsD-Sammlers; wenn weggelassen, wird die StatsD-Meldung deaktiviert--check=[Dauer, z.B. 10s (10 Sekunden), 1m (1 Minute)], die Prüfhäufigkeit, mit der Snitch nach root-Prozessen suchtSetze die Umgebungsvariable DOCKER_HOST auf deine Docker-Engine-API und führe dann Snitch mit den erforderlichen Flags aus.
$ cnitch --hostname=myhost --statsd-server=127.0.0.1:8125 --check=10s
cnitch läuft in einem nicht privilegierten Container. Wenn du den Docker-Socket für den API-Zugriff verwenden möchtest, musst du den cnitch-Benutzer zur docker-Gruppe hinzufügen. Dies kann durch das Flag --group-add erreicht werden. Setze dies auf die Gruppen-ID der Docker-Benutzergruppe.
Zum Beispiel:
--group-add=$(stat -f "%g" /var/run/docker.sock
Beispiel mit Docker-Socket-Datei für den API-Zugriff
$ docker run -i -t --rm \
-v /var/run/docker.sock:/var/run/docker.sock \
--group-add=$(stat -f "%g" /var/run/docker.sock) \
-e "DOCKER_HOST:unix:///var/run/docker.sock" \
quay.io/nicholasjackson/cnitch [options]
Wenn du auf einem Mac arbeitest und Docker Machine verwendest, befindet sich der Docker-Socket innerhalb der VM, sodass du den Befehl stat nicht verwenden kannst, um die Gruppen-ID zu ermitteln.
Im Ordner ./example befindet sich ein Beispiel-Docker-Compose-Stack, der zeigt, wie cnitch Daten an StatsD exportiert. Um dieses Beispiel auszuführen:
$ cd ./example
$ docker-compose up
Sobald alles gestartet ist, öffne http://[docker host ip]:3000 in deinem Webbrowser und du solltest den Grafana-Anmeldebildschirm sehen.
Melde dich bei Grafana mit den folgenden Anmeldedaten an:
Wähle dann das cnitch-Dashboard aus. Dieses Dashboard zeigt die aktuell laufenden root-Prozesse an.
Wenn du nicht /var/run/docker.sock zur Kommunikation mit deinem Docker-Host verwendest, musst du einige Einstellungen in der Datei ./example/docker-compose.yml an deine Gegebenheiten anpassen.
Implementierung von Funktionen aus dem Docker Bench Security Script https://github.com/docker/docker-bench-security
[ ] 1.1 Ensure a separate partition for containers has been created
[ ] 1.2 Ensure the container host has been Hardened
[ ] 1.3 Ensure Docker is up to date
[ ] 1.4 Ensure only trusted users are allowed to control Docker daemon
[ ] 1.5 Ensure auditing is configured for the Docker daemon
[ ] 1.6 Ensure auditing is configured for Docker files and directories - /var/lib/docker
[ ] 1.7 Ensure auditing is configured for Docker files and directories - /etc/docker
[ ] 1.8 Ensure auditing is configured for Docker files and directories - docker.service
[ ] 1.9 Ensure auditing is configured for Docker files and directories - docker.socket
[ ] 1.10 Ensure auditing is configured for Docker files and directories - /etc/default/docker
[ ] 1.11 Ensure auditing is configured for Docker files and directories - /etc/docker/daemon.json
[ ] 1.12 Ensure auditing is configured for Docker files and directories - /usr/bin/docker-containerd
[ ] 1.13 Ensure auditing is configured for Docker files and directories - /usr/bin/docker-runc
[ ] 2.1 Ensure network traffic is restricted between containers on the default bridge
[ ] 2.2 Ensure the logging level is set to 'info
[ ] 2.3 Ensure Docker is allowed to make changes to iptables
[ ] 2.4 Ensure insecure registries are not used
[ ] 2.5 Ensure aufs storage driver is not used
[ ] 2.6 Ensure TLS authentication for Docker daemon is configured
[ ] 2.7 Ensure the default ulimit is configured appropriately
[ ] 2.8 Enable user namespace support
[ ] 2.9 Ensure the default cgroup usage has been confirmed
[ ] 2.10 Ensure base device size is not changed until needed
[ ] 2.11 Ensure that authorization for Docker client commands is enabled
[ ] 2.12 Ensure centralized and remote logging is configured
[ ] 2.13 Ensure operations on legacy registry (v1) are Disabled
[ ] 2.14 Ensure live restore is Enabled
[ ] 2.15 Ensure Userland Proxy is Disabled
[ ] 2.16 Ensure daemon-wide custom seccomp profile is applied, if needed
[ ] 2.17 Ensure experimental features are avoided in production
[ ] 2.18 Ensure containers are restricted from acquiring new privileges
[ ] 3.x ...
[x] 4.1 Ensure a user for the container has been created
[ ] 4.2 Ensure that containers use trusted base images
[ ] 4.3 Ensure unnecessary packages are not installed in the container
[ ] 4.4 Ensure images are scanned and rebuilt to include security patches
[ ] 4.5 Ensure Content trust for Docker is Enabled
[ ] 4.6 Ensure HEALTHCHECK instructions have been added to the container image
[ ] 4.7 Ensure update instructions are not use alone in the Dockerfile
[ ] 4.8 Ensure setuid and setgid permissions are removed in the images
[ ] 4.9 Ensure COPY is used instead of ADD in Dockerfile
[ ] 4.10 Ensure secrets are not stored in Dockerfiles
[ ] 4.11 Ensure verified packages are only Installed
[ ] 5.x ...
[ ] 6.x ...
[ ] 7.x ...