Interview mit Moritz Heiber

DevSecOps: „Blinde Automatisierung ohne Bedrohungsmodell und Verständnis hat allenfalls die Relevanz eines Feigenblattes“

Dominik Mohilo

Moritz Heiber

„Es geht vor allem um die Automatisierung“, könnte das Motto von DevOps lauten. Doch der Begriff DevOps steht für so viel mehr als reine Workflowoptimierung. Es geht auch um die Sicherheit, um eine möglichst produktive Kultur und kontinuierliche Wertschöpfung für die Nutzer und Kunden. Gerade der Sicherheitsaspekt wird oft außen vor gelassen. In Bezug auf Continuous Delivery glauben manche hingegen, dass der Einsatz von Jenkins genug sei. Wir sprachen mit Moritz Heiber, Infrastructure Consultant und „DevOps Birth Assistant“ bei ThoughtWorks, über Continuous Delivery und wie es richtig umgesetzt wird. Außerdem erklärt er im Interview, wie sich DevSecOps realisieren lässt und welche Rolle Serverless im großen DevOps-Universum spielt.

JAXenter: Continuous Delivery ist als Thema quasi das Herzstück jeglicher DevOps-Bemühungen, geht es in dem Zusammenhang doch besonders auch um die Automatisierung von Arbeitsabläufen. Thoughtworks bietet hierfür GoCD, einen Open-Source-CD-Server an. Was sind die Besonderheiten von GoCD?

Moritz Heiber: GoCD bietet gegenüber anderen Lösungen einige Vorteile, die sonst nur wenige Konkurrenten am Markt nachhaltig und mit Bedacht umsetzen. Nehmen wir zum Beispiel die konsequente Umsetzung von Features im Produkt über das API. Jegliche Einstellungs- und Konfigurationsmöglichkeiten lassen sich sowohl über das API als auch die Weboberfläche anpassen. Das entspricht einem „API First“-Ansatz, der sehr viele Vorteile mit sich bringt und es gleichzeitig ermöglicht, ohne große Hürden eigene Brücken in das „Ökosystem GoCD“ zu schlagen.

Darüber hinaus ist GoCD eines der wenigen Produkte, die komplett an der Struktur von Pipelines ausgerichtet ist. Eine Pipeline im Kontext von GoCD ist die Grundstruktur jeglicher Arbeit, die der Continuous-Delivery-Server verrichtet, und nicht nur ein nachträglich etabliertes oder implementiertes Konzept. Eine Pipeline kann dabei sowohl andere Pipelines enthalten als auch als Artefakt verwendet werden, wodurch sich komplexe, kaskadierende Business- und Entwicklungsworkflows relativ simpel und mit voller Unterstützung von API und Webkonsole einrichten und betreiben lassen. Viele Probleme anderer Plattformen und Werkzeuge (wie z.B. Abhängigkeiten zwischen Pipelines oder Artefakten) sind mit GoCD direkt im Kern gelöst und komplett in den Releasezyklus integriert.

Wenn normale technische Schuld auf einer regulären Skala wächst, dann ist die Skala von sicherheitsrelevanter Schuld höchstwahrscheinlich logarithmisch.

Ein Feature, das GoCD besonders von anderen Lösungen abgrenzt, ist die Value Stream Map. Sie ist für jede Pipelinestruktur in GoCD abrufbar und eine einfache Darstellung eben jener komplexen Strukturen und Abläufe. Hiermit lässt sich für jede vom Server angestoßene Arbeitslast idempotent und versioniert nachvollziehen, welches Artefakt, ob Pipeline oder Kompilat, zu welchem Zeitpunkt mit welchen Abhängigkeiten zu welchem Ausgang an welchem Ende eines Prozesses geführt hat.

Diese Darstellung ist nicht nur immens hilfreich für Entwickler, um Abhängigkeiten zwischen Produkten und Teams klarer zu verstehen und im Falle von Fehlern und Ausfällen schnell an klare Informationen zu gelangen. Sie ist vor allem auch hochgradig zugänglich für Teammitglieder und Außenstehende, die keine große Affinität zu den technischen Hintergründen und Prozessen haben, die hinter der Produktauslieferung stehen. Und gerade dieses Feature ist es, was den Paradigmen von DevOps vor allem entspricht (cross-funktionale Teamverantwortung und Empathie sowie Business-Verständnis und -ausrichtung).

JAXenter: Wer im DevOps-Bereich unterwegs ist, der kennt auch DevSecOps als nächsten Schritt. Wie kann der Sicherheitsaspekt bei der Automatisierung gut abgedeckt werden?

Moritz Heiber: Wie man es auch immer nennt, Sicherheitsaspekte von Softwareentwicklung gehören zu den essentiellen Entwicklungsparadigmen wie „Agile“, „DRY“ oder „TDD“. Es kann manchmal gefährlich sein, diese Aspekte aufgrund von Praktikabilität oder Zeitnot in Bereiche auslagern zu wollen, die nicht direkt mit Entwicklern, dem Produkt oder der Wertschöpfungskette in Kontakt kommen.

Die Herangehensweise sollte sich hier vor allem erst einmal an kulturellen Aspekten ausrichten, d.h. welche sicherheitsrelevanten Aspekte bei der Entwicklung bedacht werden müssen, welche Bedrohungsszenarien sich auf der Art des Produktes oder Wahl von Entwicklungssprache und Umgebung ergeben, wie Daten effektiv gegen Zugriff von Dritten oder nicht befugten Personen geschützt werden können oder aber geltende Gesetzeslage (Stichwort: DSGVO) sicher und konform umgesetzt werden können. Erst anschließend sollte man sich die entsprechenden Szenarien anschauen und einen passenden Grad von Automatisierung einführen. Blinde Automatisierung ohne Bedrohungsmodell und Verständnis führt zu fehlender Verantwortung seitens der Entwickler und Produktverantwortlichen und hat allenfalls die Relevanz eines Feigenblattes.

Die anschließende Integration von entsprechenden Werkzeugen erfolgt genau so wie jedes andere Element in der Wertschöpfungskette: als Teil der Auslieferungs- und Release-Pipeline. Und das möglichst so, dass Sicherheitsprobleme nicht einfach ignoriert oder „abgestellt“ werden können, wenn es gerade nicht in den täglichen Ablauf passt. Denn wenn normale technische Schuld auf einer regulären Skala wächst, dann ist die Skala von sicherheitsrelevanter Schuld höchstwahrscheinlich logarithmisch.

DevOpsCon Istio Cheat Sheet

Free: BRAND NEW DevOps Istio Cheat Sheet

Ever felt like service mesh chaos is taking over? As a follow-up to our previous cheat sheet featuring the most important commands and functions, DevOpsCon speaker Michael Hofmann has put together the 8 best practices you should keep in mind when using Istio.

JAXenter: Infrastructure as Code und der gesamte Bereich „Operations“ befinden sich im Wandel: Das Zauberwort heißt Serverless. Macht Serverless IaC überflüssig?

Moritz Heiber: Man spürt heute bei vielen die Ernüchterung, welche sich vom Hype rund um „Serverless“ von vor einigen Jahren mehr versprochen haben. Sicherlich ist es für manche Dinge eine gute Alternative zu etablierten Werkzeugen und Prozessen, aber es ist nicht die „Silver Bullet“, wie aber auch schon viele andere Lösungen vor Serverless.

Darüber hinaus merkt jeder, der sich einmal mit Serverless beschäftigt hat, dass „Serverless“ nicht „ohne Infrastruktur“ bedeutet. Wo kommen die Daten her, die verarbeitet werden? Wo gehen sie hin? Woher bekommt meine Funktion Anfragen? Wie schickt sie diese Antworten zurück? Es gibt viele Abstraktionen in der Serverless-Welt und sie haben alle eins gemeinsam: Sie erfordern trotzdem noch Infrastruktur, um sie zum Laufen zu bekommen. Und die Definition dieser Umgebungen findet weiterhin über APIs statt, die mit Hilfe von Infrastructure as Code angesprochen werden, gerade weil es ja um Reproduzierbarkeit und Zuverlässigkeit geht.

Ich denke also nicht, dass in absehbarer Zeit das Mantra der deklarativen Definition von Infrastrukturkomponenten aus dem Werkzeugkasten von Entwicklern verschwinden wird.

JAXenter: Wie steht es um die Container-Technologie? Wird Serverless diese bald überflüssig machen oder bestehen vielleicht sogar Synergien zwischen diesen beiden großen Themen?

Moritz Heiber: Container haben sich als Standard in der Anwendungsentwicklung und -auslieferung etabliert und helfen dabei, digitale Produkte plattformunabhängig und ohne große Hürden zu entwickeln. Aus meiner Sicht hätte das Venn-Diagramm, das man für die Anwendungszwecke von Containern und Serverless zeichnen würde, allerdings nur eine geringe Schnittmenge als Resultat.

Container und Serverless werden zum guten Rüstzeug von cross-funktionalen Teams gehören.

Die Stärke von Containern liegt in erster Linie in der schnellen Iteration, dem Verwenden des gleichen Artefakts auf jeder Plattform und in jeder Umgebung sowie, falls man den in Communitys bekannten Vorgehensweisen folgt, einem erhöhten Niveau von Sicherheit und Isolation. Serverless dagegen hat vor allem den Vorteil, ohne große Komplexität seitens der Infrastruktur Ergebnisse mit guter Integration in andere Services der Plattformen, auf denen Funktionen ausgeführt werden, zu liefern.

Die Überschneidung kann man hier vor allem in Richtung von Entwicklungsgeschwindigkeit und Sprachunabhängigkeit sehen. Bei Containern liegt anschließend vielleicht der Vorteil der Plattformunabhängigkeit, aufseiten von Serverless die einfache Skalierung. Beides lässt aber nicht vermuten, dass eine von beiden Technologien der anderen „überlegen“ ist oder ihr in geraumer Zeit den Rang ablaufen sollte. Vielmehr werden sowohl Container als auch Serverless zum guten Rüstzeug von cross-funktionalen Teams gehören und für entsprechende Herausforderungen eingesetzt werden, um Mehrwert für Kunden zu schaffen.

JAXenter: Vielleicht zum Schluss ein kleiner Blick in die Glaskugel: Wie wird sich die Welt von Continuous Delivery in den nächsten 5 Jahren verändern?

Moritz Heiber: Ich muss nicht einmal in eine Glaskugel schauen, um festzustellen, dass Continuous Delivery zwar bei vielen „en vogue“ ist, aber dessen Prinzipien und Paradigmen in vielen Unternehmen und Entwicklungsteams selten vollumfänglich oder auch nur geringe Beachtung finden.

Viele setzen den Satz „Wir haben Jenkins“ mit Continuous Delivery gleich oder fühlen sich auf der sicheren Seite, weil sie ihren Deployment-Prozess automatisiert haben. Continuous Delivery ist aber ein bedeutend größerer Eisberg, bei dem unter der Wasseroberfläche noch viele Herausforderungen warten und Vorteile genutzt werden wollen.

Das geht von idempotenten Pipeline-Workflows, über Continuous Deployment, der Entkopplung von Release und Deployment, Blue-Green Setups, automatisches Testen, Ende-zu-Ende-Verantwortung, Logging, Monitoring und Alerting, die Integration und Automatisierung von Sicherheits- und Compliance-Aspekten, bis hin zu Testen in Produktion mit Feature Toggles und Canary Releases. Und das ist nur ein kleiner Teil der Themen, auf die man ein Auge werfen sollte, wenn man die Ideale hinter Continuous Delivery ernst nehmen und die Vorteile vollumfänglich nutzen möchte.

Ich wünsche mir, dass mehr Teams diese Herausforderungen ganzheitlich betrachten und in Zukunft nicht nur punktuell versuchen, die gerade am Markt am intensivst propagierten Lösungen zu adaptieren. Wenn dieser Wunsch in 5 Jahren Realität ist, dann ist Continuous Delivery ein ganzes Stück weiter gekommen.

JAXenter: Vielen Dank für dieses Interview!

Moritz Heiber ist Infrastructure Consultant bei ThoughtWorks. Er bezeichnet sich selbst als DevOps Birth Assistant und hilft Kunden dabei, ihre infrastrukturellen und operativen Herausforderungen bzgl. verteilter Umgebungen mit der Kraft und den Werten von DevOps zu meistern. Moritz sieht seine Bestimmung unter anderem darin, Computer zu überlisten – schafft das aber, wie er zugibt, nicht besonders oft.
Geschrieben von
Dominik Mohilo
Dominik Mohilo
Dominik Mohilo studierte Germanistik und Soziologie an der Goethe-Universität in Frankfurt. Seit 2015 ist er Redakteur bei S&S-Media.
Kommentare

Hinterlasse einen Kommentar

Hinterlasse den ersten Kommentar!

avatar
4000
  Subscribe  
Benachrichtige mich zu: