Moderne IT-Infrastrukturen sollen schnell, flexibel und skalierbar sein. Mit der Cloud samt Hypervisor-basierter Virtualisierung gibt es zwar auch ein Konzept, das diesen Ansprüchen genügt. Weil die Taktung der Digitalisierung aber immer weiter zunimmt, ist vielen die virtuelle Maschine (VM) oft schon zu schwerfällig. Dank Docker haben Container vor zwei Jahren jedoch ein Revival erfahren. Die Virtualisierung erreicht damit die nächste Stufe ihrer Evolution – und verändert sich rasant.

Der Docker Hub avancierte schnell zum Spielplatz für Virtualisierungstüftler und Developer, die sich mit der entstaubten Linux-Technologie austobten. Die Vorteile der virtuellen Leichtgewichte sorgten für einen Aufstieg der Container in der Entwickler-Welt. Ihre Stärken – klein und mit wenig Overhead im Gepäck – locken jetzt auch zunehmend die IT-Verantwortlichen aus der Ecke der klassischen Virtualisierung hervor. Speziell im Kontext von DevOps sowie Continuous Integration und Continuous Delivery (CI/CD) eignen sich Container und kommen deshalb auch in Unternehmen immer häufiger zum Einsatz.

Durch den neuen Zulauf auf Container müssen sich Nutzer aber auch immer mehr mit den Gefahren und Sicherheitslücken der Systeme beschäftigen. Wie jede andere Technologie müssen Container die gesetzlichen Vorgaben sowie interne Compliances und Sicherheitsstandards erfüllen.

Setzen Unternehmen Container bereits innerhalb geschäftskritischer Systemumgebungen ein, ist Vorsicht geboten. Jahrelang standen Cloud und Virtualisierung wegen mangelnder Sicherheit in der Kritik. Daher sind auch Container im Business-Kontext ein sensibles Thema. Um bestimmte Sicherheitsvorkehrungen kommt man also nicht herum. Das fängt schon mit eigentlich grundsätzlichen Dingen wie dem Härten der Systeme an – also der Erhöhung der Systemsicherheit durch den Einsatz von nur für den Betrieb nötigen Systemkomponenten. Ein weiterer und sehr entscheidender Punkt auf der Security-Checkliste sind die Images. Sie bilden die wichtigsten Bausteine für Container. Problematisch ist hier der freie Zugriff auf alle zugänglichen Repositorys. Dort kann jeder Images hoch- oder herunterladen. Das hat seine Vor- und Nachteile. Zum einen gibt es dort eine große Zahl verschiedener Images, sodass sich für die unterschiedlichsten Szenarien in der Regel ein passendes Image findet. Zum anderen sorgt diese Offenheit auch dafür, dass es dort – absichtlich oder unabsichtlich – fehlerhafte Images gibt. Sie sind der einfachste Weg, sich ein Sicherheitsproblem einzufangen. Daher sollten Unternehmen genau darauf achten, welche Images sie beispielsweise über den Docker Hub beziehen. Das gilt insbesondere für solche, die nicht frei einsehbar sind. Schon kleine Schreibfehler wie „RHAEL7“ statt korrekt „RHEL7“ innerhalb des Images reichen aus, um böswilligen Angreifern eine Tür zu öffnen.

Gerade zu Anfang des Container-Hypes gab es auf den Repositorys keinerlei Kontrollmechanismen. Wie groß das Problem anfälliger Images ist, zeigte sich im vergangenen Jahr bei einer Stichprobe der Firma Banyan: Mehr als ein Drittel der auf dem Docker Hub eingestellten Images offenbarten Lücken für Sicherheitsrisiken. Diese Zahlen sorgten für ordentlichen Zugzwang und die Image-Anbieter haben seitdem ihr Sicherheitslevel erhöht.

Hersteller wie Red Hat gehen das Sicherheitsproblem bei Containern mit Transparenz an: Sie zeigen, wie die Images gebaut werden, und unterstützen in ihren Betriebssystemen auch Sicherheitssoftware. (Foto: Red Hat)

So brachte Docker Anfang des Jahres mit der Version 1.10 ein Paket an Sicherheitsfunktionen mit auf den Markt. Darunter unter anderem das Secure Computing, welches Nutzern mehr Kontrolle über Applikationen innerhalb der Container einräumt. Über ein Whitelisting sind auf jeweilige Anforderungen zugeschnittene Systemaufrufe filterbar. Zudem ermöglicht der Secure Computing Mode das Einrichten von Sandboxes. In dem Release weitete Docker zusätzlich die Unterstützung für User Namespaces aus, die ebenfalls mehr Kontrolle über einzelne Applikationen und Prozesse geben. Auf diese Weise sind für Nutzer granulare Sicherheits-Policys einfacher einzurichten. Insgesamt gibt es heute einen deutlich größeren Handlungsspielraum, um anderen Nutzern Rechte einzuräumen oder sie zu beschränken. Diesen sollten Unternehmen entsprechend ausnutzen, um sicherzustellen, dass nur Befugte Zugriff auf bestimmte Container erhalten.

Vor allem die Container-Interaktionen gilt es zu beschränken: Unternehmen sollten die Kommunikation der Container zum Host, anderen Containern oder über das Internet nach außen kontrollieren. Um beim Host keinen Denial of Service (DoS) oder Forkbombs auszulösen, ist es wichtig, über Cgroup die Ressourcen (CPU, Memory) für Container zu konfigurieren. Diese Maßnahme muss auch bei der Interaktion mit anderen Containern erfolgen. Stichwort: „Noisy Neighbor“. Gleiches gilt für die Kommunikation über das Internet nach außen, um sich gegen DDoS-Angriffe (Distributed Denial of Service) zu wappnen. Generell ist es besser, die Zahl der Container mit Zugang zum Internet zu limitieren. Über die Namespaces sind Rollen und Rechte zuweisbar, um Zugriffe auf Informationen in anderen Containern oder dem Host zu kontrollieren. Hier gilt: Nur so viel Rechte wie wirklich nötig vergeben.

Hinsichtlich der Images hat sich ebenfalls einiges getan: So gibt es auf den Repositorys verschiedene Security-Scans, um Sicherheitslücken aufzudecken. Hersteller wie Ubuntu oder Red Hat legen ihre Images mittlerweile offen und geben tieferen Einblick in deren Bauweise. Derzeit plant Docker, als momentan größte Plattform für Images, einen Marktplatz für sichere Images. Diese werden dort auf ihre Vertrauenswürdigkeit hin überprüft und verifiziert. Aktuell läuft für den Store eine private Beta. Eine weitere Methode, sich vor anfälligen Images zu schützen, wäre das aktive Blocken bestimmter Repositorys. Dafür müssen Unternehmen entsprechende Policys festlegen, die beispielsweise nur den Einsatz selbst erstellter Images erlauben, und eigene Registries pflegen. So erhalten Nutzer ein eigenes, internes Repository, über das sie zentral notwendige Images sicher beziehen.

Seit der Container-Hype aufgekommen ist, bringen immer mehr Anbieter passende Tools auf den Markt, die gleichzeitig für mehr Sicherheit sorgen. Mittlerweile ist die Bandbreite an Tools und Lösungen, die der Nachfrage nach einer stärkeren Security-Kontrolle entsprechen, deutlich gewachsen. So unterstützt Red Hat in dem aktuellen Container-Betriebssystem „Atomic Host“ Software für Deep Container Inspection (DCI) sowie das Open Security Content Automation Protocol (OpenSCAP). Dieses identifiziert Sicherheitslücken von Containern. Darüber hinaus gibt es Orchestrierungs- und Management-Tools, die administrative Prozesse vereinfachen, automatisieren und so helfen, Fehler zu vermeiden. Oft enthalten sie aufgrund der wachsenden Nachfrage zusätzliche Sicherheitsfeatures. Eine der zentralen Aufgaben von beispielsweise Rancher ist es, bei Active Directory und LDAP (Lightweight Directory Access Protocol) Multitenancy sicherzustellen und dafür Zugriffsrechte bestimmter Personengruppen oder Environments einzuschränken. Darüber hinaus erfolgt die Kommunikation zwischen Containern über IPSec-Tunnel, die Rancher automatisch aufbaut.

Ältere Images können eine Gefahr für Container darstellen. Daher sollten Unternehmen die Basis-Images täglich neu aufbauen. Damit das nicht zu viel Zeit kostet, können sie beispielsweise die Plattform Jenkins verwenden, die sämtliche Images auf den neuesten Stand bringt. (Screenshot: Jenkins)

Wie so häufig entwickeln sich Standards erst nach und nach zu einer Technologie. Anschließend müssen sie sich dann noch in der Praxis bewähren und flächendeckend in der Branche durchsetzen. Für Container stecken angehende Standards noch in den Kinderschuhen. So bildete sich vor einem Jahr die Open Container Initiative (OCI). Ziel ist es, einen Container-Standard für die Industrie zu schaffen. Prämisse dafür sind zentrale Aspekte zur Offenheit, Sicherheit und Kompatibilität. Hier wird sich über die Zeit zeigen, welche Standards die OCI auf den Weg bringt und welche sich durchsetzen. Orientierung in Sicherheitsfragen geben aktuell daher vor allem die von der Container-Community erstellten und veröffentlichten Best Security Practices. So lautet beispielsweise eine Empfehlung, es so einfach wie möglich zu halten und für jeden Prozess jeweils einen Container einzusetzen.

Obacht ist hier bei öffentlichen Images geboten, die oft mit mehreren Applikationen vollgepackt sind. Damit machen es sich Unternehmen nur unnötig kompliziert. Eine der größten Schwachstellen ist das schnelle Veralten von Images. Hier hat es sich als Best Practice bewährt, die Basis-Images für die Container, auf denen Applikationen laufen, am besten täglich neu aufzubauen. So stellen Nutzer sicher, dass sie auf dem aktuellsten Patch Level sind. Um den Aufwand dafür zu minimieren, empfiehlt es sich, in CI/CD-Plattformen wie Jenkins tägliche Jobs einzurichten, die sämtliche OS-Images sowie Applikations-Images auf den neuesten Stand bringen. Da Applikations-Container in der Regel stateless sind, ist es möglich, im Rahmen von Deployments und Update-Rollouts anfällige Container mit gepatchten Containern auszutauschen.

Aufgrund ihres großen Erfolgs sind Container heute auch innerhalb von geschäftskritischen Systemen sicher einsetzbar. In seiner aktuellen Studie „How to Secure Docker Containers in Operation“ [1] weist der Research-Spezialist Gartner sogar auf Sicherheitsvorteile bei Docker-Containern hin: Durch die Isolation der Container seien Applikationen dort sicherer, als wenn sie direkt auf dem OS liefen. Eingebettet in einen Continuous Delivery Lifecycle sind Security-relevante Tasks einfacher umzusetzen. Das liegt vor allem an ihrer Schnelligkeit und Flexibilität. Wird eine neue Lücke in einem OS entdeckt, ist es möglich, innerhalb weniger Minuten zu patchen. Bei VMs ist das im Vergleich nicht ganz so einfach und erfordert deutlich mehr Manpower. Unterm Strich büßen Container durch mehr Sicherheit ihre Vorteile nicht ein. Dreh- und Angelpunkt sind klar definierte Zugriffsrechte und vor allem saubere Prozesse für den Aufbau sowie Betrieb der Container.