Projektinterview: Sicherer Betrieb von Container-Technologien

Dr. Markus Ermes ist studierter Physiker und hat im Bereich der optischen Simulation seine Doktorarbeit geschrieben. Im Rahmen seiner Promotion hatte er schon immer viele Berührungspunkte mit der IT. So war er an der RWTH Aachen und in seinem Job am Forschungszentrum Jülich auch im Bereich der System- und Netzwerkadministration tätig. Seine Affinität zur IT veranlasste ihn vor knapp sieben Jahren dazu, zu ComConsult zu wechseln.

Markus, was sind deine Aufgaben bei ComConsult?

Ursprünglich war ich bei ComConsult im Competence Center Cloud und Data Center für die Themenbereiche Virtualisierung, Storage, Backup und Rechenzentrumsnetze zuständig. Mittlerweile beschäftige ich mich darüber hinaus viel mit der IT-Sicherheit, die im Rechenzentrumsbereich ebenfalls eine entscheidende Rolle spielt. Auch im Bereich Netze sind die Übergänge fließend.

Container-Technologien sind aktuell ein großes Thema. Warum?

Vor mehr als einem Jahrzehnt hat das Thema Container mit Docker weltweit an Fahrt aufgenommen. Entwickler haben damit die Chance erhalten, dass alles, was für das Entwickeln des Programms notwendig war, mitgeliefert wurde. Es war nicht mehr nötig, eine Vorlage für eine virtuelle Maschine mit Betriebssystem und allem, was dazugehört, bereitzustellen. Mit anderen Worten: Software konnte man jetzt schlank in einer Form verpacken, die es ermöglichte, sie einfach zu installieren und laufen zu lassen. Inzwischen stellen viele Softwareentwickler ihre Software nur noch in dieser Form bereit. Kunden, die ich im Rechenzentrumsbereich berate, setzen sich stellenweise unter Zähneknirschen mit dem Thema auseinander, weil sie ihre Software nur noch in dieser Form erhalten. Technisch gesehen sind Container-Technologien eine interessante Sache: Sie sind schlank, einfach zu handhaben und lassen sich sehr gut automatisieren.

Die Hersteller von Kubernetes sind momentan sehr aktiv. Weshalb?

Container in ihrer ursprünglichen Form laufen auf einer einzelnen Maschine. Wenn diese Maschine ausfällt, fallen auch die Anwendungen, die auf ihr laufen, aus. Das ist für einen Entwickler vertretbar. Doch wenn darüber kritische Unternehmensanwendungen wie beispielsweise eine Finanzbuchhaltung laufen, ist das inakzeptabel. Deshalb muss es einen Mechanismus geben, der Redundanz schafft. Und da ist Kubernetes momentan die verbreitetste Plattform für die Orchestrierung von Containerumgebungen. Google hat Kubernetes ursprünglich intern entwickelt und lange eingesetzt, bevor es als Open Source zur Verfügung gestellt wurde. Viele bekannte Google-Dienste wie Google Maps, Google Docs und so weiter laufen sämtlich intern in Containern und werden über Kubernetes gesteuert. Mittlerweile ist Microsoft in diesem Bereich ebenfalls sehr aktiv. Jeder große Cloud-Anbieter stellt inzwischen in irgendeiner Form einen Kubernetes-Service zur Verfügung.

In einigen Bereichen, vor allem in der Forschung und an Universitäten, gibt es bereits Wildwuchs. Wie kommt es dazu?

Ich komme ja selber aus der Forschung. Dort ist es so, dass Container-Lösungen „mal eben“ an der einen oder anderen Stelle gebraucht werden und dann wird mit einem einzelnen Server oder mit einer kleineren Lösung mit zwei oder drei Rechnern daran gearbeitet. Wenn man einen produktiven Kubernetes-Cluster schaffen will, rechnet man mit mindestens fünf Systemen. Das ist für eine kleine Anwendung mit ein bisschen Redundanz teilweise übertrieben und deshalb gibt es hier oft eine Bewegung in die Welt der Schatten-IT. Aus netzwerk- und sicherheitstechnischer Sicht ist ein solches Vorgehen natürlich keine zufriedenstellende Lösung. Deshalb ist der Anspruch vieler Kunden gerade im Forschungsbereich, zentrale Infrastrukturen zur Verfügung zu stellen, in denen Container-Anwendungen zentral gesteuert werden.

Warum ist die Installation durch kommerzielle Lösungen (oder Cloud) häufig vergleichsweise einfach und der Betrieb dann doch komplexer als gedacht?

Wenn sich ein Unternehmen eine Kubernetes-Lösung von beispielsweise Red Hat, SUSE, Mirantis oder VMware anschafft, erhält es eine Software, die relativ einfach installiert werden kann. Doch damit, dass Kubernetes läuft, ist es ja nicht getan. Es gibt eine Menge Fragen zu beantworten: Wer erhält Zugang? Was darf wer genau ausführen? Wie wird ein Nutzer vom Rest getrennt? Wie wird das Netzwerk gestaltet? Welche Sicherheitsbedingungen gelten? Bei der Entwicklung der Umgebungen werden diese häufig mit sogenannten CI/CD-Pipelines verbunden. Mit Continuous Integration und Continuous Deployment automatisiert man im Rahmen der Softwareentwicklung Änderungen in verschiedenen Umgebungen. Hierbei wird aus Quellcodes ein fertiger Container regelmäßig automatisch entwickelt beziehungsweise es wird das Image dazu gebaut, das automatisch auf dem Kubernetes-Cluster ausgerollt werden kann. Die veralteten Versionen werden dann langsam abgeschaltet und die neue Version automatisch eingebracht. Es ist also eine ganze Reihe von Aspekten wie Benutzerverwaltung, Quellcode-Repository, Datenbanken und so weiter zu berücksichtigen. Einen reibungslosen Betrieb zu gewährleisten ist folglich nicht ganz einfach.

Die Sicherheit von Containern ist ein vielschichtiges Thema. Warum?

Viele Kunden, die noch mit klassischer Virtualisierung arbeiten, arbeiten auch noch mit konventionellen Netzwerkmechanismen wie VLANs und Firewalls. Im Container- und Kubernetes-Umfeld gibt es modernere Möglichkeiten, die man netzwerk- beziehungsweise sicherheitstechnisch anwenden kann. Beispielsweise können zur Isolierung zwischen Mandanten im selben Cluster verschiedene Namespaces implementiert werden. Oder man hat bestimmte Funktionen und Mechanismen, mit denen man dafür sorgen kann, dass es überhaupt nicht mehr möglich ist, manipulierte Container in die Umgebung zu „schmuggeln“, weil die korrekten Container nur verschlüsselt miteinander reden, nachdem sie sich gegenseitig authentisiert haben. Diese Möglichkeiten machen den Betrieb natürlich nicht einfacher. Doch die zusätzliche Komplexität kann im Netzwerk- und Sicherheitsbereich einiges bringen. Was unweigerlich immer mit dazugehört ist das Thema Software Defined Networking (SDN) – also die Trennung von Soft- und Hardware in einem Netzwerk. Die zugrunde liegende Hardware, speziell die Switches, haben keine Kenntnis davon, wie die Netze zwischen Containern genau gestaltet werden, sondern sehen nur „klassischen“ IP-Traffic zwischen den Systemen, auf denen Container ausgeführt werden. Das Thema nimmt aktuell in vielen Bereichen Fahrt auf. Im Kubernetes-Kontext ist es „friss oder stirb“.

Was sind besondere Sicherheitsaspekte?

Wir von ComConsult beraten viele öffentliche Kunden oder Kunden, die mit öffentlichen Auftragnehmern zusammenarbeiten. Diese Institutionen müssen sich an die Vorgaben des Bundesamts für Informationstechnik (BSI) halten. Für uns als Berater ist das IT-Grundschutz-Kompendium des BSI eine feine Sache, für die Unternehmen, die es umsetzen müssen, nicht unbedingt. Das BSI hat die Relevanz von Containern und Kubernetes erkannt und mittlerweile mit SYS.1.6 und der APP.4.4 entsprechende Bausteine veröffentlicht. Manche Vorgaben dieser Bausteine sind sehr einfach umzusetzen. Es gibt andere Themen, die vom gesunden Menschenverstand her eigentlich selbstverständlich, doch aufgrund der Art und Weise, wie Container funktionieren, recht arbeitsaufwändig in der Umsetzung sind. Ein Beispiel an dieser Stelle ist das Speichern von Protokolldaten. Wenn Container nicht mehr gebraucht werden, verschwinden sie und sämtliche Änderungen, die bis dahin vorgenommen wurden, sind nicht mehr verfügbar. Deshalb müssen zusätzliche Maßnahmen ergriffen werden, um die Protokolldaten abzulegen, damit man sie später analysieren kann. Hier gibt es viele Möglichkeiten. Wenn die Container von vorne bis hinten selbst gestaltet werden, kann man ihnen intern beibringen, die Daten an einem bestimmten Ort abzulegen. Oder man kann eine Zusatz-Software in Kubernetes installieren, die die Daten sammelt. Die Umsetzung der Maßnahmen ist zwar nicht sehr schwer, doch man muss einfach daran denken.

ComConsult sollte einen Konzern bei einem umfassenden Sicherheitskonzept für seine IT-Landschaft unterstützen. Wie warst du an diesem Projekt beteiligt?

Bei unserem Kunden handelte es sich um einen großen Gerätehersteller. Fast jedes elektrische Großgerät hat heutzutage in irgendeiner Form eine Linux- oder vielleicht eine WLAN-Schnittstelle. Die Idee des Kunden war es, innerhalb der Produktionsumgebung diese Schnittstellen mit der jeweiligen Software, der Firmware und dem Betriebssystem zu betreiben. Diese Aufgabe sollte in Containern realisiert werden. Es war eine relativ einfache Umgebung mit einer Handvoll Rechnern, für die kein Kubernetes nötig war. Meine Aufgabe war es, Ansätze, Maßnahmen und Best Practices in Bezug auf die Risiken, die in einem solchen Umfeld auftreten können, zu formulieren. Meine Empfehlung war unter anderem eine Netzwerksegmentierung, also die Aufteilung der Netzwerke in getrennte, logische Bereiche, die es einem Angreifer erschwert, Zugriff auf weitere Systeme zu erhalten. Nicht nur bei klassischen Netzwerken, sondern auch bei der Container-Orchestrierung ist die Netzsegmentierung Pflicht.

Bei einem großen deutschen Unternehmen wird in der Softwareentwicklung verstärkt mit Container-Plattformen gearbeitet. Dabei wird OpenShift Container Platform eingesetzt. Für den Einsatz dieser Plattform sollte ComConsult ein Sicherheitskonzept gemäß des ISMS des Kunden erstellen. Erzähle bitte von deinen Aufgaben in diesem Projekt.

Für die Erstellung des Sicherheitskonzeptes haben wir untersucht, welche Bausteine des BSI-IT-Grundschutzkompendiums anzuwenden waren. OpenShift ist eine Anwendungsplattform auf Basis von Kubernetes, die sehr verbreitet ist. Deshalb war der BSI-Baustein Kubernetes für das Sicherheitskonzept von Bedeutung. Und weil der Kunde mit Container-Plattformen arbeitet, war auch der BSI-Baustein Containerisierung wichtig – wie auch eine Reihe von OPS-Bausteinen vom BSI, die den Betrieb von IT-Systemen thematisiert. Hier haben wir unter anderem Fragen zur Administration und zum Umgang mit Patches untersucht. Übergreifende Bausteine zur Organisation spielten ebenfalls eine Rolle. Dabei geht es zum Beispiel um das Thema, wie man das Personal qualifiziert, das an den Systemen arbeitet. Alles in allem war unsere Analyse sehr komplex und übergreifend. Und dann ging es „ans Eingemachte“. Wir haben uns die Server, auf denen alles betrieben wurde, sicherheitstechnisch angeschaut ebenso wie das Betriebssystem und die Containerumgebung, die auf ihnen liefen. Weiterhin haben wir das betrachtet, was in den Containern läuft sowie die Orchestrierung der Container mit Kubernetes. Wir mussten dabei nicht nur für Kubernetes die einzelnen Server betrachten, sondern alle anderen Server, die damit zusammenhingen. Dann hatten wir noch eine Datenbank, welche durch die containerisierten Anwendungen genutzt werden konnte. Diese mussten wir uns natürlich auch anschauen. Und es gab eine Umgebung für die Protokollierung zu berücksichtigen. Es waren sehr, sehr viele Systeme involviert, wodurch sich das Projekt äußerst komplex gestaltete.

Wie bekommt ihr ein solch komplexes Projekt in den Griff?

Zum einen beraten wir diesen Kunden schon seit vielen Jahren, sodass wir in diesem sehr umfangreichen Projekt glücklicherweise schon auf etliches unternehmensinternes Vorwissen zurückgreifen konnten. Zum anderen hofft man darauf, dass der Kunde seine Systeme schon ganz gut unter Kontrolle hat, was der Fall war. Der Kunde hatte sich schon viel mit den BSI-Bausteinen beschäftigt und dementsprechend einiges bereits umgesetzt. Einen großen Teil meiner Zeit habe ich in diesem Projekt damit verbracht, mit den Mitarbeitern darüber zu sprechen, was sie bereits wie umgesetzt haben oder welche zukünftigen Maßnahmen sinnvoll erscheinen. Die Ergebnisse aus den Gesprächen habe ich anschließend dokumentiert.

Ich habe ebenfalls die Dokumentationen, die beim Kunden bereits vorlagen, dahingehend überprüft, ob Anforderungen des BSI nicht (vollständig) eingehalten wurden und – wo es nötig war – eine schnelle Nachbesserung oder Umsetzung empfohlen. Ich habe wie auch schon in vielen anderen Projekten festgestellt, dass gerade das Thema Dokumentation immer wieder stiefmütterlich behandelt wird, obwohl es in den BSI-Bausteinen als sehr wichtig eingestuft wird. Es muss genau festgehalten werden, wie die Prozesse funktionieren, wie die Datenströme aussehen, welche Sicherheitsmechanismen vorgesehen sind und so weiter. Für die Mitarbeiter, die sich täglich mit diesen Themen beschäftigen, erscheinen diese Dinge selbstverständlich, weil alles so konfiguriert ist, doch den alten Spruch „Der Code dokumentiert sich selbst“ lässt man in diesem Umfeld einfach nicht gelten. So war es auch im vorliegenden Projekt notwendig, noch einige Vorgänge schriftlich an zentraler Stelle zusammenzuführen.

Ist der Einsatz von Container-Technologien jedem Unternehmen zu empfehlen?

Ich habe einmal erlebt, dass ein Mitarbeiter aus der Marketingabteilung eines großen Anbieters einem Kunden Kubernetes wärmstens empfohlen hat. Der Kunde hat daraufhin Kubernetes getestet und musste feststellen, dass es nicht wirklich in einem Maße zum Einsatz hätte kommen können, dass sich die teure Investition gelohnt hätte. Hier hat man erkannt, dass eine kleinere Lösung genügt. Natürlich ist Kubernetes eine tolle Sache, die jeder einmal ausprobiert haben will. Jedoch sollte man ehrlich zu sich sein und überlegen, ob es unbedingt die Yacht sein muss, wenn auch ein Ruderboot ausreicht.