Fefes Blog

Fragen? Antworten! Siehe auch: Alternativlos

Thu Aug 8 2019

• [l] Kubernetes wurde auditiert und der Bericht veröffentlicht. Das Ergebnis: 37 Sicherheitslücken gefunden, davon 5 mit hoher Gefahr. Die Zahlen sind erstmal belanglos, solange wir nicht wissen, wie viele Leute wie lange gesucht haben. Die Primärquelle schreibt:

  The Security Audit Working Group managed the audit over a four month time span.

  OK. Also das ist dann ziemlich katastrophal. Wenn die Auditoren nach vier Monaten Arbeit nur 37 Bugs gefunden haben, bei einem Projekt dieser Größe, dann heißt das im Allgemeinen, dass der Code so komplex und unverständlich war, dass man nicht entscheiden konnte, ob etwas ein Bug ist oder nicht, bis man da eine Woche dran herumgeforscht hat.

  Leider klingt das auch hier so:

  Die Prüfer haben sich allerdings bei der Untersuchung auch nur auf acht Kernkomponenten der Software beschränkt und nur jene Probleme der Implementierung betrachtet, die "offensichtlich falsch" seien. Auch habe der Fokus der Untersuchung eher auf "Breite statt Tiefe" gelegen.

  Das klingt nach Nebelwand-Jargon für "wir haben nach Bugs gegreppt". Nach Bugs greppen macht man, wenn ein Projekt zu komplex ist, um es in der gegebenen Zeit sinnvoll zu verstehen zu versuchen. Bei vier Monaten Zeit könnt ihr euch ja selbst überlegen, wie krass überkomplex und unterverständlich das Projekt sein muss, damit Auditoren das machen. Der andere Indikator dafür ist "wir haben Fuzzing gemacht".

  Die Auditoren kritisieren auch die hohe Komplexität von Kubernetes. Wir erinnern uns: Kubernetes war das Tool, das uns vor der Komplexität von Containern retten sollte. Das ist jetzt selber so komplex, dass es ein Rettungsprojekt braucht.

  So wird Kubernetes als System mit "erheblicher Komplexität" bezeichnet. Ebenso seien die Konfiguration und das Deployment nicht trivial. Das wieder liege an "verwirrenden Standardeinstellungen, fehlenden Steuerungselementen und nur implizit definierten Security-Kontrollelementen".

  […] So habe die riesige Codebasis große Teile mit nur "minimaler Dokumentation" sowie zahlreiche externe Abhängigkeiten. Außerdem gebe es viele Stellen, an denen bestimmte Programmlogik einfach reimplementiert wird.

  Das, meine Damen und Herren, ist das Ergebnis von agilen Methoden in der Softwareentwicklung. Genau das passiert, wenn man ein Projekt agil implementiert. Dann wird solange gefrickelt, bis den Use Case abdeckt, aber die interne Struktur ist Kraut und Rüben, Dokumentation "machen wir später" und sowas wie Codestruktur gibt es nicht oder nur zufällig.

  Mir ist ja echt schleierhaft, wieso immer noch Leute auf diesen Agil-Hokuspokus reinfallen. Ich hatte gehofft, die Zeit von Wunderheilern und anderem Aberglauben ist vorbei. (Danke, Marian)