Snyk bei Snyk: Kubernetes-RBAC für Snyks Entwickler ermöglichen

Wie Onkel Ben einst sagte: „Mit großer Macht kommt große Verantwortung.“ Das gilt auch für die Kubernetes-API. Sie ist sehr leistungsfähig und ermöglicht es Ihnen, Erstaunliches zu entwickeln. Doch das hat seinen Preis: Auch böswillige Nutzer können die API für schädliche Zwecke einsetzen.

Hier kommt Kubernetes-RBAC (rollenbasierte Zugriffskontrolle) ins Spiel: Damit können Sie die API kontrolliert nutzen, indem Sie nach dem Prinzip der geringsten Rechte nur die erforderlichen Berechtigungen vergeben.

Mit Kubernetes können Nutzer Rollen innerhalb von Namespaces und Cluster-Rollen außerhalb von Namespaces definieren.

Damit wird das Problem jedoch nur verlagert: Jetzt brauchen wir gute Prozesse für RBAC-Ressourcen, denn ein einfacher RBAC-Fehler könnte schwerwiegende Sicherheitsfolgen haben. Stellen Sie sich vor, ein Entwickler weist dem standardmäßigen Servicekonto im standardmäßigen Namespace „versehentlich“ die Rolle des Cluster-Administrators zu. Welch ein Grauen!

Foto von https://unsplash.com/@arnykoor

Der vorgezeichnete Weg zu mehr Kubernetes-Sicherheit

Idealerweise möchten wir allen Entwicklern ermöglichen, RBAC-Berechtigungen nach ihren Vorstellungen zu erstellen und gleichzeitig Schutzmaßnahmen einzurichten, die unsichere Vorgehensweisen verhindern. Eine Möglichkeit dafür ist, bei jeder Änderung mit RBAC-Ressourcen eine Codeüberprüfung durch AppSec vorzuschreiben. Das könnte zwar funktionieren, hat aber einige Nachteile:

• AppSec wird zum Engpass und bremst die Entwickler aus.

• Sicherheit wird zu einer „Blackbox“, die nur AppSec versteht, da keine Richtlinien veröffentlicht werden, anhand derer sich erkennen lässt, worauf AppSec bei der Überprüfung solcher Änderungen achtet.

• Wir verstärken die Silos und hindern Entwickler daran, Verantwortung für Sicherheit zu übernehmen. Damit verschärft sich das Problem, dass AppSec zum Engpass wird und Entwickler ausbremst.

Die Kubernetes-RBAC-Sicherheitscheckliste

Bei Snyk standen wir vor ähnlichen Herausforderungen. Wir wollten unsere Entwickler befähigen, die Kubernetes-API zu nutzen, ohne sie auszubremsen. Zunächst stellten wir eine Liste mit Sicherheitsanforderungen für RBAC-Regeln zusammen. Sie ist recht kurz und orientiert sich hauptsächlich an den CIS Kubernetes-Benchmarks:

• Keine Platzhalter bei Ressourcen oder Verben

• Keine Verwendung integrierter Regeln, da sie zu viele Berechtigungen gewähren

• Keine Bindungen an Servicekonten im standardmäßigen Namespace (der leer sein sollte) oder im kube-system-Namespace (in dem sensible Workloads ausgeführt werden)

• Keine Bindung an das standardmäßige Servicekonto

• Keine Verwendung gefährlicher Berechtigungen, etwa zum Erstellen von Pods oder Lesen von Secrets

Nachdem wir die Liste zusammengestellt hatten, konnten wir damit einiges anfangen:

• Wir veröffentlichten sie als interne Richtlinie und verlangten, dass alle RBAC-Objekte diese Anforderungen erfüllen. So waren die Kriterien keine „Blackbox“ mehr.

• Wir baten unsere Entwickler und Security Engineers, Verstöße gegen diese Liste als Sicherheitsrisiko zu dokumentieren und AppSec darüber zu informieren.

• Wir holten Feedback ein und luden alle Entwickler ein, sich an der Liste zu beteiligen und sie zu aktualisieren, um Silos aufzubrechen.

• AUTOMATISIERUNG. Schließlich möchten wir Tests so einfach wie möglich machen, sobald eine Liste vorliegt.

Automatisierte Prüfung von Kubernetes-Konfigurationen mit Snyk IaC

Ende 2020 kündigte Snyk ein neues Produkt an: Snyk Infrastructure as Code (Snyk IaC). Snyk IaC enthält einen integrierten Regelsatz, mit dem sich IaC-Code prüfen lässt, darunter auch Kubernetes-Manifeste (und Terraform – aber das ist Thema eines anderen Blogbeitrags). Einer der Vorteile, bei Snyk zu arbeiten, ist der frühzeitige Zugriff auf neue Funktionen – und noch besser: die Möglichkeit, zum Produkt beizutragen.

Nachdem wir unsere Liste zusammengestellt hatten, wandten wir uns an das Snyk IaC-Team und besprachen unsere Kubernetes-RBAC-Checkliste. Und voilà! Snyk IaC erhielt fünf neue Prüfungen, mit denen wir unsere Sicherheitsprüfungen automatisieren und verhindern können, dass AppSec zum Engpass wird.

IaC-Sicherheit für Snyks Entwickler so einfach wie möglich machen

Snyk IaC kann Scans über GitHub Actions ausführen und Ergebnisse im Sarif-Format ausgeben, das sich in GitHub Security integrieren lässt. Wir wollten noch einen Schritt weiter gehen und Verstöße direkt in unseren PRs anzeigen – was Snyk IaC (noch) nicht kann. Unsere AppSec-Gruppe hat dafür eine eigene GitHub-Integration entwickelt. So werden Änderungen an unseren Kubernetes-Manifestdateien beim Commit automatisch mit Snyk gescannt. Bei einem Verstoß erhält der Entwickler eine hilfreiche Warnung im PR:

Jetzt können alle unsere Entwickler RBAC-Änderungen vornehmen, ohne dafür erst AppSec hinzuziehen zu müssen. Und AppSec kann beruhigt sein, denn Snyk passt auf uns auf.

Möchten Sie etwas Ähnliches für Ihr Team einrichten? Sehen Sie sich hier das Beispiel-Repository an und stellen Sie sicher, dass Sie ein Snyk-Konto haben – mit IaC können Sie kostenlos loslegen!