Das Prinzip der geringsten Berechtigung mit RBAC auf Kubernetes anwenden

Bei korrekter Konfiguration können unbefugte Benutzer weder auf eingeschränkte Anwendungsfunktionen zugreifen noch Rollen wechseln. Außerdem können sie nicht auf bestimmte Daten wie Dateien und API-Schlüssel zugreifen – es sei denn, dies ist für die Erfüllung einer zugewiesenen Aufgabe erforderlich. So lassen sich die absichtlichen und unbeabsichtigten Folgen unbefugter Aktionen verhindern.

In Einrichtungen vor Ort ist der Zutritt zu bestimmten Bereichen wie Serverräumen nur Mitarbeitenden gestattet, die für ihre Arbeit dort autorisiert sind. Einige kritische Bereiche solcher Einrichtungen sind ausschließlich erfahrenen oder leitenden Teammitgliedern der zuständigen Abteilungen zugänglich.

Dasselbe Prinzip gilt für PoLP. In einer Software zur Personalverwaltung können beispielsweise wahrscheinlich nur Personalverantwortliche auf Personalakten zugreifen. Ebenso lassen sich bestimmte Aktionen – etwa das Bereitstellen von Anwendungsversionen in der Produktionsumgebung – so konfigurieren, dass sie nur von erfahrenen Engineers ausgeführt werden können.

PoLP kommt auch in Software-as-a-Service-Anwendungen (SaaS) zum Einsatz, in denen Benutzer je nach ihren konkreten Aufgaben unterschiedliche Rollen haben.

Beim Schutz von Softwaresystemen gilt es, ein Gleichgewicht zu finden: Einerseits darf ein System für die Beteiligten nicht zu restriktiv sein, andererseits muss es vor Bedrohungsakteuren geschützt werden. Mit PoLP erreichen wir dieses Gleichgewicht: Das System bleibt sicher und zugleich werden Einschränkungen beim Zugriff auf ein Minimum reduziert.

Darüber hinaus trägt PoLP zu einer effizienten und zuverlässigen Betriebsleistung bei. Systeme sind weniger anfällig für Ausfallzeiten durch Malware-Angriffe oder riskante Benutzeraktivitäten, etwa das Übertragen unsicheren Codes in die Produktionsumgebung oder das Ändern von Admin-Passwörtern.

In diesem Artikel erfahren Sie, wie Kubernetes (K8s) das Prinzip der geringsten Berechtigung (PoLP) durch rollenbasierte Zugriffskontrolle unterstützt.

Das Prinzip der geringsten Berechtigung auf Kubernetes-Zugriffe anwenden

Kubernetes orchestriert Container-Workloads. Die Plattform ermöglicht es Unternehmen und Entwicklern, die Bereitstellung, Verwaltung und Skalierung containerisierter Anwendungen zu automatisieren. Daher benötigen verschiedene Mitglieder der Entwicklungs-, Betriebs- und IT-Teams Zugriff auf eine Kubernetes-Umgebung, wenn sie bereitgestellte Anwendungen erstellen oder warten.

Um optimale Sicherheit und den Schutz von Ressourcen zu gewährleisten, sollten Unternehmen bei der Nutzung von Kubernetes das Prinzip der geringsten Berechtigung umsetzen – unabhängig von der aktuellen Phase der Produktionsumgebung. Glücklicherweise bietet Kubernetes Möglichkeiten zur Authentifizierung und Autorisierung, um die Zugriffskontrolle zu ermöglichen. Teams sollten ausdrücklich festlegen, wer auf welche Betriebsressourcen und Berechtigungen zugreifen darf, wenn die Kubernetes-API verwendet wird. Außerdem sollten Unternehmen den nicht authentifizierten Zugriff deaktivieren – sowohl für Menschen als auch für Service-Accounts.

So verwaltet Kubernetes den Zugriff mit RBAC

Die rollenbasierte Zugriffskontrolle (RBAC) ist eine in vielen Systemen verwendete Methode, um Ressourcenberechtigungen anhand der Rollen einzelner Personen in der Umgebung festzulegen. Kubernetes verfügt über einen umfangreichen nativen RBAC-Mechanismus, mit dem sich Berechtigungen konfigurieren lassen, die festlegen, wie ein Benutzer oder eine Benutzergruppe mit Kubernetes-Objekten in einem Cluster interagieren darf. Die Nutzung dieses RBAC-Frameworks ist der erste Schritt zur Absicherung eines Clusters und seiner containerisierten Anwendungen.

Kubernetes-Objekte sind persistente Entitäten, die festlegen, welche containerisierten Anwendungen ausgeführt werden, welche Ressourcen ihnen zur Verfügung stehen und welche Richtlinien ihren Betrieb steuern. Im Wesentlichen definieren sie den gewünschten Zustand des Clusters. Über die Kubernetes-API lassen sich Objekte erstellen, ändern oder löschen.

In Kubernetes gibt es zwei Arten von Accounts: Benutzer-Accounts und Service-Accounts. Benutzer-Accounts sind für aktive menschliche Benutzer vorgesehen, Service-Accounts für Prozesse, die auf die Kubernetes-API zugreifen. Die Kubernetes-RBAC steuert den Zugriff dieser Accounts auf Ressourcen wie Pods, Secrets, Controller und benutzerdefinierte Ressourcendefinitionen (CRDs).

Berechtigungen in Kubernetes werden mit den Objekten Role oder ClusterRole definiert. Anschließend werden die festgelegten Berechtigungen mithilfe der Objekte RoleBinding und ClusterRoleBinding als Regeln zugewiesen. Die RBAC-API definiert die folgenden vier Arten von Kubernetes-Objekten:

• Role – verwaltet Berechtigungen für Ressourcen innerhalb eines einzelnen Namespace

• ClusterRole – verwaltet Berechtigungen für Ressourcen im gesamten Cluster

• RoleBinding – weist einem Account oder einer Gruppe innerhalb eines bestimmten Namespace eine Role zu

• ClusterRoleBinding – weist einem Account oder einer Gruppe eine ClusterRole für alle Namespaces im Cluster zu

In den nächsten beiden Abschnitten erfahren Sie, wie RBAC-Richtlinien durch die Einschränkung des Ressourcenzugriffs in Clustern dem Prinzip der geringsten Berechtigung entsprechen.

Berechtigungen definieren

Damit Berechtigungen korrekt eingerichtet sind, müssen Sie Kubernetes so konfigurieren, dass die Rolle jedes Teammitglieds unter Berücksichtigung des Prinzips der geringsten Berechtigung abgebildet wird. Roles und ClusterRoles sind eine äußerst effiziente Möglichkeit dafür. Roles gelten für Ressourcen innerhalb eines Namespace, ClusterRoles für Ressourcen im gesamten Cluster.

In diesem Abschnitt erfahren Sie, wie Sie mit Role und ClusterRole den Zugriff auf bestimmte Systembereiche einschränken.

Angenommen, ein Unternehmen stellt einen erfahrenen DevOps-Engineer ein, der alle Umgebungsvariablen und sonstigen Secrets einsehen können muss, während die Teammitglieder keinen Zugriff darauf haben. Als Mitglied des Betriebsteams muss dieser Engineer möglicherweise außerdem die Pods anzeigen können, die für die Anwendungs-Workload des Unternehmens erstellt wurden, um den Zustand der Container mit den Client-Anwendungen zu überwachen.

Definieren Sie dazu zunächst die Objekte Role und ClusterRole in Ihrer YAML-Datei. Das folgende Beispiel zeigt, wie Sie eine Role definieren, die Lesezugriff auf Secrets im Namespace „development“ ermöglicht:

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

Der obige Code gibt die API-Version an. RBAC verwendet die API-Gruppe rbac.authorization.k8s.io, um Autorisierungsrichtlinien über die Kubernetes-API zu konfigurieren. Anschließend wird als Definitionstyp Role festgelegt und der Namespace angegeben, für den die Role gilt: development. Dabei wird angenommen, dass development der Namespace für die Ressourcen ist, die das Entwicklungsteam nutzt. Als Nächstes erhält die Role den Namen secretpod-reader.

Der Abschnitt rules enthält die Ressourcen, für die die Regel gilt, sowie die Aktionen, die die Role für diese Ressourcen ausführen kann. Außerdem enthält dieser Abschnitt einige Verben für Regeln. Kubernetes verwendet Verben wie write, watch, read und delete, um Berechtigungen in übergeordneten Kategorien zu verwalten.

Das folgende Beispiel zeigt, wie Sie eine ClusterRole definieren, die Lesezugriff auf die Frontend-Pods im Cluster ermöglicht:

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

Beachten Sie, dass im obigen Code im Metadatenabschnitt kein Namespace angegeben ist. Das liegt daran, dass ClusterRoles keinem Namespace zugeordnet sind. Daher wurde im Metadatenabschnitt lediglich der Name der ClusterRole angegeben: pod-reader.

Als Nächstes können Sie die Role an die Gruppe der Ressourcen im Namespace „development“ binden und die ClusterRole dem Cluster zuweisen. Nun kann Ihr Team – und sonst niemand – die erforderlichen Secrets in den Entwicklungsressourcen einsehen. So wird das Prinzip der geringsten Berechtigung umgesetzt: Ihr Team erhält Zugriff auf die für Entwicklungsaufgaben notwendigen Ressourcen, während allen anderen Personen in Ihrem Unternehmen der Zugriff auf diese Pods und Ressourcen verwehrt bleibt.

Sie haben nun eine Role erstellt, mit der der DevOps-Engineer auf Secrets zugreifen kann, sowie eine ClusterRole, mit der das gesamte DevOps-Team Pods lesen kann. Im nächsten Abschnitt weisen Sie der Role und der ClusterRole die Berechtigungen zu.

Berechtigungen zuweisen

Ein RoleBinding ist beispielsweise dann nützlich, wenn ein bestimmter Mitarbeiter Zugriff auf die geheimen Schlüssel benötigt, die in der Konfiguration einer Anwendung verwendet werden. Dabei kann es sich um API-Schlüsselpaare oder Umgebungsvariablen handeln.

Außerdem müssen wir Cluster-Bindings verwenden, um Berechtigungen für einen gesamten Cluster zu erteilen. Ein Cluster-Binding kann jedem Benutzer mit der angegebenen ClusterRole erlauben, Pods überall im Cluster zu lesen – unabhängig vom Namespace.

Wenn der DevOps-Engineer ein Benutzer namens Sola ist, können Sie die oben erstellte Role dem Benutzer sola im Namespace „development“ zuweisen. Damit kann sola die Secrets in diesem Namespace lesen.

Beachten Sie, dass beim Namen sola die Groß- und Kleinschreibung beachtet werden muss. Die Definition des RoleBinding sieht wie folgt aus:

1apiVersion: rbac.authorization.k8s.io/v1
2kind: RoleBinding
3metadata:
4  name: secret-reader
5  namespace: development
6subjects:
7- kind: User
8  name: sola
9  apiGroup: rbac.authorization.k8s.io
10roleRef:
11  kind: Role
12  name: secret-reader 
13  apiGroup: rbac.authorization.k8s.io

Im obigen Code haben Sie:

• den Typ RoleBinding angegeben.

• eine Role namens secret-reader und den Namespace development angegeben, für den das RoleBinding gilt.

• sola im Abschnitt subjects als User angegeben. Sie können auch mehrere Subjects angeben.

• die entsprechende Role im Abschnitt roleRef an das Binding gebunden. Beachten Sie, dass sich die im Abschnitt roleRef an das Binding gebundene Role oder ClusterRole nach dem Erstellen des Bindings nicht mehr ändern lässt.

Das obige RoleBinding-Beispiel eignet sich für Anwendungsfälle, in denen ein bestimmtes Mitglied des Entwicklungsteams Zugriff auf geheime Schlüssel benötigt, die in der Anwendungskonfiguration verwendet werden – etwa API-Schlüsselpaare und Umgebungsvariablen.

Um Berechtigungen für einen gesamten Cluster zu erteilen, müssen Sie künftig ClusterBinding verwenden. Im folgenden Beispiel sehen Sie, wie ClusterBinding jedem Benutzer in der Gruppe ops das Lesen der Pods in allen Namespaces des Clusters ermöglicht. Beachten Sie, dass beim Namen ops die Groß- und Kleinschreibung beachtet werden muss:

1apiVersion: rbac.authorization.k8s.io/v1
2kind: ClusterRoleBinding
3metadata:
4  name: read-pods-global
5subjects:
6- kind: Group
7  name: ops
8  apiGroup: rbac.authorization.k8s.io
9roleRef:
10  kind: ClusterRole
11  name: pod-reader
12  apiGroup: rbac.authorization.k8s.io

Ein Cluster-Binding ist in Situationen wie im obigen Beispiel nützlich, in denen alle Teammitglieder Zugriff auf sämtliche Pods im Cluster erhalten müssen. Wenn jede einzelne Berechtigung korrekt festgelegt ist, können die Benutzer in der Gruppe die Pods einsehen und ihren Zustand beurteilen. So können sie die erforderlichen Berichte erstellen und ihre Überwachungsaufgaben erfüllen. Gleichzeitig stellen die Definitionen der ClusterRole sicher, dass die Benutzer weder die Pods noch die darin enthaltenen Anwendungen ändern können.

Ihre K8-Konfigurationen absichern

Rollenbasierter Zugriff kann wesentlich dazu beitragen, das Prinzip der geringsten Berechtigung umzusetzen. Glücklicherweise bietet das native RBAC-Framework von Kubernetes umfangreiche Funktionen dafür. Mit dem Erstellen und Binden von Rollen lässt sich sehr wirkungsvoll sicherstellen, dass nur die unbedingt erforderliche Anzahl von Benutzern den notwendigen Zugriff auf bestimmte Ressourcen erhält. Dadurch wird die Angriffsfläche für potenzielle Angreifer begrenzt, ohne die Aufgaben der Teammitglieder zu beeinträchtigen. Ein Beispiel zur Nutzung von Kubernetes RBAC finden Sie in unserem Bericht dazu, wie wir es bei Snyk einsetzen.

Weitere Informationen zur korrekten und sicheren Umsetzung des Prinzips der geringsten Berechtigung in Ihrer Kubernetes-Umgebung finden Sie bei Snyk und in weiteren Beiträgen im Snyk-Blog.

Kubernetes-Ressourcen:

• Kubernetes-Sicherheit

• Docker-Images in Kubernetes

• Leitfaden zur Kubernetes-Überwachung

• Kubernetes-SecurityContext-Einstellungen

• Kubernetes-Operatoren