Docker war vor einigen Jahren eine clevere Idee. In abgespeckten virtuellen Maschinen wird – vereinfacht gesagt – nur noch die gewünschte Anwendung virtualisiert. Dadurch wird der Container schlank, transportabel und skalierbar. Haken an der Sache: das Handling und die Konfiguration solcher Umgebungen ist alles andere als trivial.
Kubernetes ist angetreten, das alles zu vereinfachen. Die Bereitstellung, Skalierung und Verwaltung von Docker- und anderen Containerumgebungen kann damit automatisiert werden. Ursprünglich von Google entworfen wird Kubernetes heute von der Cloud Native Computing Foundation (CNCF) entwickelt und verwaltet. Und die hat ein externes Audit ihrer Software in Auftrag gegeben.
Bei Software einer gewissen Komplexitätsstufe kann man nicht von Fehlerfreiheit ausgehen. Im Gegenteil: es gibt statistische Annahmen über die typische Fehlerdichte in Quellcode. Dass in Kubernetes Fehler und Sicherheitslücken gefunden wurden, ist also nicht weiter verwunderlich. Die CNCF dokumentiert alles sauber, verfasst Whitepaper und analysiert Angriffsszenarien mit dem Ziel, Administratoren beim Abdichten ihrer Systeme zur Hand zu gehen. Naja, und behoben werden die Schwachstellen natürlich in Zukunft auch. Also alles gut?
Der Sicherheitsexperte Felix von Leitner, kein Unbekannter im Umkreis des Chaos Computer Clubs, sieht das anders. Seine Analyse hebt darauf ab, dass 37 Sicherheitslücken (davon fünf schwere) längst nicht alles sein können, wenn ein Team von Auditoren ein Projekt dieser Größenordnung für mehrere Monate durchleuchtet. Schlimmer noch: die Ergebnisse deuten darauf hin, dass der untersuchte Code viel zu komplex ist, als dass die Prüfer ihn auch nur annähernd verstanden haben können. Das schreiben die Prüfer sogar in ihren Bericht hinein. Ob es dann so clever von der CNCF ist, mit diesem Bericht hausieren zu gehen, darf man bezweifeln.
Von Leitner glaubt auch, die Ursache für die Zustände ausgemacht zu haben. Er verurteilt agile Methoden als zu anfällig für nachlässige Qualitätskontrolle, vernachlässigte Codestruktur, schlampige Dokumentation und Zeitdruck, der all diese Symptome verursacht. Ehrlich gesagt: ich befürchte, dass es nicht speziell der agile Ansatz ist, der Software unsicher macht. Das klappt mit anderen Entwicklingsmodellen ebenso. Um die Arbeit, den Schweiß und die Zeit, die es kostet Software sicher zu machen, kommt man mit keiner Methodologie herum. Und der erste Schritt in die richtige Richtung ist es, sich das immer wieder vor Augen zu halten.
