Drittanbieterinhalte sicher nutzen

Dies ist der letzte Teil einer vierteiligen Serie zum Aufbau Ihrer Kubernetes-AppSec-Strategie.

Die vorherigen Teile finden Sie hier:

• Containersicherheit während des gesamten SDLC

• Security Shift Left bedeutet Kultur, nicht nur Tools

• Von Image-Sicherheit zu Workload-Sicherheit

Ein Thema, das wir in unserer Diskussion über Anwendungssicherheit für Kubernetes noch nicht behandelt haben, sind die Unterschiede zwischen Anwendungen von Erst- und Drittanbietern.

Aus Sicht Ihrer Produktionssysteme gibt es zwischen den beiden kaum einen Unterschied. Ganz gleich, ob Sie die Anwendung selbst oder jemand anderes geschrieben hat: Es gibt viele Gemeinsamkeiten. In beiden Fällen hat die Anwendung Zugriff auf Produktionsdaten, und Schwachstellen darin können dazu führen, dass diese Daten oder zugehörige Systeme teilweise kompromittiert werden. Aus klassischer Betriebssicht ist es einfach, Anwendungen von Erst- und Drittanbietern gleich zu behandeln. Doch was ist, wenn wir einen Teil der Betriebsverantwortung auf Entwicklungsteams übertragen?

Anwendungspaketierung

In Kubernetes ist es üblich, Anwendungen von Drittanbietern mithilfe eines Tools wie Helm zu installieren. Das Repository Helm Charts enthält Konfigurationen für Hunderte von Anwendungen – von Aerospike bis zetcd – und spart damit viel Zeit. Auch Softwareanbieter, die Software für Verbraucher bereitstellen, paketieren ihre Anwendungen zunehmend mit Helm. Ein Helm-Chart enthält die für die Installation der Anwendung erforderliche Konfiguration, die wiederum üblicherweise auf eine Reihe von Drittanbieter-Images verweist. In jüngerer Zeit sehen wir ähnliche Ansätze bei der Arbeit an Cloud Native Application Bundles (CNAB).

Werfen wir einen kurzen Blick auf ein Beispiel für ein Helm-Chart, in diesem Fall für Linkerd.

$ tree
.
├── Chart.yaml
├── README.md
├── templates
│ ├── NOTES.txt
│ ├── _helpers.tpl
│ ├── config.yaml
│ ├── daemonset.yaml
│ ├── ingress.yaml
│ └── service.yaml
└── values.yaml

1 directory, 9 files.

Welche Inhalte des Charts könnten sich auf die Sicherheit auswirken? In der Datei Values.yaml finden wir Angaben zu einigen Container-Images, die Schwachstellen enthalten können:

image: buoyantio/linkerd:1.1.2
image: buoyantio/kubectl:v1.6.2

Die Datei values.yaml legt außerdem sinnvolle Ressourcenlimits fest

resources:
limits:
cpu: 500m
memory: 512M

Die Templates, insbesondere das DaemonSet, enthalten eine Containerspezifikation, für die verschiedene Sicherheitseigenschaften konfiguriert werden können. Dazu gehört unter anderem, ob Container als Root ausgeführt werden, ein schreibgeschütztes Dateisystem haben, nur die benötigten Berechtigungen anfordern oder eine Pod-Sicherheitsrichtlinie festlegen.

Anwendungen von Drittanbietern während des gesamten SDLC

Wie lassen sich diese Überlegungen zur Paketierung unserem SDLC zuordnen, und wie setzen wir Sicherheit während des gesamten Lebenszyklus durch?

• Lokal – wenn Sie Charts von Drittanbietern verwenden, arbeitet möglicherweise keines Ihrer Entwicklungsteams lokal daran.

• CI/CD – je nachdem, wie Sie die Charts installieren, verweisen Sie möglicherweise in einer Konfigurationsdatei darauf (zum Beispiel in Helmfile oder Terraform). Wahrscheinlich führen Sie dort jedoch keine Tests durch, abgesehen von möglichen Smoke-Tests.

• Registries – Helm-Charts verweisen in der Regel auf Images in öffentlichen Repositories. Diese lassen sich normalerweise durch interne Images ersetzen. Sie benötigen dann jedoch einen Prozess, um Ihre internen Kopien dieser Images aktuell zu halten.

Bei einer eigenständigen Anwendung kann es gut sein, dass Sie heute erst bei der Bereitstellung in der Produktion erstmals auf Schwachstellen prüfen können. Dadurch entsteht eine Diskrepanz zwischen der Realität, Entscheidungen über Drittanbieterinhalte zunehmend den Entwicklern zu überlassen, und den Möglichkeiten unserer Tools, zeitnah Feedback dazu zu geben, ob diese Anwendungen von Drittanbietern sicher eingesetzt werden können.

Arten von Drittanbieteranwendungen

Vereinfacht gesagt lassen sich Anwendungen von Drittanbietern in zwei Gruppen einteilen:

• Eigenständige Anwendungen, die einen bestimmten, klar abgegrenzten Nutzen bieten, wie WordPress oder Jenkins.

• Direkte Abhängigkeiten einer Anwendung von Erstanbietern, zum Beispiel Redis oder PostgreSQL.

Wenn wir betrachten, wie Anwendungen von Drittanbietern in unsere Umgebungen gelangen, wird deutlich, warum diese Unterscheidung hilfreich ist. Eigenständige Anwendungen sind häufig eher für Betriebs- oder Plattformteams relevant. Sie werden von einem zentralen Team installiert und verwaltet, das die Anwendung anderen Entwicklungsteams als Service bereitstellt. Direkte Abhängigkeiten liegen häufiger in der Verantwortung der einzelnen Entwicklungsteams. Wenn wir die Sicherheit der Drittanbieter-Lieferkette verbessern wollen, müssen wir beide Perspektiven berücksichtigen.

Fazit

Was können wir gegen dieses Problem tun? Die Antwort lautet: mehr Automatisierung vorantreiben und Pipelines so gestalten, dass sich Drittanbieterinhalte frühzeitig in der Pipeline einfach validieren und testen lassen. Diese Pipeline sollte sowohl für eigenständige Anwendungen funktionieren (für die es möglicherweise noch keine Pipeline gibt) als auch für das Testen der Abhängigkeiten bestehender Anwendungen.

Um dieses Problem zu lösen, müssen wir die gesamte Software-Lieferkette betrachten. Wir brauchen lokale Tools, mit denen wir ein Helm-Chart, einen Operator oder ein ähnliches Paket aus Konfigurationen und Image-Referenzen auf Plausibilität prüfen können. Wir brauchen CI/CD-Pipelines, die wir bei Bedarf schnell einrichten können, um zu verstehen, wie sich Änderungen an Drittanbieterinhalten auf das Risiko ihrer Nutzung auswirken. Außerdem brauchen wir schlankere Pipelines, um externe Images in unsere Vertrauensbasis aufzunehmen. Es wäre wünschenswert, wenn Standards für den Austausch vertrauenswürdiger Schwachstellendaten entstünden.

Es ist möglich, Anwendungen von Drittanbietern auch in einer Umgebung sicher einzusetzen, in der Verantwortlichkeiten rasch auf Entwickler übertragen werden. Dafür müssen Sie jedoch den dafür erforderlichen Prozess berücksichtigen und möglichst viele seiner Schritte in den Secure SDLC integrieren.