Was ist Container-Sicherheit?

Container-Technologien haben in den vergangenen Jahren enormen Zuspruch erhalten. Nach mehreren Jahrzehnten eines verhältnismäßigen Dornröschenschlafs war es der Launch von Docker 2013, der Software-Entwicklung nach Container-First Methodik und zugehörige operative Strukturen sinnvoll implementierbar machte.

Mit dieser Entwicklung auf der Bildfläche erschienen sind jedoch auch neue Sicherheitsrisiken. Bei Millionen an verfügbaren Images ist die Absicherung von Containern komplexer denn je, gibt es doch mehrere Layer zu beachten. So etwa die folgenden:

• Container-Image und enthaltene Software

• Interaktion zwischen Container, Host-Betriebssystem und anderen Containern auf dem Host

• Host-Betriebssystem

• Netzwerk- und Storage-Repositories des Containers

• Runtime-Umgebung, häufig in Kubernetes-Clustern

Jeder Layer sollte dabei mit entsprechender Detailtiefe beleuchtet werden, und so konzentrieren wir uns in diesem Guide auf den ersten Aspekt: Image und Code. Ein einzelnes Container-Image kann hunderte oder sogar tausende an Schwachstellen enthalten. Werden diese ausgenutzt, sind Incidents die Folge (z. B. Datenpannen). Aber schon allein bei der Prävention geht so einiges an Produktivität verloren, etwa durch die reine Analyse der Schwachstellen in der immer größeren Anzahl an Images.

Sicherheit von Docker-Containern: Definition

Anwendungssicherheit fiel in der Vergangenheit vor allem in den Aufgabenbereich hierauf fokussierter Security-Teams. Angesichts der ihnen so eigenen Dev-Struktur kommt die Verantwortung dafür nun aber mehr und mehr Entwicklern und DevSecOps-Teams zu.

Dieser Wandel sowie die Update- und Deployment-Dynamik für Container erfordert eine ergebnisorientierte Security-Methodik. Hinausgehen muss sie über Container-Scans und Best Practices für Images umsetzen, die Schwachstellen umfassend aufdecken.

Für besonders praxisrelevante Schritte in diesem Kontext interessant sind auch unser Vorgänger-Guide für Container-Sicherheit mit Docker ebenso wie diese 3 Schritte zur Absicherung von Container-Images. In diesem Post finden Sie einen Überblick zu DevSecOps-Best-Practices zur Entwicklung und Ausführung sicherer Container-Images. Auch auf die dafür wichtigen Tools gehen wir ein: Snyk Container, Snyk IaC und unsere Zusammenarbeit mit Sysdig. Mit dem Ergebnis umfassender Container-Sicherheit von der Entwicklung bis zur Runtime.

Warum ist Container-Sicherheit so wichtig?

Container-Sicherheit ist von großer Bedeutung, da das Container-Image alle Komponenten enthält, die letztlich Ihre Anwendung ausführen. Finden sich dort Schwachstellen, sind Risikopotenzial und -schwere in der Produktion proportional größer. Die Produktion sollte dabei also auch nicht außen vor gelassen werden. Denn selbst wenn Sie Images ohne jedwede Schwachstellen oder umfassende Rechte und Privilegien erstellen, müssen Sie genau wissen, was sich in der Runtime abspielt.

Container-Sicherheit in verschiedenen Ökosystemen: Ein Überblick

Sicherheit von Docker-Containern

Docker verfügt über eine enorme Userbase mit Nutzern in zweistelliger Millionenhöhe und hunderten Milliarden an Image-Pulls. Angesichts dieser Zahlen zeigt sich klar: Containerisierung verändert die Anwendungsentwicklung grundlegend. Und so wird das Thema Security immer mehr wichtiges Augenmerk von Dev-Teams. Vor dem Übergang in Docker Hub oder andere Registries sind für Docker-Images Scans erforderlich. Nur so können Schwachstellen in Linux-Packages, Nutzerberechtigungen, Netzwerk-Konfigurationen, Open-Source-Tools und Zugriffsmanagement hinreichend adressiert werden. Und mit Schwachstellen natürlich auch wenig wünschenswerte Probleme in Ihrer Anwendung und Ihrer Infrastruktur, die sich sonst nach dem Release noch darin finden würden.

Sicherheit von Kubernetes-Containern

Kubernetes bietet verschiedenste Security-Mechanismen, die Ihnen bei der Absicherung Ihrer Cluster, Workloads und Container helfen. Wichtig zu beachten ist dabei, dass Kubernetes ohne konfigurierte Security-Kontrollen bereitgestellt wird, diese also noch manuell vorgenommen werden müssen. Auch bietet Kubernetes zwar diese Kontrollen und Features zur Cluster-Absicherung, doch sind die Standard-Konfigurationen oft nur unzureichend. Und so ist für das Workload-Deployment durchaus Kubernetes-Expertise gefragt. Weitere Informationen zu Security Best Practices für Kubernetes finden Sie hier.

Sicherheit von GKE-Containern

Google Kubernetes Engine (GKE) bietet ihren Nutzern viele Tools zur Workload-Absicherung. Eingesetzt werden sollten sie am besten in Layern durch Konfiguration von Security-Features für Zugriffskontrollen, Workloads und andere Security-Aspekte. GKE kann entweder im Standardmodus ausgeführt werden, bei dem Sie selbst die zugrunde liegende Infrastruktur verwalten, oder im Autopilot-Modus, bei dem GKE diese Aufgabe übernimmt. Mit der Snyk Container Kubernetes-Integration können Sie Workloads via GKE absichern, dies entweder im Standardmodus oder via Autopilot. Dabei können Sie Schwachstellen sowohl in Container-Images und Anwendungs-Code aufspüren als auch Ihre Kubernetes-Konfigurationen auf Probleme scannen.

Sicherheit von AKS-Containern

Ähnlich wie GKE verfügt auch Microsoft Azure Kubernetes Service (AKS) über solide Security-Features, etwa in Form seiner Integration mit Azure Policy sowie mit regelmäßigen Updates und Patches. Zum Upgrade von Cluster-Komponenten auf neue Versionen ist aber ein semi-manueller Prozess vonnöten. Hierfür müssen bei der Cluster-Erstellung Netzwerk-Policies aktiviert sein. Eine weitere Parallele zu GKE ist die Möglichkeit, mit Snyk Kubernetes-Konfigurationen und -Container zu scannen, ebenso wie automatisches Monitoring beim Deployment von AKS-Ressourcen.

Sicherheit von EKS-Containern

Auch Amazon Elastic Kubernetes Service (Amazon EKS) verfügt über starke Security-Features und nutzt das Modell der geteilten Verantwortung von AWS. Mit diesem wird definiert, wer in punkto Container-Sicherheit die Verantwortung für welche Elemente trägt. Für gewöhnlich obliegt dabei AWS die Verantwortung für die Sicherheit der Cloud selbst, während es Ihre Aufgabe als Kunde ist, für die Sicherheit der Abläufe in der Cloud zu sorgen.  Wie bei den oben erwähnten Kubernetes-Optionen ist Snyk auch mit Amazon EKS und Amazon Elastic Container Registry (Amazon ECR) integriert. Dem Scanning Ihrer Kubernetes-Konfigurationen und -Container steht somit nichts im Wege, genauso wenig wie automatisiertem Monitoring beim Deployment auf Amazon EKS.

5 Best Practices für Container-Sicherheit

Bei der Erstellung von sicheren Container-Images lässt sich im Allgemeinen zwischen fünf wichtigen Schritten unterscheiden. Wir sehen sie uns im Folgenden ein wenig genauer an:

1. Absicherung von Code und Abhängigkeiten

2. Beginn mit einfachem Base-Image aus vertrauenswürdiger Quelle

3. Verwaltung aller Layer zwischen Base-Image und Code

4. Zugriffsmanagement nutzen

5. Container-Infrastruktur sichern

1. Absicherung von Code und Abhängigkeiten

Per Containerisierung lassen sich cloudnative Anwendungen schneller bereitstellen. In diesem Vorteil findet sich auch der häufigste Use Case. Den definitorischen Umfang von Anwendungs-Code haben Container nicht geringfügig erweitert. Kontrolliert wird er dabei nach wie vor freilich vorrangig von Entwicklern. Open-Source-Abhängigkeiten können dabei dem eigenen Code ein ganz schönes Gewicht aufschnallen. Integrierte Scans mit Software Composition Analysis (SCA) und Static Application Security Testing (SAST) sind also umso wichtiger, um die Analyse von Code und Abhängigkeiten zu automatisieren. Über Container-Scans lassen sich zudem auch Probleme direkt in Git-Commits und -Repositories ausmachen – mit weiteren positiven Effekten für den Dev-Prozess.

2. Beginn mit einfachem Base-Image aus vertrauenswürdiger Quelle

Nicht nur für Portabilität und Download-Geschwindigkeit ist die Image-Größe wichtig, sie limitiert außerdem auch die potenzielle Schwachstellen-Spannweite. Jedes Container-Image sollte sich idealerweise auf Code und Mindestanzahl an zusätzlichen, zur Ausführung einer Anwendung notwendigen Packages beschränken. In der Praxis wird man aber meist eine große Anzahl an Anwendungen auf einen gemeinsamen verwaltbaren Base-Nenner bringen müssen.

Bei der Auswahl eines Base-Images gibt es glücklicherweise viele vertrauenswürdige Anbieter. Docker Hub ist dabei mit über 3,8 Millionen Images, mehr als 7 Millionen Repositories und etwa 11 Milliarden Pulls pro Monat der beliebteste. Hierzu gehören unter anderem ausgewählte, offizielle Images, die von Docker als Open-Source-Images und modular einsetzbare Solution-Repositories veröffentlicht werden. Auch Images hoher Qualität mit Maintenance durch verifizierte Publisher sind vorhanden. Die Richtlinien von Docker für diese verifizierten Publisher bilden einen hervorragenden Ausgangspunkt zur Definition Ihrer eigenen Best Practices für Container-Images.

In Docker Hub finden sich Images für verschiedenste Use Cases. Einen Blick sollte man dennoch immer auch auf ihren Ursprung werfen. Handelt es sich um ein offizielles Image von Docker? Lassen sich Quelle und Inhalte mit einem Service wie Notary auf digitale Signaturen prüfen?

3. Verwaltung aller Layer zwischen Base-Image und Code

Base-Images bedürfen spezieller Abwägungen: Was auch immer sie enthalten, nimmt man als Entwickler auch zu sich „mit nach Hause“ in sein eigenes Image. Selbst im Falle eines sehr schlanken Images werden neben Ihrem Code und den notwendigen Installationen wohl noch zusätzliche Tools und Bibliotheken erforderlich sein. Auch hier ist natürlich eine Prüfung auf Schwachstellen unabdingbar.

Glücklicherweise lassen sich diese Zwischen-Layer aber recht gut kontrollieren. Die dabei aufgewendete Aufmerksamkeit in Entwicklung, Testing und Deployment will aber natürlich auch überlegt priorisiert werden. Jede Phase erfordert womöglich unterschiedliche Tools. Richtung Produktion sollte aber alles entfernt werden, was nicht absolut essenziell ist.

Der Beginn mit einem möglichst schlanken Image, erweitert nur um die notwendigsten Tools, macht dies naturgemäß leichter: Entweder durch Entfernung der Tools aus dem Dockerfile gefolgt von einem Rebuild oder durch Nutzung von Multistage-Builds zur Erfassung aller Phasen in einem zentralen, automatisierten Build-Prozess. Auch im Tooling und in Support-Packages im Zwischen-Layer finden Sie womöglich Schwachstellen. Diese können aber ignoriert werden, falls sie nicht in den Images in der Produktion enthalten sein werden. In diesem Blog-Post gehen wir auf weitere Best Practices für Multistage-Builds ein.

4. Zugriffsmanagement nutzen

Im Kontext von Containern sprechen wir beim Zugriff von den Rechten eines bestimmten Nutzers, einen spezifischen Schritt für eine bestimmte Container-Ressource auszuführen. Typischerweise handelt es sich dabei um Rechte zur Erstellung, zum Auslesen und Aktualisieren oder Löschen. Die Details des zugehörigen Zugriffsmanagements sind dabei abhängig von der Container-Plattform. Im Falle von Kubernetes agieren die Nutzer außerhalb des Clusters. Administratoren obliegt es, die entsprechenden externen Identitäten mit TLS-Zertifikaten, OAuth2 oder anderen Authentifizierungsmethoden zu verwalten.

Secrets und Netzwerkzugriff sollten auf dem Prinzip der geringsten Nutzungsrechte basieren, Administratorzugriff auf die Entwicklung von Infrastruktur beschränkt sein. Damit kein Container kompletten Zugriff auf alle Ressourcen hat, empfiehlt es sich, spezifische Rollen und Zuständigkeiten zuzuweisen und diese dann mit Tools konsequent durchzusetzen.

5. Container-Infrastruktur sichern

Neben der Absicherung des Container-Image oder des laufenden Containers ist es ebenfalls wichtig, den zur Ausführung aller Container notwendigen Infrastruktur-Stack effizient zu verwalten. Dies beginnt bei der Container-Registry, etwa Docker Hub, und muss sich dann end to end bis zur Produktionsorchestrierung mit Kubernetes erstrecken.

Container-Registries ermöglichen die sichere Speicherung und Weitergabe und machen so auch nahtlose Zusammenarbeit möglich. Einher geht dies aber auch mit dem Potenzial, Schwachstellen und Malware einzuschleusen und Secrets preiszugeben. Oft verfügen sie über integrierte Security-Features. Bei der Verbindung mit einer Registry sollte zudem auch immer ein entsprechendes Security-Protokoll wie TLS zum Einsatz kommen.  Weiter verfügt Kubernetes auch über Tools zur Erstellung und Durchsetzung von Security-Kontrollen sowohl auf Ebene des Clusters als auch auf der des Netzwerks. Weitere Details lesen Sie in unserem Artikel zur Sicherheit von Container-Registries.

Auch die Sicherheit des Systems bzw. des zugrunde liegenden Cloud-Services ist bei Containern absolut essenziell. Für Services sollten rollenbasierte Zugriffskontrollen zum Einsatz kommen.

Ein weiterer Punkt: Angreifer setzen tendenziell an Punkten zu Beginn der CI/CD-Pipeline an. Gerade auch diese Phasen zu Beginn der Entwicklung dürfen bei der Absicherung also nicht außer Acht gelassen werden. Bei der Entwicklung von Anwendungen und Containern muss vor der Nutzung von Code in der Anwendung und vor dem Deployment unbedingt ein Code-Scan durchgeführt werden. Weiter ist das Prinzip der geringsten Nutzerrechte ebenso entscheidend wie die Automatisierung von Security-Checks und Kontrollen in der Dev-Pipeline.

Container-Absicherung mit Snyk Container

Angesichts von Millionen an Container-Schwachstellen kann ihre Identifikation, Priorisierung und Behebung Entwickler mit einem kaum zu bewältigenden Aufwand konfrontieren. Snyk Container nimmt dem sein Gewicht und seine Komplexität: In einem Schritt erfasst und behebt die Technologie Anwendungs- und Container-Schwachstellen – auch wenn Sie keinen Zugriff auf den Original-Code in Ihren Containern haben.

Scans auf neue Schwachstellen werden mit Snyk Container fortlaufend ausgeführt, Fixes basierend auf Kontext und Gefahrenpotenzial priorisiert. Dank Problemerkennung in Open-Source-Abhängigkeiten sowie Abgleiche zwischen Schwachstellen und Dockerfile-Befehlen durch die Lösung können Entwickler Fixes nahtlos umsetzen. Mit Snyk Container wurden allein 2021 über 130 Millionen Container-Tests durchgeführt, 56 Millionen Schwachstellen von Snyk Container Nutzern behoben.

In Kombination mit Snyk Infrastructure as Code sichert Snyk Container Container-Konfigurationen ab. Integrationen bestehen mit vielen Kubernetes-Plattformen wie AKS und GKE, Container-Registries wie Docker Hub, GCR und Quay sowie Betriebssystemen für Container wie Amazon Linux und Ubuntu und vielen mehr. Integrierte Schwachstellen-Scans unterstützen Entwickler bei der Identifikation und Nutzung geeigneter Base-Images als Grundlage sowie zur Automatisierung von Upgrade-Prozessen.

Wie auch alle anderen Lösungen der Snyk Plattform setzt Snyk Container auf eine Developer-First Methodik mit DevSecOps als Framework. Die Technologie passt sich nahtlos in die IDE ein, prüft Pull-Requests vor der Zusammenführung, spricht Empfehlungen für Fixes aus und wendet automatische Tests auf CI/CD-Pipelines an. Für ausgeführte Container prüft Snyk Container fortlaufend auf bestehende oder neue Schwachstellen. Alerts werden via Slack, Jira, E-Mail und weitere wichtige Kanäle übermittelt, damit DevSecOps-Teams Schwachstellen rasch identifizieren und beheben können.

Sicherheit für die Container-Runtime: Snyk und Sysdig

Per Image-Feedback mit Snyk Container lassen sich bereits 70 % oder mehr aller Schwachstellen beheben. Doch 30 % der Runtime-Schwachstellen bleiben dabei nach wie vor unadressiert. Darin können sich freilich nach wie vor hunderte Schwachstellen mit Relevanz für tausende Container und unzählige Cluster befinden. Diese dann noch manuell zu identifizieren ist keine einfache Aufgabe: Welche Packages werden in einem ausgeführten Container verwendet? Welche Schwachstellen nehmen Einfluss auf die in der Runtime ausgeführten Packages? Bevor Entwickler für Fixes involviert werden können, müssen die für Live-Umgebungen verantwortlichen Security- und Ops-Teams zunächst noch alle Schwachstellen selbst ausfindig machen. Entwickler wiederum verfügen über keine umfassende Systems-Expertise, und so kann es Monate dauern, bis die Probleme behoben sind.

Durch unsere Zusammenarbeit mit Sysdig können wir nun zusätzliche Kontextdetails zur Runtime-Umgebung zugänglich machen und die Problembehebung in diesem Zuge vereinfachen. So ist im Rahmen dieser Partnerschaft eine Security-Lösung für den gesamten DevOps-Prozess entstanden. Die Kombination der Plattformen von Snyk und Sysdig sichert alle Komponenten ab – vom Code in der Dev-Umgebung bis hin zur Infrastruktur im Cluster.

In diesem Post gehen wir genauer auf unsere Zusammenarbeit mit Sysdig ein und erläutern ihre Vorteile für Container-Sicherheit über die Runtime-Umgebung hinaus.

Container-Sicherheit: Zusammenfassung

Container-Sicherheit bildet ein weit gespanntes Themenfeld. Allein bei Base-Images gibt es eine schiere Unmenge an Herausforderungen. Zur effizienten Absicherung Ihrer Images sollten diese wichtigen Punkte stets bedacht werden:

• Beginnen Sie mit Base-Images eines vertrauenswürdigen Anbieters und nutzen Sie digitale Signaturen zur Verifizierung.

• In punkto Base-Images ist Minimalismus Trumpf. Soweit möglich sollten diese daher nur die Standard-OS-Packages und die Version des von Ihnen jeweils benötigten Frameworks beinhalten. Alles Weitere können Sie dann darauf aufbauen.

• Scannen Sie Ihre Images stets frühzeitig und immer regelmäßig auf Schwachstellen.

• Implementieren Sie entsprechende Checks an verschiedenen Punkten im SDLC – von Desktop und CI über in Registries gespeicherte Images bis hin zu Containern oder Pods, die aktiv in Ihren Clustern ausgeführt werden.

• Entscheiden Sie sich für Scanning-Tools, die sich nicht auf Schwachstellen-Reporting à la Excel beschränken, sondern darüber hinaus auch Empfehlungen zur Mitigierung und für Base-Images aussprechen.

Sie möchten Ihre Container-Images im SDLC konsistenter absichern? Snyk Container automatisiert Container-Security mit Developer-First Methodik – mit einem starken Augenmerk auf Sicherheit und Produktivität gleichermaßen.

Container-Sicherheit: Glossar

• Container-Scanning: Identifizieren von Schwachstellen in Containern durch Scans von Images auf Packages und Abhängigkeiten

• Container-Monitoring: Erfassung von Metrics und System-Health für containerisierte Anwendungen und Architekturen

• Kubernetes: Ursprünglich von Google entwickeltes Open-Source-System zur Orchestrierung containerisierter Anwendungen in einem Cluster

• K8s: Abkürzung für Kubernetes

• Docker: Beliebteste Container-Plattform weltweit; demokratisiert Tooling und Prozesse im Kontext der Container-Erstellung und -Ausführung und hilft Entwicklern, diese Technologien effizient zu nutzen

• Dockerfile: Textdatei mit den für die Entwicklung eines Docker-Image notwendigen Konfigurationen.

• Google Kubernetes Engine (GKE): Managed Service von Google zur Ausführung von Kubernetes-Workloads via Google Cloud

• AKS: Managed Service von Microsoft Azure; begann als generischer Azure Container Service und wurde dann mit der Entwicklung von Kubernetes zur wichtigsten Plattform zur Container-Orchestrierung zu AKS

• AWS EKS: Managed Service von Amazon Web Services zur Ausführung von Kubernetes-Workloads mit AWS; Nutzung möglich mit oder ohne Services wie AWS Fargate (Lösung zur visuellen Isolierung der Kubernetes-Infrastruktur, rückt eigene Kubernetes-Pods der Nutzer in den Mittelpunkt)

• Container-Image: Statische Datei mit Anweisungen zur Ausführung eines Containers

• Container-Registry: Image-Repository eines Containers und Management-Tool zur einfachen Speicherung und Weitergabe von Container-Images

• Container-Runtime: Software zur Erstellung, Ausführung und Verwaltung von Containern auf Host-OS

• Shift Left: Kultur und Tools zur Integration von Security in Developer-Workflows

• DevSecOps: Zusammenführung von Development, Security und Operations im Rahmen eines Konzepts zur Automatisierung von Security im SDLC

Container-Sicherheit: FAQ