Aufrufe
vor 6 Tagen

Cloud & Managed Services 2019

  • Text
  • Unternehmen
  • Anwendungen
  • Container
  • Azure
  • Sicherheit
  • Schweizer
  • Schweiz
  • Anforderungen
  • Microsoft
  • Uniqconsulting

DOSSIER KOMPAKT IN

DOSSIER KOMPAKT IN KOOPERATION MIT NINE INTERNET SOLUTIONS Container-Sicherheit – was Engineers wissen sollten Die Sicherheit von Daten und Infrastruktur ist zum grossen Teil handlungsabhängig, auch in der Cloud. Da Container ein anderes Sicherheitsmodell als traditionelle VMs benötigen, schauen wir uns hier einige Schlüsselbereiche an, welche die Sicherheit in der Systemarchitektur beeinflussen. Da Container die Laufzeitanforderungen einer Anwendung beinhalten, bleibt das Betriebssystem der Container-Plattform extrem schlank. Sogenannte Atomic-Linux-Distributionen wenden dieses Prinzip an und nutzen ein Read-only-Dateisystem, Transaktions-Updates und ein «git»-ähnliches OS-Tree-Modell, um Sicherheit und Skalierbarkeit bei möglichst wenig Angriffsfläche zu bieten. Das Modell des unveränderlichen OS-Tree- Filesystems ermöglicht es auch, wenn nötig direkt auf eine vorherige Systemversion zurückzugehen. Dadurch sind Atomic- Systeme sehr gut für die Anwendung in grossformatigen Kubernetes-Distributionen geeignet, um das Gleichgewicht zwischen Nodes zu sichern. Google selbst hat für Container-Betriebssysteme einen anderen Ansatz: Sein «Container Optimised OS» basiert auf Chromium, aber viele der Kernmerkmale sind gleich wie bei Atomic-Distributionen. Container-Runtimes Docker ist derzeit die meistgenutzte Anwendung der Container- Technologie, hat aber einen grossen Nachteil: Ein Daemon muss laufen, um die Container zu betreiben. Negativ ist dabei, dass alle Container zusammen mit dem Daemon gestoppt werden. Aber es gibt auch weniger offensichtliche Nachteile: So kann man Container nicht starten, bevor der Daemon-Prozess läuft. INIT-Container sind somit unmöglich. Da die Docker-Engine – und nicht die Docker-CLI – die Container startet, werden der Docker- CLI zugeordnete Cgroups nicht vom Container übernommen. Die Parent-PID der Container ist der Daemon, nicht die CLI. Gut ist, dass jede auf Kubernetes basierende Container- Orchestration-Plattform die Container-Runtime Interface-Abs- Bild: Binkski / Fotolia.com Der Autor Tom Whiston, Teamleader Platform, Nine Internet Solutions traktion enthält, sodass unterschiedliche Container-Laufzeiten möglich sind. Eine der bekanntesten Runtimes ist Googles Gvisor, das Sicherheit in ähnlicher Weise wie User Mode Linux behandelt. Gvisor agiert als Gast-Kernel und fängt Systemaufrufe ab und blockiert diese entweder, oder führt eine Userspace-Anwendung aus. Auch nennenswert sind: Frakti – es erlaubt die Nutzung von Kata-Containern, da es eine schlanke, vom darunterliegenden System ganz unabhängige VM um den Pod errichtet; und Virtlet – es ermöglicht das Einrichten ganzer VMs auf Kubernetes-Nodes. Natürlich gibt es bei jeder Lösung Abstriche bei Geschwindigkeit oder Benutzerkomfort, die man im Einzelfall betrachten muss. Kubernetes’ API-Objekte Wenn man Kubernetes für die Container-Orchestrierung nutzt, hat man die Option, sowohl Role Based Access Control (RBAC) als auch Resource-Quota- und Limit-Range-API-Objekte zu verwenden, um Sicherheit und Stabilität zu wahren. Mit RBAC kann man definieren, welche Vorgänge (Verben) unterschiedliche Subjekte (Benutzer/Gruppen) auf Ressourcen (API-Objekten) im Cluster ausführen dürfen. Auch ist der Einsatz individueller Admission-Webhooks möglich, um so entweder zusätzliche Zugangsüberwachung zu bieten oder ankommende API-Anfragen zu mutieren. Durch Resource Quotas und Limit Ranges kann man die Menge an CPU und RAM definieren, die ein Namespace/Pod/Container benötigt oder verbrauchen darf, sodass man sicherstellt, dass alle Container die benötigten Ressourcen erhalten, ohne sie anderen wegzunehmen. Der Aufbau der Anwendung ist entscheidend Auch wenn die Fragen beim Container-Betrieb andere sind als bei traditionellen Servern, kann man in jeder Architekturebene sinnvolle Varianten wählen, um Sicherheit zu gewährleisten – unabhängig davon, ob man Container vor Ort oder in der Cloud betreibt. Und natürlich hängt die Sicherheit am stärksten vom Aufbau der Anwendung ab. 32 Cloud & Managed Services

« Sicherheit geht alle etwas an, ob man Container benutzt oder nicht » Container-Technologie kann – richtig angewendet – Clouds sicherer machen. Zudem kann sie auch den Ressourcenverbrauch auf der Infrastruktur reduzieren. Was es dabei zu beachten gilt, erklärt Tom Whiston von Nine Internet Solutions. Interview: Marc Landis DOSSIER KOMPAKT IN KOOPERATION MIT NINE INTERNET SOLUTIONS AG Wie können Container die Sicherheit in der Cloud verbessern? Tom Whiston: Container-Sicherheit ist ein sehr umfangreiches Thema und hängt von vielen Faktoren ab. Aber kurz gefasst sind die Gestalt und die Architektur von Containern und Container- Plattformen eine gute Basis für viele Best Practices bei der Entwicklung und Bereitstellung von Anwendungen und Infrastrukturen. Durch die Begünstigung bestimmter Strukturen – etwa das Behandeln von Infrastruktur als Code und der Runtime als unveränderlich – wird alles prüfbar und alle Änderungen sind nachvollziehbar. Den Container-Zustand können bestimmte Funktionen erhalten: so etwa CRI-Os-Read-Only-Modus, mit dem nur externe Datenträger und spezifische Tmpfs-Mounts beschrieben werden können. Besonders Kubernetes benutzt eine Reihe von API-Objekten, die zusätzlich die Sicherheit fördern. Dazu gehören Role Based Access Control für eine sehr feine Einstellung von Nutzerberechtigungen sowie Secrets, womit verschlüsselte Daten gespeichert und in Container eingefügt werden können. Das Network-Policy-Objekt ist ebenfalls von Bedeutung, da man damit definieren kann, welcher Traffic zwischen Pods fliessen darf. Bei der Verwaltung all dieser Sicherheitsfunktionen und -konfigurationen muss man sich oft mit YAML rumärgern. Obwohl man dabei eine steile Lernkurve hat, glaube ich, dass die Sicherheit und Änderungsprozesse gegenüber klassischer Infrastruktur viel transparenter und nachvollziehbarer sind, wenn man diese wichtigen Aspekte des Anwendungsumfelds auf nur eine API, die Kubernetes API, standardisiert. Die CI/CD-Prozesse, die oft mit der Nutzung von Containern einhergehen, machen es ausserdem möglich, Sicherheits-Fixes für Anwendungen viel schneller und automatisierter bereitzustellen. Tom Whiston, Teamleader Platform, Nine Internet Solutions. Welchen Einfluss haben Container auf den Ressourcenverbrauch in der Infrastruktur? Da Container keine komplette VM um sich errichten müssen, benötigen sie weniger Verwaltungsdaten als traditionelle Virtualisierungen, sodass mehr Platz für die Anwendung selbst bleibt. Bei den meisten Container-Plattformen findet ein Grossteil der Prozesse – wie die Abwicklung von API-Anfragen – auf einer separaten Maschine statt. Dadurch ist es einfacher, die verfügbaren Ressourcen zu berechnen, und unwahrscheinlicher, dass ein eventuelles Plattformproblem die Anwendung beeinträchtigt. Da Container-Plattformen ein System für die Ressourcenverteilung beinhalten, kann man bei Bedarf leicht anpassen, was der Anwendung zugewiesen ist, und dazu das Nutzungsprofil genau kontrollieren. Das ist wichtig, um sicherzustellen, dass alles planbar ist und kein Container die gesamten Hardwareressourcen verbraucht. Man muss natürlich die Ressourcen-Grenzwerte seiner Software gut kennen, um diese Werte korrekt einzustellen! Welche Anwender sollten sich mit Container-Security auseinandersetzen? Sicherheit geht alle etwas an, ob man Container benutzt oder nicht. Echte Sicherheit hängt nicht nur von der Runtime-Umgebung ab, sondern zum Beispiel auch von fehlertoleranten Anwendungen, der Vorbereitung auf die Nichtverfügbarkeit von Services, der Prüfung von Drittanbieter-Libraries, der Sicherung von Konfigurationen in der Infrastruktur, Penetration-Tests etc. Über die Sicherheit muss man also frühzeitig und oft nachdenken. Ich würde es jedem empfehlen, sich die «DevSecOps»- Bewegung anzuschauen und sich über Tools wie Chaos Monkey oder Chaos Toolkit zu informieren, die interessante Anregungen enthalten, wie man für das Sicherheits-Testing Eigeninitiative und Automatisierung nutzt. Cloud & Managed Services 33