Grundlagen der Container-Sicherheit: Orchestrierung

Wenn Sie gerade erst in diese Artikelreihe einsteigen, sollten Sie vielleicht am Anfang beginnen:
Grundlagen der Containersicherheit: Einführung
Grundlagen der Containersicherheit: Pipeline

Laut Tripwires Bericht „State of Container Security 2019“ betreibt derzeit knapp jede dritte Organisation (32 %) mehr als 100 Container in der Produktionsumgebung. Ein geringerer Anteil (13 %) betreibt mehr als 500. Und 6 % der besonders ambitionierten Anwender verwalten derzeit mehr als 1.000. Nur wenige Organisationen betreiben Container in großem Maßstab ohne dabei von einem Orchestrierungssystem unterstützt zu werden.

Die Orchestrierungsebene der Container-Sicherheit konzentriert sich auf die Umgebung, die für den täglichen Betrieb der Container verantwortlich ist. Den heute verfügbaren Daten zufolge nutzen Sie mit hoher Wahrscheinlichkeit Kubernetes als Orchestrator, wenn Sie Container einsetzen.

Es ist wichtig zu beachten, dass es auch andere Orchestratoren gibt, die meisten von ihnen jedoch ebenfalls auf Komponenten und Konzepten basieren, die von Kubernetes abgeleitet sind. Daher konzentrieren wir uns auf die Sicherheit von Kubernetes und seinen Komponenten.

Die Kubernetes-Umgebung

Kubernetes besteht aus zahlreichen beweglichen Teilen. Das erschwert die Absicherung – nicht nur aufgrund der Vielzahl der beteiligten Komponenten, sondern auch wegen der Art und Weise, wie diese miteinander interagieren. Einige kommunizieren über APIs, andere über das Dateisystem des Hosts. Sie alle stellen potenzielle Eintrittspunkte in die Orchestrierungsumgebung dar, die berücksichtigt werden müssen.

Einfache Kubernetes-Umgebung

Ein kurzer Überblick über die wichtigsten Komponenten, die besondere Aufmerksamkeit erfordern:

• API-Server und Kubelet
• Pods
• Etcd

Das heißt: Hol dir eine Tasse Kaffee, denn hierfür wirst du etwas mehr Zeit brauchen.

1. Authentifizierung ist nicht optional

Aufmerksamen Lesern dürfte dies bekannt vorkommen. Vielleicht haben Sie schon einmal von der zweiten Sicherheitsregel gehört, auch bekannt als „Tür abschließen“. Dieses Thema werden wir immer wieder aufgreifen, da es häufig vernachlässigt wird. Eine starke Authentifizierung ist unerlässlich. Wir beobachten, dass die Zahl der Sicherheitsvorfälle aufgrund unzureichender Sicherheitspraktiken bei Containern weiter steigt. Eine der häufigsten Ursachen ist die fehlende Authentifizierung, insbesondere bei Bereitstellungen in der Public Cloud.

Verlangen Sie starke Anmeldedaten und wechseln Sie diese regelmäßig. Der Zugriff auf den API-Server (über ungesicherte Konsolen) kann zu einer „Game-over“-Situation führen, da sich darüber die gesamte Orchestrierungsumgebung steuern lässt. Dazu gehören das Bereitstellen von Pods, das Ändern von Konfigurationen sowie das Stoppen und Starten von Containern. In einer Kubernetes-Umgebung ist der API-Server die „eine API, sie alle zu beherrschen“, die Sie unbedingt von Angreifern fernhalten sollten.

So sichern Sie den API-Server und Kubelet ab
Beachten Sie, dass diese Empfehlungen auf dem aktuellen Autorisierungsmodell von Kubernetes basieren. Ziehen Sie stets die neueste Dokumentation für die von Ihnen verwendete Version zurate.

• mTLS überall aktivieren
  - Eine eigene Zertifizierungsstelle pro Dienst verwenden – k8s, etcd, Anwendungen
  - Zertifikate regelmäßig erneuern und auf die Berechtigungen privater Schlüssel auf dem Datenträger achten
  
• Nur an sichere Adressen binden
  - Vorsicht bei den API-Konfigurationsoptionen „insecure-bind-address“ und „insecure-port“
  - Dies auf _alle_ Dienste anwenden (SSH, Vault, etcd)
  
• „Anonyme Authentifizierung“ deaktivieren
  - Klingt „anonyme Authentifizierung“ nach einer guten Idee?
  - Seit Version 1.5 standardmäßig deaktiviert; kann mit „--anonymous-auth=True“ manuell aktiviert werden
  
• Autorisierung aktivieren
  - Verwenden Sie nicht „--authorization-mode=AlwaysAllow“
  - Der API-Server sollte „--authorization-mode=RBAC,Node“ verwenden
  - Kubelet sollte „--authorization-mode=Webhook“ verwenden
  - Kubelet einschränken und nur den Zugriff auf Ressourcen auf dem eigenen Knoten erlauben.
  

Es ist wichtig zu beachten, dass diese Empfehlungen auf dem aktuellen Autorisierungsmodell von Kubernetes basieren. Ziehen Sie stets die neueste Dokumentation für die von Ihnen verwendete Version zurate.

• Kubernetes-Autorisierungsreferenz
• Referenz zur Kubelet-Authentifizierung und -Autorisierung

2. Pods und Berechtigungen

Pods sind eine Gruppe von Containern. Sie sind die kleinste Kubernetes-Komponente. Je nach verwendetem Container-Network-Interface-(CNI-)Plugin können standardmäßig alle Pods miteinander kommunizieren. Einige CNI-Plugins können mithilfe von „Network Policies“ dieses Standardverhalten einschränken. Dies ist wichtig, da Pods auf unterschiedlichen Kubernetes-Knoten (vergleichbar mit physischen Servern) ausgeführt werden können. Außerdem binden Pods häufig Secrets ein, die private Schlüssel, Authentifizierungstoken und andere vertrauliche Informationen enthalten können. Daher werden sie auch als „Secrets“ bezeichnet.

Das bedeutet, dass es bei Pods mehrere Sicherheitsaspekte zu berücksichtigen gibt. Bei F5 gehen wir zu Beginn der Bedrohungsmodellierung stets von einem kompromittierten Pod aus. Der Grund dafür ist, dass Anwendungsworkloads in Pods bereitgestellt werden. Da Anwendungsworkloads am ehesten nicht vertrauenswürdigen Zugriffen ausgesetzt sind, stellen sie auch den wahrscheinlichsten Angriffspunkt dar. Aus dieser Annahme ergeben sich vier grundlegende Fragen, die beantwortet werden müssen, um Maßnahmen zur Eindämmung potenzieller Bedrohungen zu planen.

1. Was könnte ein Angreifer bei Zugriff auf einen Pod in anderen Pods sehen oder tun?
2. Kann ein Angreifer auf andere Dienste im Cluster zugreifen?
3. Welche Secrets werden automatisch eingebunden?
4. Welche Berechtigungen wurden dem Dienstkonto des Pods erteilt?

Die Antworten auf diese Fragen zeigen Risiken auf, die ausgenutzt werden könnten, wenn ein Angreifer Zugriff auf einen Pod innerhalb des Clusters erlangt. Um die mit der Kompromittierung eines Pods verbundenen Bedrohungen einzudämmen, ist ein vielschichtiger Ansatz erforderlich, der Konfigurationsoptionen, die Kontrolle von Berechtigungen und Einschränkungen auf Systemebene umfasst. Beachten Sie, dass mehrere Pods auf demselben (physischen oder virtuellen) Knoten bereitgestellt werden können und sich somit den Zugriff auf das Betriebssystem – in der Regel ein Linux-Betriebssystem – teilen.

So mindern Sie Bedrohungen für Pods
Kubernetes umfasst eine Pod-Sicherheitsrichtlinienressource, mit der sich sicherheitskritische Aspekte eines Pods steuern lassen. Sie ermöglicht es Betreibern, die Bedingungen festzulegen, unter denen ein Pod ausgeführt werden muss, damit er im System zugelassen wird, und setzt einen Mindeststandard für den Sicherheitskontext des Pods durch. Gehen Sie niemals davon aus, dass die Standardeinstellungen sicher sind. Implementieren Sie sichere Mindeststandards und überprüfen Sie, ob die Erwartungen erfüllt werden, um sich vor Bedrohungen für Pods zu schützen.

Die konkreten Optionen einer Pod-Sicherheitsrichtlinie sollten folgende Punkte abdecken:

• Privilegierte Container vermeiden
  • Suchen Sie in der kube-api und/oder im kubelet nach der Einstellung „—allow-privileged“
  • Suchen Sie in der Pod-Spezifikation nach „privileged: true“.
  • Reduzieren Sie das Sicherheitsrisiko mit „--allow-privileged=false“
• Der standardmäßige Container-Benutzer bei Docker ist root
  • Vermeiden Sie es, Workloads als Root-Benutzer auszuführen
  • Die Pod Security Policy kann „runAsUser“, „runAsGroup“ und „runAsNonRoot: true“ verwenden.
  • Ähnliche Optionen können in einer Dockerfile definiert werden.
• Rechteausweitung innerhalb eines Containers verhindern
  • „allowPrivilegeEscalation: false“
• SELinux / AppArmor verwenden
  • SELinux verwendet Multi-Category Security, um Container voneinander zu isolieren.
  • Aktiviert lassen und die Zugriffsverweigerungen schrittweise beheben
  • Das Deaktivieren oder der Wechsel in den Permissive-Modus beeinträchtigt die Sicherheit erheblich.
• Symlink-/Entrypoint-Angriffe verhindern
  • Angreifer können die Entrypoint-Binärdatei überschreiben oder schädliche symbolische Links erstellen
  • Vermeiden Sie dies, indem Sie „readOnlyRootFilesystem: true“ festlegen.
• Vermeiden Sie host*-Konfigurationsoptionen
  • Angreifer mit Zugriff auf die Hostressourcen können mit höherer Wahrscheinlichkeit ihre Kompromittierung auf den Host und/oder benachbarte Container ausweiten
  • Vermeiden Sie Optionen wie hostPID, hostIPC, hostNetwork und hostPorts
• Schreibgeschützte hostPath-Einhängungen
  • Falls es erforderlich ist, Lese-/Schreibzugriff auf den Host zu konfigurieren, gehen Sie bei der Bereitstellung vorsichtig vor und machen Sie dies keinesfalls zur Standardpraxis.
  • Verwenden Sie „readOnly“ für alle allowedHostPaths, um Angriffe zu verhindern.
• Seccomp-Profile
  • Reduzieren Sie die Angriffsfläche, indem Sie die zulässigen Systemaufrufe einschränken.
  • Docker-Standardprofil reduziert einige Risiken, ist jedoch ein generisches Profil
  • Anwendungsspezifische Profile bieten den größten Sicherheitsvorteil

3. Etcd

Etcd ist der Speicher für Konfigurationen und Geheimnisse. Eine Kompromittierung kann hier das Auslesen sensibler Daten oder das Einschleusen schädlicher Daten ermöglichen. Beides ist problematisch. Um Bedrohungen für etcd zu minimieren, muss der Zugriff kontrolliert werden. Dies lässt sich am besten durch die Erzwingung von mTLS erreichen. Geheimnisse werden von Kubernetes in etcd Base64-codiert gespeichert. Erwägen Sie die Verwendung der Alpha-Funktion „Encryption Provider“, um beim Speichern sensibler Geheimnisse stärkere Schutzoptionen zu nutzen, oder ziehen Sie HashiCorp Vault in Betracht.

Lesen Sie den nächsten Blogbeitrag der Reihe:
Grundlagen der Containersicherheit: Workloads