Red Hat: „Container verbessern die Cloud-Sicherheit“

Gastbeitrag Die Container-Technologie ermöglicht, eine Applikation mit all ihren Abhängigkeiten in einem Image zu verpacken und es ohne Änderungen von der Entwicklung über den Test bis in eine produktive Umgebung weiterzuleiten. Mit Containern lässt sich eine durchgängige Konsistenz in unterschiedlichen Umgebungen sicherstellen, egal ob die Container auf physikalischen Servern, in virtuellen Maschinen oder in Private und Public Clouds laufen.

Matthias Pfützner, der Autor dieses Beitrags, ist Senior Solution Architect, Account & Cloud – DA(CH) bei Red Hat (Bild: Red Hat)

Statische Sicherheitsrichtlinien und Checklisten reichen für Container jedoch nicht aus – und vor allem skalieren sie nicht. Um die Geschäftsvorteile von Containern umfänglich nutzen zu können, ist es notwendig, dass Unternehmen ihre IT-Sicherheitsmaßnahmen in regelmäßigen Abständen überprüfen und weiterentwickeln. Die Überwachung und Einhaltung einer hohen IT-Sicherheit ist eine permanente Aufgabe. Und sie muss in jeder Phase des Lebenszyklus einer Container-Applikation und der Infrastruktur berücksichtigt werden. Bei der Überwachung der Container-Sicherheit geht es um Themen wie Container Content, Container Registry, Continuous-Integration (CI)- und Continuous Delivery (CD)-Pipeline sowie Continuous Deployment Policies.

Die wichtigsten Elemente einer Enterprise-Container-Lösung im Überblick (Bild: Red Hat).

Container-Images aus vertrauenswürdigen Quellen nutzen

Entwickler und IT-Betrieb müssen dafür sorgen, dass Images sicher laufen. Jedes Container-Image besteht aus einem grundlegenden Linux User Space Layer sowie weiteren Applikations-abhängigen Layern. So bietet beispielsweise Red Hat über einen Container Catalog Basis-Images für das Linux-Betriebssystem sowie eine große Zahl zertifizierter Images für verschiedene Programmiersprachen, Middleware und Datenbanken. Wichtig ist, dass es einen eindeutig festgelegten Workflow für den Zugriff auf extern und intern erstellte Container-Images gibt. Unternehmen, die bereits ein Binary Repository wie JFrog Artifactory oder Sonatype Nexus einsetzen, können dieses für den Transport der Container-Images nutzen.

Unabhängig davon, welche Registries Unternehmen einsetzen: Entscheidend ist, dass sie über Funktionen verfügen, um Sicherheitsrichtlinien und Workflows für die Verwendung von in der Registry gespeicherten Container-Images zu automatisieren. Zudem sollte ein Rollen-basierter Zugriff für die Container-Images vorhanden sein. Dazu kommen Funktionen zur Kennzeichnung von Images: freigegeben nur für die Entwicklung, für Tests und schließlich für die Übergabe in den produktiven Betrieb – egal, ob auf Bare-Metal-Servern, in virtuellen Maschinen oder in einer Cloud-Umgebung.

Private Registries ermöglichen einen sicheren Zugriff und die geordnete Weiterleitung von Images (Bild: Red Hat).

CI benötigt einen automatischen Sicherheitscheck

Wie bei jeder Applikation ist das Management der Production Builds ein zentraler Baustein zur Sicherstellung der Sicherheit eines Software Stack. Eine Source-to-Image-Funktion vereinfacht Entwickler- und IT-Betriebsteams die Zusammenarbeit in einer reproduzierbaren Build-Umgebung. Sobald ein Build abgeschlossen ist, sollte die Source-to-Image-Funktion das Image automatisch in die Private Registry transportieren.

Dies geschieht automatisch, wenn Entwickler eine Source-to-Image-Funktion verwenden. Viele Unternehmen nutzen Signaturen als weiteren Sicherheitscheck für Container-Images. Bevor ein Image in den produktiven Betrieb geht, müssen Signaturen verifiziert werden. Vielfach erfolgt die Prüfung heute noch per Skript; wünschenswert ist eine standardmäßige Integration in den Container Lifecycle.

Für den Fall, dass während des Build-Prozesses etwas schief geht oder für Situationen, in denen eine Schwachstelle entdeckt wird, nachdem ein Image implementiert wurde, benötigen Unternehmen einen weiteren Security Layer: Wichtig ist dieser deshalb, weil keine im Einsatz befindlichen Container gepatcht werden. Container sollten vielmehr neu erstellt und automatisch ersetzt werden.
Die Container-Infrastruktur schützen

Externe Inhalte für Anwendungen sollten zusammen mit wichtigen Metadaten über die Container-Images lokal in einer Private Registry gespeichert werden. Image Streams abstrahiert die Images in Public und Private Registries, was die Automatisierung vereinfacht. OpenShift und die Jenkins-Integration bieten beispielsweise Hooks zur Automatisierung von Image-Updates (Bild: Red Hat).

Beim Schutz der Container-Infrastruktur sind beispielsweise folgende Aspekte gefragt: Container-Plattform, Container-Host, Multi-Tenancy, Network Isolation und Storage. Die sichere Nutzung von Containern in einem Unternehmensrechenzentrum und in einer Cloud-Umgebung erfordert ein Betriebssystem, das die Mandantenfähigkeit der Container Runtime verwalten kann: Die Multi-Tenant-Isolierung auf der Container-Plattform spielt eine entscheidende Rolle im Rahmen eines umfassenden Container-Sicherheitskonzepts – On-Premise und in der Cloud.

Die klare Trennung soll sicherstellen, dass kein Container Zugriff auf die Ressourcen eines anderen Containers erhält und dass auch die Ressourcen des zugrundeliegenden Hosts nicht zugänglich sind. Zur Umsetzung der Multi-Tenant-Isolierung stehen grundlegende Linux-Sicherheitstechnologien zur Verfügung. Es gibt mehrere Security Levels zum Schutz von Containern unter Linux: SELinux (Security-Enhanced Linux), Linux Namespaces, CGroups und Read Only Mounts. CGroups stellen sicher, dass ein einzelner Container nicht eine große Menge an Systemressourcen verbrauchen kann, und sie verhindern so einfache Denial-of-Service-Angriffe.

Zusätzlich zu den Network Namespaces bietet OpenShift SDN eine weitere Sicherheit, indem das Multi-Tenant-Plugin eine Isolierung zwischen Master (Orchestration) Namespaces herstellt (Bild: Red Hat).

Im Kern ist SELinux ein Labeling-System. Jeder mit SELinux laufende Prozess erhält ein Label; das gilt auch für jedes File, Directory oder System Object. Standardmäßig stehen mehr als 400 SELinux-Module und -Policies zur Verfügung. Diese Vorschriften definieren Zugriffsregeln und der Kernel setzt diese durch. SELinux fungiert als Schutzmauer zwischen nicht vertrauenswürdigen Applikationen und dem restlichen Betriebssystem.

Linux Namespaces bieten die Grundlagen der Container-Isolierung. Ein Namespace trennt containerisierte Prozesse voneinander und präsentiert jedem Prozess nur seine „eigene Welt.“ Die aus Container-Sicht wichtigsten Namespaces sind der PID Namespace und der Network Namespace. Der PID Namespace sorgt dafür, dass ein containerisierter Prozess nur die Prozesse innerhalb des Containers sieht, aber keine Prozesse anderer Container auf dem Shared Host. Der Network Namespace ist eine isolierte Umgebung, die über einen eigenen Networking Stack verfügt und Container davor schützt mit anderen Containern auf dem gleichen Host zu kommunizieren.

Ein weiteres Beispiel sind User Namespaces. Sie ähneln den PID Namespaces und ermöglichen es einem Administrator, bestimmte Host-UIDs zu definieren, die einem Container zugeordnet sind. Folglich erhält ein Prozess dann volle Root-Privilegien für Operationen innerhalb des Containers und gleichzeitig darf er keine Operationen außerhalb des Containers ausführen. User Namespaces bietet Servern, die Linux-Container ausführen, zusätzliche Sicherheit, indem sie die Isolierung zwischen Host und Containern verbessern. Administratoren von Containern sind dann nicht mehr in der Lage, administrative Operationen auf dem Host durchzuführen, was die Sicherheit erhöht.

Mit Read Only Mounts lässt sich das Filesystem vor Containern schützen. Durch einen Read-Only-Zugriff auf Kernel-Schnittstellen wird ein Container daran gehindert, in das virtuelle Dateisystem sysfs zu schreiben und Kernelparameter zu ändern, die das gesamte System destabilisieren können.

Ein Beispiel für eine Zwei-Wege-SSL-Verschlüsselung von Red Hat OpenShift Container Platform (Bild: Red Hat).

Sichere und verschlüsselte Kommunikation

Immer mehr Applikationen erfordern eine Zwei-Wege-Verschlüsselung. Dabei müssen beide Seiten ihre Identität nachweisen, um verschlüsselte Daten über eine sichere Verbindung austauschen zu können. Red Hat OpenShift Container Platform beispielsweise bietet standardmäßig einen containerisierten stateless HAProxy als Default Router. Es gibt drei konfigurierbare Möglichkeiten zur TLS-Terminierung: Edge, Re-Encryption und Passthrough. Entscheidend dabei ist, dass Entwickler und Administratoren auch beim Verschlüsseln eng zusammenarbeiten – das beginnt bei der Erstellung der Container-Images und reicht bis zu einem sicheren Einsatz der Container-Images über den gesamten Lebenszyklus.