Sicherheitsauswirkungen von Kubernetes-Operatoren

Artikel von

Chris Laux

15. Februar 2022

0 Min. Lesezeit

Die Verwaltung von Ressourcen in frühen Kubernetes-Versionen war unkompliziert: Wir konnten Ressourcen mit YAML definieren und diese Definitionen an den Cluster übermitteln. Das erforderte jedoch zu viel manuelle Arbeit auf einer zu niedrigen Abstraktionsebene.

Der nächste Schritt in der Entwicklung von Kubernetes war der Einsatz von Helm-Charts. Helm wird manchmal als „Paketmanager für Kubernetes“ bezeichnet und ermöglichte es Entwicklern, vollständige Anwendungs-Setups mithilfe einer Vorlagensprache zu teilen. So ließen sich Konfigurationen einfach weitergeben und Charts bequem mit einem einzigen Befehl bereitstellen.

Helm ist jedoch ein externes Add-on, dessen Möglichkeiten auf das beschränkt sind, was sich über die vorhandene Kubernetes-API implementieren lässt. Der logische nächste Schritt für Kubernetes war daher die Erweiterung der Kubernetes-API mithilfe von Operatoren. Damit konnten wir benutzerdefinierte Funktionen direkt im Cluster hinzufügen.

Kubernetes-Operatoren stellen ihre Regelkreise bereit, um Aufgaben auszuführen, die zuvor menschliche Operatoren übernommen haben. Um einen Kubernetes-Operator zu erstellen, definiert der Entwickler benutzerdefinierten Code, der mit der Kubernetes-API interagiert und den Lebenszyklus der Anwendung automatisch steuert. Dieser Code läuft üblicherweise in einem oder mehreren Pods im Cluster, kann mit entsprechender Authentifizierung aber ebenso von außerhalb mit dem Cluster interagieren.

Denken Sie, dass diese Konstellation eine potenzielle Angriffsfläche für Sicherheitslücken bietet? Das ist richtig. Wie immer bringen neue Abstraktionen auch neue Kubernetes-Sicherheitsprobleme mit sich.

In diesem Beitrag sehen wir uns Beispiele für eine angemessene Eingrenzung von Operator-Berechtigungen an, beleuchten die gemeinsame Verantwortung von Operator-Entwicklern und Endnutzern für die Sicherheit und zeigen einige Möglichkeiten, mit Operatoren Kubernetes-Dienste sicherer zu machen.

Kubernetes-Sicherheit mit RBAC

Wenn wir einen Kubernetes-Operator in einem Cluster bereitstellen, sollten wir allgemeine Kubernetes-Sicherheitskonventionen als Grundlage für unsere Überlegungen zum jeweiligen Operator betrachten. Sehen wir uns zunächst diese allgemeinen Aspekte an.

Das zentrale Berechtigungssystem in Kubernetes ist die rollenbasierte Zugriffskontrolle (RBAC), die beim Starten des Clusters aktiviert werden muss. Sie bietet zusätzliche Berechtigungsressourcen: Roles und RoleBindings, die nur für den Namespace gelten, in dem sie definiert sind, sowie ClusterRolesund ClusterRoleBindings, die für den gesamten Cluster gelten (und nur bei Bedarf verwendet werden sollten).

Roles legen fest, wie privilegierte Akteure auf Ressourcen zugreifen können, und RoleBindings weisen menschlichen oder softwarebasierten Akteuren Roles zu. Wie bei der allgemeinen Betriebssystemsicherheit ist es wichtig, nur die unbedingt erforderlichen Berechtigungen zu vergeben und gewährte Berechtigungen regelmäßig daraufhin zu überprüfen, ob sie noch benötigt werden.

Hier sehen Sie ein Beispiel für eine Rolle, die Lesezugriff auf die Pod-Ressourcen im angegebenen Namespace erlaubt:

1apiVersion: rbac.authorization.k8s.io/v1
2kind: Role
3metadata:
4  namespace: my-webserver
5  name: pod-reader
6rules:
7- apiGroups: [""]
8  resources: ["pods"]
9  verbs: ["get", "list"]

Der leere String für apiGroups verweist auf die zentrale API. Dazu passend können wir eine Rollenbindung definieren, die diese Rolle einem bestimmten Benutzerkonto zuweist:

1apiVersion: rbac.authorization.k8s.io/v1
2kind: RoleBinding
3Metadata:
4  namespace: my-webserver
5  name: read-pods
6subjects:
7- kind: User
8  name: emilio
9  apiGroup: rbac.authorization.k8s.io
10roleRef:
11  kind: Role
12  name: pod-reader
13  apiGroup: rbac.authorization.k8s.io

Bei der Bereitstellung von Operatoren sind oft eigene Rollen und Bindungen enthalten. Nutzer sollten diese sowie die Dokumentation prüfen, um genau zu erfahren, welche Berechtigungen ein Drittanbieter im Cluster gewährt.

Geltungsbereiche und Berechtigungen

Zur Sicherheit von Kubernetes-Operatoren gehört eine Vertrauenskette. Sie beginnt bei den Autoren des Operators und ihrem Repository und reicht über die Bereitstellung des Operators im Cluster des Nutzers bis hin zu vielen weiteren Aspekten. Ähnlich wie beim RBAC-System ist es sinnvoll, die Berechtigungen des Operators so weit wie möglich einzuschränken. Leider benötigen die meisten Kubernetes-Operatoren recht weitreichende Berechtigungen, um ihre Funktionen auszuführen. Entwickler müssen daher sorgfältig zwischen Sicherheit und Nutzen abwägen.

Wie Rollen und Rollenbindungen können Operatoren auf einen Namespace beschränkt sein (namespace-scoped) oder in allen Namespaces des gesamten Clusters arbeiten (cluster-scoped). Kubernetes-Anwendungen lassen sich in jeweils eigenen Namespaces unterbringen, um sie voneinander und vom Kubernetes-System zu isolieren.

Wenn möglich, sollten Operator-Entwickler namespace-scoped Varianten wählen. So wird verhindert, dass sich Probleme auf andere Bereitstellungen im selben Cluster ausweiten. Soll ein Operator Dienste für alle Bereitstellungen eines Clusters bereitstellen, sind cluster-scoped Operatoren erforderlich. Ein bekanntes Beispiel dafür ist eine Bereitstellung, die Anwendungen automatisch mit Zertifikaten versorgt.

Eine Möglichkeit, Pods und Container daran zu hindern, den Rest des Kubernetes-Systems zu manipulieren, ist der Einsatz von securityContexts, die sich auch auf Operator-Container anwenden lassen. Hier sehen Sie einen YAML-Ausschnitt, der die Berechtigungen eines Pods einschränkt:

1securityContext:
privileged: false
allowPrivilegeEscalation: false
runAsNonRoot: true
runAsUser: 1000
runAsGroup: 1000
readOnlyRootFilesystem: true

Wir gehen davon aus, dass der Container in diesem Beispiel auf dem Kubernetes-Cluster läuft, den er verwaltet. Mit diesem Ausschnitt verhindern wir, dass Prozesse Root-Berechtigungen erlangen und ihr Root-Dateisystem ändern. Wird der Operator aus irgendeinem Grund kompromittiert, sind die Möglichkeiten eines Angreifers, auf das Hostsystem einzuwirken, dadurch eingeschränkt.

Als Nächstes legen wir clusterweite Sicherheitsbeschränkungen für Pods fest. Vor Kubernetes-Version 1.21 wurde dies mit dem Objekt PodSecurityPolicy (PSP) umgesetzt. Dieses ist inzwischen veraltet. Der Nachfolger PodSecurityAdmission (PSA) ist in Kubernetes-Version 1.23 eine Beta-Funktion.

Leider ermöglicht das neue PSA nicht dieselbe detaillierte benutzerdefinierte Steuerung wie das YAML im obigen Beispiel. Stattdessen wählen wir aus drei neu definierten Richtlinienebenen – privileged, baseline und restricted – und wenden sie auf jeden Namespace an.

1apiVersion: v1
2kind: Namespace
3metadata:
4  labels:
5    pod-security.kubernetes.io/enforce: baseline
6    pod-security.kubernetes.io/warn: restricted

Unser Namespace ist in diesem Beispiel so konfiguriert, dass die Sicherheitsstufe baseline erzwungen und auf der treffend benannten Stufe restricted eine Warnung ausgegeben wird. Die genauen Definitionen dieser Richtlinien finden Sie in der Kubernetes-Dokumentation zu den Pod-Sicherheitsstandards.

Sicherheitsvorteile von Operatoren

Kubernetes-Operatoren bringen zwar Sicherheitsaspekte mit sich, können einen Cluster aber auch sicherer machen. Wie bereits erwähnt, übernehmen Kubernetes-Operatoren Aufgaben und Konfigurationen, die normalerweise menschlichen Operatoren zufallen – und bei denen Fehler regelmäßig vorkommen. Eine programmatisch ausgeführte Konfiguration und Steuerung ist zuverlässiger und reproduzierbarer als die Arbeit eines Menschen.

Korrekt entwickelte Operatoren vermeiden Fehler durch Nachlässigkeit – oder sogar durch böswilliges Handeln. Auch die Reaktionsgeschwindigkeit ist ein wesentlicher Sicherheitsfaktor. Software-Operatoren haben gegenüber menschlichen Operatoren einen deutlichen Vorteil, wenn es darum geht, auf Probleme zu reagieren, sie zu melden und zu beheben.

Die meisten Bereitstellungen in einem Cluster dienen dem täglichen Betrieb der Anwendung. Es ist jedoch auch möglich, dedizierte Sicherheitsmanagement-Dienste direkt im Cluster bereitzustellen. Am besten werden diese durch den Regelkreis eines Operators gesteuert.

Lösungen für sichere Kubernetes-Bereitstellungen

Durch die Entwicklung von Kubernetes-Operatoren lässt sich die Kubernetes-API um benutzerdefinierte Logik im Cluster erweitern. Bei unsachgemäßer Handhabung können böswillige Akteure diese zusätzliche Funktionalität ausnutzen. Als Entwickler können wir die Sicherheit unserer Kubernetes-Bereitstellungen jedoch mit Berechtigungsregeln und anderen Einschränkungen gewährleisten. Die zentrale Kubernetes-Funktion zur Verwaltung von Berechtigungen ist RBAC, mit der sich Berechtigungen festlegen lassen.

Operatoren können auch zur Sicherheit beitragen, indem sie manuelle Prozesse ersetzen, die häufig menschlichen Fehlern unterliegen. Sie ermöglichen es uns, dedizierte Sicherheitsdienste wie Snyk innerhalb eines Clusters auszuführen.

Snyk bietet Lösungen für die in diesem Beitrag beschriebenen potenziellen Sicherheitslücken und viele weitere. Dazu werden Entwickler auf Sicherheitsprobleme aufmerksam gemacht, sobald diese beim Programmieren auftreten. Insbesondere stellt Snyk einen Kubernetes-Operator bereit, den wir in unserem Cluster installieren können. Anschließend findet und meldet Snyk Sicherheitslücken, sobald sie in bestehenden oder neuen Workloads im Cluster auftreten.