Karsten Klein & Thomas Schulte 04. Dezember 2018

Container-Technologie – Segen und Fluch

Vertrauensvorsprung für eine disruptive Technologie

Container und Container-Orchestrierungstechnologien halten weiter Einzug in die Unternehmen. Docker, rkt, LXC und Kubernetes sind aktuell wohl die bekanntesten Vertreter. Sie ergänzen etablierte Virtualisierungsansätze oder lösen diese einfach und effektiv ab. Aus dem anfänglichen Hype ist eine ernstzunehmende Technologie erwachsen, die schon jetzt eine Erfolgsgeschichte ist und das Fundament für zukünftige Innovation sein wird.

Container – Aus dem anfänglichen Hype ist eine ernstzunehmende Technologie erwachsen. © Dmitry v. Petrenko / Fotolia.com — © Dmitry v. Petrenko / Fotolia.com

Der zentrale Vorteil von Containern liegt in der Einfachheit der Handhabung. Mit wenigen Kommandos können Container-Images heruntergeladen, weitere Container-Images abgeleitet, ein Container instanziert oder Container-Images publiziert werden. Systeme werden aus einer Vielzahl von Containern aufgebaut, integriert und über Werkzeuge wie Docker Swarm, Kubernetes oder Apache Mesos orchestriert.

Segen und Fluch

Aus Perspektive der Softwareentwickler ist diese Technologie ein Segen. Arbeitsabläufe, Test, Testbetrieb, Rollout und Produktivbetrieb werden erheblich vereinfacht und beschleunigt. Zudem haben Container insbesondere im Vergleich zu Images von virtuellen Maschinen einen reduzierten Ressourcenbedarf.

Was für die Einwicklung ein Segen ist, kann für andere Disziplinen im Unternehmen ein Fluch sein. Versucht man Container im Rahmen einer Unternehmenssicht einzuordnen, wird klar, dass hierfür ein tieferes Verständnis für die Technologie erforderlich wird. Durch die Vereinfachung entsteht großes Potential für Versäumnisse, sowohl in der eigenen Entwicklung, als auch in der Entwicklung der Zulieferer. Denn während ein Container in seiner Außenwirkung die Komplexität eines Software-Stacks versteckt, gelten weiterhin für alle verwendeten Komponenten und deren Zusammenspiel rechtliche, regulatorische und vertragliche Verpflichtungen. Unbemerkt unterwandern so neue Technologien bestehende Unternehmensrichtlinien. Die Geschwindigkeit und Eleganz einer neuen Technologie war schon immer ein trügerischer Schutz vor Versäumnissen und den damit einhergehenden Verstößen.

Perspektive License Compliance

Schaut man aus dem Blickwinkel eines License-Compliance-Managers oder Spezialisten für IT-Recht auf einen Container liegt der Vergleich mit der Büchse der Pandora oft nah:

Meist sind Lizenzhinweise unscharf, unvollständig oder wurden sogar vollständig entfernt (Stichwort: Pico-Container).
Die Frage nach der Plausibilität, Vereinbarkeit und Erfüllung der Lizenzverpflichtungen bleibt bereits an der Quelle eines Basis-Container-Images unbeantwortet.
Ohne weitere Informationen, Werkzeuge und Aufwand kommt das Unternehmen kaum zu einer Aussage, wie sicher die Software im Container ist und welche bekannten Sicherheitslücken von Relevanz sein können.
Die Technologie geht über den Rahmen eines Containers hinaus, d. h. es gilt die Lizenz jedes Container-Images und der darin enthaltenden Inhalte zu überblicken. Dabei gibt es insbesondere bei letzterem massive technologische Unterschiede. Jede Linux-Distribution handhabt Lizenz- und Copyrightinformationen anders, auf sehr unterschiedlichen Qualitäts- oder Detailebenen. Die Patch-Policies sind grundlegend unterschiedlich, da sie verschiedenen Philosophien und Notwendigkeiten folgen.

Ohne einen Dialog der Disziplinen im Unternehmen (hier konkret: Entwicklung – License-Compliance-Management – IT-Recht-Spezialist) ist eine realistische Bewertung kaum möglich. Zumal jedes Unternehmen auch gegenüber dieser neuen Technologien zu einem eigenen Rechtsverständnis und einer eigenen Bewertung und Positionierung kommen sollte. Eine einseitige Ad-hoc-Bewertung, eine unmittelbare Nutzung oder Weitergabe erscheint in diesem Licht eher unprofessionell und fahrlässig.

Aber "Deckel-drauf,-Augen-zu-und-durch" darf und kann für Unternehmen, die in der Verpflichtung stehen, Risiken zu erkennen, zu bewerten und zu reduzieren, nicht die gängige Praxis sein.

Ansatz

Die Situation ist prinzipiell nicht aussichtslos. Denn die Verpflichtungen der Lizenzen, auf denen die meisten Linux-Distributionen und Container-Basis-Images beruhen, sind prinzipiell erfüllbar. Zur Erreichung eines Komfortbereiches der License Compliance bzw. eines gewünschten Compliance-Risikoniveaus erfordert es ein substantielles Grundverständnis und den tatsächlichen Willen zur Umsetzung.

Eine einheitliche Haltung der entwickelnden Industrie in Deutschland und international ist in diesem Zusammenhang nicht erkennbar. Vorgaben, Richtlinien und Prüfverfahren, insbesondere solche, die auch diese Technologien der aktuellen Generation mit einbeziehen, fehlen. Die Rechtsprechung in diesem Bereich ist zu speziell, um die Grauzone aufzulösen. Um zukunftssicher, handlungsfähig, konkurrenzfähig und schuldlos zu bleiben, investieren besonders große, namhafte Unternehmen in die Compliance ihrer Produkte. Gerade das Fehlen einer Betrachtung kann zum denkbar ungünstigsten Zeitpunkt einen empfindlichen Schaden für ein Unternehmen bedeuten.

Sieht ein Unternehmen vor, container-basierte Lösungen in einem produktiven Betrieb zu nutzen oder an weitere Empfänger in einer Lieferkette weiterzugeben, sollten folgende Grundlagen umgesetzt werden:

Externe Container-Images werden nur aus ausgewählten Quellen bezogen.
Externe Container-Images sind entsprechend eigener Richtlinien zu verifizieren.
Ableitungen von eigenen Container-Images können über definierte Abläufe reproduziert werden.
Modifikationen an Fremdkomponenten sind durch eigene Richtlinien eingeschränkt und werden durch Reviews oder Werkzeuge beim Erzeugen der Ableitungen geprüft.
Aktive Inventarisierung der Software-Komponenten – insbesondere der Komponenten Dritter – zur Prüfung gegen eigene Richtlinien.

Dabei sind die Inhalte der aufgeführten eigenen Richtlinien hier offen gelassen. Letztendlich sind die Ziele dieser Richtlinie Sache des Unternehmens, bzw. ergeben sich aus den regulatorischen, gesetzlichen und vertraglichen Rahmenbedingungen aus der Perspektive und dem Risikoappetit der Unternehmensführung.

Fazit

Die aktuelle Evolutionsstufe kann nur eine Station auf dem Weg zur Professionalisierung einer vielversprechenden Technologie sein. Container sind aus Sicht der Compliance und insbesondere aus dem Blickwinkel des License Compliance Managements komplex und anspruchsvoll. Über die aktuellen Risiken und Nebenwirkungen und mögliche Zielvorstellung sollte in der Industrie ein Konsens erörtert und durch Verbesserungen umgesetzt werden. Jedes Unternehmen, das mit Containern hantiert, sollte sich dieser Aspekte bewusst sein.

Von einer Microservice-Architektur basierend auf einer Serverless Infrastructure, die das Prädikat Compliance-by-Design trägt und dem wachsenden gesellschaftlichen Transparenzverständnis gerecht wird, sind wir, mit den aktuell heterogenen Inhalten, existierenden Standards und Qualitätsargumenten, in der Umsetzung wohl noch weit entfernt.

Begriffsklärung

Container: Ein Container setzt sich aus Container-Images zusammen und stellt einen Laufzeit-Prozess dar, der vorbereitet, gestartet, gestoppt und wieder entfernt werden kann. Ein Container kann als solches nicht ausgeliefert werden. Zur Auslieferung kommen das oder die Container-Images (Filesystem-Abbild), die den Container ausmachen.
Container-Image: Ein Container-Image ist eine physikalische Datei, die einen bestimmten Aspekt zu einem Container beisteuert. Container-Images können von einem anderen Container-Image (parent) abhängen bzw. darauf aufbauen.
Layer: Je nach Technologie kann ein Container-Image mehrere Layer enthalten. Layer beziehen sich auf das Dateisystem im Container. Auf einem Layer können Dateien ausgeblendet, ergänzt oder überlagert werden. Dies entspricht einer Modifikation im Sinne vieler gängiger Lizenzen.
Nodistro-Images: Images ohne Bezug zu einem Betriebssystem/ einer Linux-Distribution.
Pico-Container: Basis-Container-Image mit stark reduzierter Größe. Oft werden hier etwa Lizenzinformation entfernt. Prinzipiell ist die Weitergabe solcher Container ohne ergänzende Dokumentation problematisch zu sehen. Der Begriff wird auch in Bezug auf minimalistische Dependency-Injection-Frameworks genutzt.
Vereinbarkeit von Lizenzen: Software ist einem Geschäftskonzept, einem Markt und einem Verwendungszweck zuzuordnen. Bedingungen und Verpflichtungen aus Softwarelizenzen können diesen entgegenwirken,
- da sie den Verwendungszweck einschränken und damit im Konflikt des Marktes oder Zielverwendungszwecks stehen,
- da sie im Konflikt zu anderen Lizenzen oder Marktregularien stehen oder
- da sie im Konflikt mit dem Geschäftskonzept stehen; etwa eine Non-Commercial-Lizenz in einem kommerziellen Umfeld.