Von Image-Sicherheit zu Workload-Sicherheit
31. Oktober 2019
0 Min. LesezeitDies ist der dritte Teil einer vierteiligen Reihe zum Aufbau Ihrer Kubernetes-AppSec-Strategie. Hier finden Sie Teil I und hier Teil II.
In einem unserer früheren Beiträge haben wir darüber gesprochen, wie sich die Paketierung von Anwendungen auf Entwicklerteams verlagert, während Unternehmen Container einführen. Doch nicht nur die Paketierung verlagert sich von der Systemadministration in die Entwicklung, sondern auch das Konfigurationsmanagement.
Kubernetes und die Herausforderung der Konfiguration
Die Kubernetes-API ist eine leistungsstarke Abstraktion für den Aufbau cloudnativer Systeme. Eine unbeabsichtigte Folge dieser umfangreichen API ist jedoch, dass Entwickler große Mengen an Konfigurationen manuell erstellen, hauptsächlich in YAML. Sehen Sie sich zum Beispiel diese Beschreibung eines Kubernetes-Deployments an:
apiVersion: apps/v1
kind: Deployment
metadata:
name: nginx-deployment
labels:
app: nginx
spec:
replicas: 3
selector:
matchLabels:
app: nginx
template:
metadata:
labels:
app: nginx
spec:
containers:
- name: nginx
image: nginx:1.7.9
ports:
- containerPort: 80
Diese Konfigurationsdateien werden häufig in Versionsverwaltungssystemen gespeichert, manchmal zusammen mit dem Anwendungscode, manchmal getrennt davon. Allein auf GitHub gibt es mehr als 1,5 Millionen öffentliche Kubernetes-Konfigurationsdateien.
Standardmäßig unsicher
Leider eröffnet die große Konfigurationsfläche von Kubernetes eine Reihe potenzieller Sicherheitsprobleme. Der Vortrag The Path Less Travelled von Ian Coldwater und Duffie Cooley fasst einige der Probleme mit den Kubernetes-Standardeinstellungen aus Sicherheitssicht gut zusammen. Zu den häufig nicht konfigurierten Eigenschaften gehören:
CPU- und Arbeitsspeicherlimits | Die Begrenzung der erwarteten CPU- und Arbeitsspeicherressourcen bietet sowohl betriebliche als auch Sicherheitsvorteile. Aus Sicherheitssicht geht es darum, die möglichen Auswirkungen von Denial-of-Service-Angriffen auf die Anwendung statt auf den Node oder sogar den gesamten Cluster zu begrenzen. |
runAsNonRoot | Standardmäßig laufen Container als Root-Benutzer. Diese Eigenschaft verhindert das zur Laufzeit des Containers. Kann ein Angreifer also einen Befehl im Kontext des Containers ausführen, stehen ihm nur begrenzte Berechtigungen zur Verfügung. |
readOnlyRootFilesystem | Standardmäßig ist das für den Container eingebundene Dateisystem beschreibbar. Das bedeutet, dass ein Angreifer, der den Container kompromittiert, auch auf die Festplatte schreiben kann, was bestimmte Angriffe erleichtert. Wenn Ihre Container zustandslos sind, benötigen Sie kein beschreibbares Dateisystem. |
Capabilities | Linux-Capabilities steuern auf niedriger Ebene, was Prozesse im Container tun dürfen – vom Schreiben auf die Festplatte bis zur Netzwerkkommunikation. Es ist möglich, alle Capabilities zu entfernen und nur die erforderlichen hinzuzufügen. Dafür müssen Sie jedoch die Liste der Capabilities kennen. |
Diese Konfigurationseigenschaften sind selbst keine Schwachstellen, erleichtern Angreifern aber in der Regel die Ausnutzung einer Schwachstelle in einem Image. Kommt es zu einem Exploit, können die Konfigurationseigenschaften den Schaden möglicherweise verstärken. Ihr Risikopotenzial hängt nicht nur von den vorhandenen Schwachstellen ab, sondern auch vom Kontext, in dem sie auftreten.
Konfiguration im gesamten SDLC
Da wir mehr Sicherheitsverantwortung auf Entwicklerteams übertragen, lohnt es sich, diese Herausforderung rund um sichere Konfiguration – ähnlich wie Schwachstellen in Images – aus der Perspektive des SDLC zu betrachten.
Phase | Beschreibung | Feedback | Vollständigkeit |
Lokal | Lokale Tools unterstützen das Erstellen sicherheitsbewusster Konfigurationen – von der Integration in Unit-Test-Workflows bis hin zu Hinweisen in IDEs. Sie lösen jedoch individuelle Probleme statt Problemen auf Team- oder Organisationsebene. | Schnell | Niedrig |
CI/CD | Lassen Sie den Build schnell fehlschlagen, wenn Konfigurationsdateien potenziell unsicher sind oder interne Richtlinien nicht erfüllen. Dies muss jedoch in allen relevanten Pipelines implementiert werden. | Schnell | Variabel |
Repository | Konfigurationen werden derzeit hauptsächlich in Versionsverwaltungssystemen gespeichert (wobei Helm 3 auch das Speichern von Images in kompatiblen OCI-Registries unterstützt). Wie helfen wir Entwicklern, sichere Konfigurationen zu schreiben, während sie Pull Requests einreichen und Branches erstellen? | Mittel | Mittel |
Admission | Kubernetes-Admission-Controller blockieren API-Anfragen und ermöglichen es, unzulässige unsichere Konfigurationen zu verhindern. Verschiedene Cluster haben jedoch möglicherweise unterschiedliche Richtlinien. Außerdem betreffen diese neue Anfragen, nicht aber bestehende Workloads. | Langsam | Hoch |
Produktion | Die Kubernetes-API bildet die laufende Konfiguration ab – hier sollten Sie der Konfiguration die größte Aufmerksamkeit widmen. Probleme an dieser Stelle können sich jedoch auf reale Workloads auswirken, und die Feedbackzyklen zu ihrer Behebung können lang sein. | Langsam | Hoch |
Wie bei der Prüfung von Container-Images gibt es auch hier an den verschiedenen Punkten unterschiedliche Zielkonflikte. Tests nur in einer Phase liefern möglicherweise schnelles Feedback, aber weniger Kontrolle – oder umgekehrt. Wie bei Schwachstellen in Images umfasst ein moderner und ausgereifter Sicherheitsprozess wahrscheinlich Konfigurationstests in mehreren Phasen.
Fazit
Unsere Anwendungen bestehen nicht nur aus den Images, mit denen wir sie paketieren, sondern auch aus der Konfiguration, mit der wir sie ausführen. Bisher haben wir diese beiden Bereiche meist getrennt betrachtet und abgesichert. Gespräche über Containersicherheit für Entwicklerteams konzentrieren sich jedoch in den meisten Fällen ausschließlich auf Schwachstellen in Images. Da die Verantwortung für Anwendungssicherheit zunehmend auf Entwicklungsteams übergeht, wird es immer wichtiger, den Zusammenhang zwischen Schwachstellen in Images und Konfiguration zu verstehen und Tools einzusetzen, die beides absichern.
Starten Sie mit Capture the Flag
Erfahren Sie in unserem virtuellen On-Demand-Workshop für Einsteiger, wie Sie Capture-the-Flag-Herausforderungen lösen.
