Kubernetes-Pod-Sicherheitsstandards verstehen

Kubernetes „überwand 2021 die Akzeptanzhürde“, nachdem 5,6 Millionen Entwickler die Plattform zur Orchestrierung ihrer Container nutzten, so die Cloud Native Computing Foundation (CNCF). Die jährliche CNCF-Umfrage ergab, dass beeindruckende 96 % der Unternehmen Kubernetes entweder in Betracht zogen oder bereits einsetzten.

Mit zunehmender Beliebtheit wird Kubernetes jedoch auch für Hacker und böswillige Akteure attraktiver. Wenn Entwickler Kubernetes als bevorzugte Container-Orchestrierungsplattform nutzen, müssen sie auch sicherstellen, dass sie die Plattform sicher einsetzen.

Kubernetes-Pod-Sicherheitsstandards sind ein wichtiger Baustein für die Kubernetes-Sicherheit. Sie umfassen drei aufeinander aufbauende Richtlinien, die von vollständig strikt bis zu relativ offen reichen. Sehen wir uns an, was die Kubernetes-Pod-Sicherheitsstandards sind, wie der Pod-Security-Admission-Controller ihre Durchsetzung gewährleistet und für welche Anwendungsfälle sich die einzelnen Richtlinien eignen.

Was sind Kubernetes-Pod-Sicherheitsstandards?

Kubernetes-Pod-Sicherheitsstandards sind Richtlinien und Leitlinien zur Aufrechterhaltung der Container-Sicherheit und -Integrität in Kubernetes-Clustern. Die Standards definieren drei unterschiedliche Profile mit verschiedenen Einschränkungen. So sollen containerisierte Workloads vor bekannten Privilegienausweitungen geschützt werden und aktuelle Best Practices zur Pod-Härtung einhalten:

• Privileged: Ermöglicht eine vollständig uneingeschränkte Richtlinie.

• Baseline: Bietet möglichst wenige Einschränkungen und verhindert gleichzeitig bekannte Privilegienausweitungen.

• Restricted: Orientiert sich an aktuellen Best Practices zur Pod-Härtung, kann jedoch die Kompatibilität einschränken.

Die Einhaltung dieser Standards trägt dazu bei, dass containerisierte Anwendungen die branchenüblichen Sicherheitsanforderungen in Kubernetes-Umgebungen erfüllen. Zu diesem Zweck bietet Kubernetes einen integrierten Pod-Security-Admission-Controller, der die Isolationsstufen von Pods anhand dieser Pod-Sicherheitsstandards überprüft.

In früheren Kubernetes-Versionen übernahm PodSecurityPolicy diese Aufgabe. Kubernetes stufte dieses Feature in v1.21 als veraltet ein und entfernte es in v1.25 vollständig. In einem Blogbeitrag erklärte die Kubernetes SIG Security, dass der ursprüngliche Admission-Controller unter „erheblichen Problemen bei der Benutzerfreundlichkeit“ litt. PodSecurityPolicy war verwirrend, gewährte leicht versehentlich weitergehende Berechtigungen als beabsichtigt und erschwerte es, in einer bestimmten Situation geltende Berechtigungen zu prüfen. Eine nachträgliche Überarbeitung von PodSecurityPolicy zur Behebung dieser Probleme wäre ein komplexes Projekt gewesen, bei dem andere Features hätten beeinträchtigt werden können. Deshalb wurde PodSecurityPolicy als veraltet eingestuft und ersetzt. 

Die Pod-Sicherheitsstandards bauen auf den Standardstufen der als veraltet eingestuften PodSecurityPolicy auf und vereinfachen so den Wechsel für Altsysteme, die PodSecurityPolicy verwenden. Der integrierte Pod-Security-Admission-Controller setzt diese Standards in Clustern oder Namespaces durch.

Arbeiten mit dem Pod-Security-Admission-Controller

Sobald der Pod-Security-Admission-Controller aktiviert und der Webhook installiert ist, können wir den Admission-Control-Modus in unseren Namespaces konfigurieren:

• Enforce: Lehnt Pods mit Richtlinienverstößen ab.

• Audit: Lässt Pods mit Richtlinienverstößen zu, fügt dem Audit-Log-Ereignisdatensatz jedoch eine Audit-Annotation hinzu.

• Warn: Lässt Pods mit Richtlinienverstößen zu, warnt jedoch die Benutzer.

Zur Konfiguration des Pod-Security-Admission-Controllers müssen zwei Labels festgelegt werden:

• Level: Privileged, Baseline oder Restricted.

• Mode: Enforce, Audit oder Warn.

Ebenso können wir für jeden Namespace mehrere Sicherheitsprüfungen festlegen. Außerdem können wir die Version angeben und anhand der Richtlinie prüfen, die mit dieser Kubernetes-Minor-Version ausgeliefert wurde.

Wenn wir beispielsweise wissen möchten, ob der Namespace „my-namespace“ die aktuelle Baseline-Version der Pod-Sicherheitsstandards erfüllt, können wir diese Warnung einrichten:

1kubectl label --overwrite ns my-namespace \
2   pod-security.kubernetes.io/warn=baseline \
3   pod-security.kubernetes.io/warn-version=latest

Wenn wir die Sicherheitsstufe „Baseline“ durchsetzen, in den Logs jedoch benachrichtigt werden möchten, um die Sicherheitsstufe zu überprüfen und festzustellen, ob wir den Standard Restricted erfüllen können, lässt sich das so einrichten:

1 kubectl label --overwrite ns my-namespace \
2   pod-security.kubernetes.io/enforce=baseline \
3   pod-security.kubernetes.io/enforce-version=latest
4   pod-security.kubernetes.io/audit=restricted \
5   pod-security.kubernetes.io/audit-version=latest

Das Sicherheitsprofil Privileged verwenden

Da das Sicherheitsprofil Privileged bekannte Privilegienausweitungen zulässt, sollten wir es nur in begrenzten Anwendungsfällen einsetzen, in denen ausschließlich vertrauenswürdige Benutzer kritische Infrastruktur-Workloads ausführen. 

Das Richtlinienprofil Privileged der Kubernetes-Pod-Sicherheitsstandards bietet uneingeschränkte Berechtigungen, die für die Verwaltung sensibler Workloads erforderlich sind, und lässt gleichzeitig die Flexibilität für komplexe Aufgaben in kritischen Systemen. Stellen wir uns beispielsweise ein Unternehmen vor, das sensible Finanzdaten verwaltet. In diesem Fall müssen privilegierte und vertrauenswürdige Benutzer die System- und Infrastruktur-Workloads des Unternehmens verwalten, um deren Sicherheit zu gewährleisten.

Auch wenn diese Art von Zugriff manchmal notwendig ist, sollte das Unternehmen offenen Zugriff nur Benutzern gewähren, die ihn für ihre Aufgaben unbedingt benötigen. Bei einem weniger restriktiven Ansatz wie dem Profil Privileged ist es entscheidend, den Umfang der Berechtigungen zu begrenzen. 

Bei Verwendung eines Sicherheitsprofils Privileged sollten außerdem der Warn- und der Audit-Modus auf der Stufe Restricted des Pod-Security-Admission-Controllers aktiviert werden. Dadurch werden Benutzer aktiv über den Status jeder Aktion informiert, und alle Ereignisprotokolleinträge erhalten relevante Audit-Annotationen.

Schließlich müssen auch weitere Best Practices außerhalb der Pod-spezifischen Maßnahmen umgesetzt werden. Sie könnten beispielsweise eine Multi-Faktor-Authentifizierung (MFA) verlangen, um die potenziellen Risiken weitreichender Berechtigungen zu mindern.

Das Sicherheitsprofil Baseline verwenden

Die Richtlinie Baseline eignet sich ideal für Anwendungsbetreiber und Entwickler nicht kritischer Anwendungen, die ihre Umgebung absichern möchten, ohne sie unnötig komplex zu machen. Mit der Richtlinie Baseline können Benutzer typische containerisierte Workloads verwalten und sich gleichzeitig vor bekannten Privilegienausweitungen schützen. 

Nehmen wir beispielsweise an, unser Beispielunternehmen betreibt mehrere nicht kritische Microservices auf seiner Infrastruktur, um seine Geschäftsabläufe zu unterstützen. Das Richtlinienprofil Baseline trägt dazu bei, diese Workloads abzusichern, ohne dass Anwendungsbetreiber oder Entwickler erheblichen zusätzlichen Aufwand haben. Durch diese Richtlinie mit möglichst wenigen Einschränkungen begrenzt das Unternehmen potenzielle Risiken und verhindert, dass Angreifer sich über Schwachstellen in Container-Images oder andere Angriffsvektoren erhöhte Berechtigungen verschaffen. 

Angenommen, das Beispielunternehmen nutzt den Service eines Drittanbieters, der schreibgeschützten Zugriff auf in Kubernetes-Clustern gespeicherte Daten benötigt. Die Pod-Sicherheitsrichtlinie Baseline beschränkt privilegierte Zugriffe auf das vom Anbieter benötigte Maß und verhindert unbefugte Versuche des Anbieters – oder anderer Personen –, ihre Berechtigungsstufe über die Baseline-Anforderungen hinaus zu erhöhen.

Das Sicherheitsprofil Baseline bietet Unternehmen mit Standard-Workloads, darunter APIs und Webanwendungen, ebenfalls Flexibilität. Zusätzliche Konfigurationsmaßnahmen sind für diese Unternehmen nicht erforderlich, sofern sie sich nicht nach weiteren Tests und Analysen als notwendig erweisen.

Wichtig ist, dass das Sicherheitsprofil Baseline bewusst allgemein gehalten ist, um ein breites Spektrum an Workloads abzudecken. Daher enthält das Profil Baseline oft Einschränkungen, die für einen bestimmten Anwendungsfall nicht hilfreich sind. Statt standardmäßig auf das Profil Privileged zurückzugreifen – pauschaler Root-Zugriff wäre unsicher –, müssen Sie wahrscheinlich einige anwendungsspezifische Kontrollen entsprechend Ihrem konkreten Anwendungsfall konfigurieren.

Das Sicherheitsprofil Restricted verwenden

Das Richtlinienprofil Restricted ist das sicherste der drei Profile, da es aktuelle Best Practices zur Pod-Härtung durchsetzt. 

Nehmen wir an, unser Beispielunternehmen setzt mehrere containerisierte Workloads zur Verarbeitung sensibler Finanztransaktionen ein. Gleichzeitig betreibt es jedoch Altsysteme mit nicht containerisierten Anwendungen, die moderne Sicherheitsstandards nicht erfüllen. Die Pod-Sicherheitsrichtlinie Restricted stellt sicher, dass alle Container Best Practices einhalten, darunter Sandboxing, die Einschränkung von Benutzerkonten und die Kontrolle von Netzwerkberechtigungen.

Mit dem Sicherheitsprofil Restricted stellen Anwendungsbetreiber und Entwickler sicherheitskritischer Anwendungen unter anderem Folgendes sicher: 

• Alle Container innerhalb eines Pods sind schreibgeschützt.

• Die Linux-Capabilities sind auf die für den Betrieb des Containers erforderlichen Berechtigungen beschränkt.

• Der Hostname jedes Containers wird mithilfe einer Umgebungsvariablen explizit festgelegt.

• Bei der Erstellung von Pods müssen Ressourcen wie CPU- und Speicherverbrauch pro Prozess in einem Container angegeben werden.

Das sichere Richtlinienprofil Restricted bietet mehr Transparenz über potenzielle Angriffsflächen, insbesondere für Unternehmen mit anfälligen Workloads. Die Richtlinie setzt aktuelle Best Practices zur Pod-Härtung durch und trägt so zum Schutz vor Privilegienausweitungen und anderen böswilligen Aktivitäten bei. 

Zusätzliche Sicherheit erreichen Sie durch mehrschichtige Schutzmechanismen an verschiedenen Stellen. Dazu gehören das Entfernen unnötiger Anwendungsfunktionen außerhalb der Kernfunktionen und der Einsatz fortschrittlicher Funktionen zur Abwehr von Bedrohungen.

Mit Pod-Sicherheitsstandards arbeiten

Kubernetes-Pod-Sicherheitsstandards helfen Entwicklern, ihre containerisierten Anwendungen in der Kubernetes-Umgebung abzusichern. Die drei Sicherheitsprofile – Privileged, Baseline und Restricted – unterscheiden sich je nach Anforderungen der Benutzer in ihren Einschränkungen. Der Pod-Security-Admission-Controller aktiviert diese Standards in Clustern oder Namespaces, indem er sie je nach ausgewählter Stufe durchsetzt, überprüft oder Warnungen ausgibt. Bei Bedarf können Sie außerdem eine Version angeben.

Unternehmen können mithilfe der Pod-Sicherheitsstandards die Einhaltung branchenüblicher Sicherheitsanforderungen gewährleisten und sich gleichzeitig vor potenziellen Privilegienausweitungen und anderen böswilligen Aktivitäten schützen. Letztlich vereinfacht der Einsatz von Pod-Sicherheitsstandards über den Pod-Security-Admission-Controller den Entwicklungsprozess und schützt gleichzeitig alle Workloads, die in Kubernetes-Clustern ausgeführt werden. 

Nachdem Sie Ihre Pod-Sicherheitsstandards in Kubernetes eingerichtet haben, erfahren Sie, wie Snyk Container dabei hilft, Schwachstellen in Containern während des gesamten Entwicklungsprozesses zu finden und zu beheben. Die Lösung bietet Einblicke und Empfehlungen, damit Ihre Container sicher bleiben.