Mehr Sicherheit für Container
Kubernetes-Bodyguard
Unreifes System, wenig Best Practices, deutlich höherer Traffic: Kubernetes hat viele Nachteile gegenüber etablierten Lösungen. Zudem halten herkömmliche Sicherheitslösungen mit der Dynamik containerbasierter Umgebungen nicht Schritt. Unternehmen benötigen moderne Ansätze für Authentifizierung und Autorisierung, Cloud-native Sicherheits-Tools sowie Code-Überwachung.
Bereits 2018 erklärte Forrester Kubernetes zum Sieger bei der Containerorchestrierung. Doch eine Studie von Gartner aus dem vergangenen Jahr hebt die Unreife des Gesamtsystems sowie einen generellen Mangel an operativen Best Practices hervor. Zusätzlich kann die Einführung von Kubernetes sowohl den Traffic innerhalb der Anwendung als auch den Management-bezogenen Datenverkehr erheblich steigern. Schließlich ist Kubernetes so konzipiert, dass es eine Anwendung in kleine separate Teile aufspaltet, die über das Netzwerk oder die Private Cloud eines Unternehmens kommunizieren.
Die Protokollierung und Erkennung fehlerhaften Verkehrs zwischen Containern kann durchaus komplex sein. Sicherheits-Tools müssen jedoch alle kompromittierten Container und nicht autorisierten Verbindungen zwischen Pods erkennen. Zudem kann jede Anwendung innerhalb eines Containers eine andere Angriffsfläche besitzen. Gleichzeitig halten traditionelle Security-Lösungen mit der hohen Dynamik containerbasierter Umgebungen nicht mit. So haben neuartige und gezielte Angriffe oft leichtes Spiel.
Authentifizierung und Autorisierung
Um Kubernetes-bezogene Malware abzublocken, ist der erste Schritt eine verbesserte Authentifizierung und Autorisierung. Hierbei sind mehrere Sicherheitsebenen wichtig sowie eine rollenbasierte Zugriffskontrolle, die den Zugang zu Kubernetes-Clustern nur denjenigen ermöglicht, die ihn wirklich benötigen. Unternehmen sollten die Linux-Funktionen bei nicht-privilegiertem (Nicht-Root-)Zugriff stark einschränken und schreibgeschützte Mounts für Dateisysteme einsetzen. Jede Anwendung in einem Cluster ist nach Möglichkeit auch von anderen zu trennen oder zu isolieren. Die üblichen Schutzmaßnahmen wie Passwörter, Mehr-Faktor-Authentifizierung und Zertifikate sorgen dafür, dass unautorisierte interne und externe Nutzer nur schwer Zugang zu Systemen erhalten. Bei Bedarf können Unternehmen auch private Register zur Speicherung von Anwendungs-Images verwenden, wobei sie nur speziell autorisierten Mitarbeitern Zugriff gewähren.
Eine alternative Methode zur Authentifizierung bietet eine statische Token-Datei. Der API-Server liest hier Inhaber-Token aus einer Datei, wenn auf der Befehlszeile die Option token-auth-file=SOMEFILE angegeben wird. Derzeit sind Tokens unbegrenzt gültig, und die Token-Liste lässt sich nicht ändern, ohne den API-Server neu zu starten. Die Token-Datei ist eine csv-Datei mit mindestens drei Spalten: Token, Benutzername, Benutzer-uid, gefolgt von optionalen Gruppennamen. Bei mehr als einer Gruppe muss die Spalte in Anführungszeichen gesetzt werden, zum Beispiel: conf token,user,uid, „group1,group2,group3“. Bei Verwendung der Inhaber-Token-Authentifizierung von einem HTTP-Client erwartet der API-Server einen Autorisierungs-Header mit dem Wert Bearer THETOKEN. Das Inhaber-Token muss eine Zeichenfolge sein, die sich in einen HTTP-Header-Wert setzen lässt, wobei nur die Kodierungs- und Zitierungsmöglichkeiten von HTTP Verwendung finden dürfen.
Wenn zum Beispiel das Inhaber-Token 31ada4fd-adec-460c-809a-9e56ceb75269 lautet, würde es in einem HTTP-Header so erscheinen: Authorization: Bearer 31ada4fd-adec-460c-809a-9e56ceb75269.
Um das Bootstrapping für neue Cluster zu beschleunigen, enthält Kubernetes ein dynamisch verwaltetes Bootstrap Token. Diese Tokens werden als Secrets im Namensraum kube-system gespeichert. Dort lassen sie sich dynamisch erstellen und verwalten. Der Controller Manager enthält einen TokenCleaner-Controller, der Bootstrap-Token löscht, sobald sie ablaufen.
- Kubernetes-Bodyguard
- Cloud-native Sicherheit
- Überwachung von Code
Lesen Sie mehr zum Thema
