Übersetzt aus dem Englischen

https://cheatsheetseries.owasp.org/cheatsheets/Docker_Security_Cheat_Sheet.html

Einführung

Docker ist die beliebteste Containerisierungstechnologie. Bei sachgemäßer Verwendung kann es das Sicherheitsniveau erhöhen (im Vergleich zum Ausführen von Anwendungen direkt auf dem Host). Andererseits können einige Fehlkonfigurationen dazu führen, dass das Sicherheitsniveau herabgestuft oder sogar neue Schwachstellen eingeführt werden.

Das Ziel dieses Merkblatt ist es, eine benutzerfreundliche Liste mit häufigen Sicherheitsfehlern und bewährten Praktiken bereitzustellen, die Ihnen helfen, Ihre Docker-Container zu sichern.

Regeln

REGEL 0 – Host und Docker auf dem neuesten Stand halten

Um bekannte, Container-Escape-Schwachstellen zu verhindern, die in der Regel mit einer Eskalation auf Root-/Administratorrechte enden, ist das Patchen von Docker Engine und Docker Machine von entscheidender Bedeutung.

Außerdem teilen sich Container (im Gegensatz zu virtuellen Maschinen) den Kernel mit dem Host, daher treffen Kernel-Exploits, die innerhalb des Containers ausgeführt werden, direkt auf den Host-Kernel. Zum Beispiel führt ein Exploit zur Ausweitung von Kernel-Privilegien ( wie Dirty COW ), der in einem gut isolierten Container ausgeführt wird, zu Root-Zugriff auf einen Host.

REGEL 1 – Den Docker-Daemon-Socket nicht freigeben (auch nicht für die Container)

Docker-Socket /var/run/docker.sock ist der UNIX-Socket, auf den Docker lauscht. Dies ist der primäre Einstiegspunkt für die Docker-API. Der Besitzer dieses Sockets ist root. Jemandem Zugriff darauf zu gewähren, entspricht dem uneingeschränkten Root-Zugriff auf Ihren Host.

Aktivieren Sie den TCP- Docker-Daemon-Socket nicht. Wenn Sie einen Docker-Daemon mit -H tcp://0.0.0.0:XXX oder ähnlichem ausführen, stellen Sie unverschlüsselten und nicht authentifizierten direkten Zugriff auf den Docker-Daemon bereit. Wenn Sie dies wirklich, wirklich tun müssen, sollten Sie es sichern. Überprüfen Sie anhand der offiziellen Docker-Dokumentation, wie das geht .

Machen Sie /var/run/docker.sock nicht für andere Container verfügbar . Wenn Sie Ihr Docker-Image mit -v /var/run/docker.sock://var/run/docker.sockoder ähnlichem ausführen , sollten Sie es ändern. Denken Sie daran, dass das Mounten des Sockets schreibgeschützt keine Lösung ist, sondern nur die Ausnutzung erschwert. Äquivalent in der docker-compose-Datei ist etwa so:

volumes:
- "/var/run/docker.sock:/var/run/docker.sock"

REGEL 2 – Legen Sie einen Benutzer fest

Die Konfiguration des Containers für die Verwendung eines nicht privilegierten Benutzers ist der beste Weg, um Angriffe auf eine Rechteausweitung zu verhindern. Dies kann auf drei verschiedene Arten wie folgt erreicht werden:

Während der Laufzeit mit -u Option des docker run Befehls zB:

docker run -u 4000 alpine

Während der Bauzeit. Einfach Benutzer in Dockerfile hinzufügen und verwenden. Beispielsweise:

FROM alpine
RUN groupadd -r myuser && useradd -r -g myuser myuser
<HERE DO WHAT YOU HAVE TO DO AS A ROOT USER LIKE INSTALLING PACKAGES ETC.>
USER myuser

Aktivieren Sie die Unterstützung von Benutzernamensräumen ( --userns-remap=default) im Docker-Daemon Weitere Informationen zu diesem Thema finden Sie in der offiziellen Docker-Dokumentation

In Kubernetes kann dies im Sicherheitskontext mithilfe eines runAsNonRootFelds konfiguriert werden , z. B.:

kind: ...
apiVersion: ...
metadata:
  name: ...
spec:
  ...
  containers:
  - name: ...
    image: ....
    securityContext:
          ...
          runAsNonRoot: true
          ...

Als Kubernetes-Cluster-Administrator können Sie es mithilfe von Pod-Sicherheitsrichtlinien konfigurieren .

REGEL 3 – Beschränken Sie die Fähigkeiten (Gewähre nur bestimmte Fähigkeiten, die von einem Container benötigt werden)

Die Linux-Kernel-Fähigkeiten sind eine Reihe von Privilegien, die von Privilegierten verwendet werden können. Docker wird standardmäßig nur mit einer Teilmenge der Funktionen ausgeführt. Sie können es ändern und einige Funktionen löschen (mit --cap-drop), um Ihre Docker-Container zu härten, oder --cap-add bei Bedarf einige Funktionen hinzufügen (mit ). Denken Sie daran, keine Container mit dem --privileged Flag auszuführen - dies fügt dem Container ALLE Linux-Kernel-Funktionen hinzu.

Die sicherste Einrichtung besteht darin, alle Funktionen zu löschen --cap-drop allund dann nur die erforderlichen hinzuzufügen. Beispielsweise:

docker run --cap-drop all --cap-add CHOWN alpine

Und denken Sie daran: Führen Sie keine Container mit dem Flag --privileged aus !!!

In Kubernetes kann dies im Sicherheitskontext mit einem capabilities Feld konfiguriert werden , z. B.:

kind: ...
apiVersion: ...
metadata:
  name: ...
spec:
  ...
  containers:
  - name: ...
    image: ....
    securityContext:
          ...
          capabilities:
            drop:
              - all
            add:
              - CHOWN
          ...

Als Kubernetes-Cluster-Administrator können Sie es mithilfe von Pod-Sicherheitsrichtlinien konfigurieren .

REGEL 4 – Füge das Flag „no-new-privileges“ hinzu

Führen Sie Ihre Docker-Images immer mit --security-opt=no-new-privilegesaus, um zu verhindern, dass Berechtigungen setuid oder setgid Binärdateien eskalieren.

In Kubernetes kann dies im Sicherheitskontext mithilfe eines allowPrivilegeEscalationFelds konfiguriert werden , z. B.:

kind: ...
apiVersion: ...
metadata:
  name: ...
spec:
  ...
  containers:
  - name: ...
    image: ....
    securityContext:
          ...
          allowPrivilegeEscalation: false
          ...

Als Kubernetes-Cluster-Administrator können Sie die Kubernetes-Dokumentation zur Konfiguration mit Pod-Sicherheitsrichtlinien verwenden .

REGEL 5 – Deaktivieren der Kommunikation zwischen Containern (--icc=false)

Standardmäßig Inter-Container-Kommunikation (ICC) ist aktiviert - es bedeutet , dass alle Container miteinander (unter Verwendung sprechen können docker0 überbrückte Netzwerk ). Dies kann deaktiviert werden, indem der Docker-Daemon mit --icc=falseFlag ausgeführt wird. Wenn icc deaktiviert ist (icc=false), muss mit der Option --link=CONTAINER_NAME_or_ID:ALIAS mitgeteilt werden, welche Container kommunizieren können. Weitere Informationen finden Sie in der Docker-Dokumentation - Containerkommunikation

In Kubernetes können Netzwerkrichtlinien dafür verwendet werden.

REGEL 6 – Linux-Sicherheitsmodul verwenden (seccomp, AppArmor oder SELinux)

Deaktivieren Sie zunächst nicht das Standardsicherheitsprofil!

Ziehen Sie die Verwendung von Sicherheitsprofilen wie seccomp oder AppArmor in Betracht .

Anweisungen dazu in Kubernetes finden Sie in der Dokumentation zum Sicherheitskontext und in der Kubernetes-API-Dokumentation

REGEL 7 – Ressourcen begrenzen (Speicher, CPU, Dateideskriptoren, Prozesse, Neustarts)

Der beste Weg, um DoS-Angriffe zu vermeiden, besteht darin, die Ressourcen zu begrenzen. Sie können Speicher , CPU , maximale Anzahl von Neustarts ( --restart=on-failure:<number_of_restarts>), maximale Anzahl von Dateideskriptoren ( --ulimit nofile=<number>) und maximale Anzahl von Prozessen ( --ulimit nproc=<number>) begrenzen .

Weitere Informationen zu ulimits finden Sie in der Dokumentation

Sie können dies auch in Kubernetes tun: Zuweisen von Speicherressourcen zu Containern und Pods , Zuweisen von CPU-Ressourcen zu Containern und Pods und Zuweisen von erweiterten Ressourcen zu einem Container

REGEL 8 - Dateisystem und Volumes auf schreibgeschützt setzen

Führen Sie Container mit einem schreibgeschützten Dateisystem mit --read-only Flag aus. Beispielsweise:

docker run --read-only alpine sh -c 'echo "whatever" > /tmp'

Wenn eine Anwendung in einem Container vorübergehend etwas speichern muss, kombinieren Sie --read-only Flag mit --tmpfs wie folgt:

docker run --read-only --tmpfs /tmp alpine sh -c 'echo "whatever" > /tmp/file'

Äquivalent in der docker-compose-Datei ist:

version: "3"
services:
  alpine:
    image: alpine
    read_only: true

Äquivalent in Kubernetes im Sicherheitskontext ist:

kind: ...
apiVersion: ...
metadata:
  name: ...
spec:
  ...
  containers:
  - name: ...
    image: ....
    securityContext:
          ...
          readOnlyRootFilesystem: true
          ...

Wenn das Volume nur zum Lesen gemountet ist, mounten Sie es außerdem schreibgeschützt. Dies kann durch Anhängen :ro an Folgendes erfolgen -v:

docker run -v volume-name:/path/in/container:ro alpine

Oder mit --mountOption:

docker run --mount source=volume-name,destination=/path/in/container,readonly alpine

REGEL 9 – Verwenden Sie statische Analysetools

Um Container mit bekannten Schwachstellen zu erkennen, scannen Sie Bilder mit statischen Analysetools.

So erkennen Sie Fehlkonfigurationen in Kubernetes

kubeaudit
kubesec.io
Kube-Bank

So erkennen Sie Fehlkonfigurationen in Docker

inspec.io
dev-sec.io

REGEL #10 - Setzen Sie die Protokollierungsebene auf mindestens INFO

Standardmäßig ist der Docker-Daemon so konfiguriert, dass er einen Basis-Logging-Level von 'info' hat, und wenn dies nicht der Fall ist: Setzen Sie den Docker-Daemon-Log-Level auf 'info'. Begründung: Durch das Einrichten einer geeigneten Protokollebene wird der Docker-Daemon so konfiguriert, dass Ereignisse protokolliert werden, die Sie später überprüfen möchten. Eine Basisprotokollebene von 'info' und höher würde alle Protokolle außer den Debug-Protokollen erfassen. Solange dies nicht erforderlich ist, sollten Sie den Docker-Daemon nicht auf der Protokollebene 'debug' ausführen.

Regel 11 – Linkt das Dockerfile zur Build-Zeit

Viele Probleme können verhindert werden, indem Sie beim Schreiben des Dockerfiles einige Best Practices befolgen. Das Hinzufügen eines Sicherheits-Linters als Schritt in der Build-Pipeline kann viel dazu beitragen, weitere Kopfschmerzen zu vermeiden. Einige Punkte, die es wert sind, überprüft zu werden, sind:

Stellen Sie sicher, dass eine USER Anweisung angegeben ist
Stellen Sie sicher, dass die Basis-Image-Version angepinnt ist
Stellen Sie sicher, dass die Versionen der Betriebssystempakete angeheftet sind
Vermeiden Sie die Verwendung von ADD zugunsten von COPY
Vermeiden Sie Curl-Bashing in RUN Direktiven

So konfigurieren Sie die Protokollebene in docker-compose

docker-compose --log-level info up

Links

https://cheatsheetseries.owasp.org/cheatsheets/Docker_Security_Cheat_Sheet.html

OWASP Docker Security Sheet

Inhaltsverzeichnis