Ein Kommentar

Quality-Gates für Microservices

Eine der wichtigsten Vorteile, der im Rahmen von DevOps entstehenden Vollautomatisierung aller Vorgänge, ist die Möglichkeit, Tests in verschiedene Phase des Entwicklungprozesses einzuhängen. Dabei ist unser Vorschlag, die Testphasen jeweils mit einem Sicherheitsaspekt zu beenden.

Laut der oben gezeigten Grafik darf also kein Artefakt erzeugt werden, wenn die Threat Analyse angreifbare Packages identifiziert hat. Im Rahmen einer „echten“ CI-Umgebung ist das für alle Entwickler schmerzfrei, da bereits beim ersten Checkin die Rückmeldung erfolgt, dass die/das neu hinzugefügte Library/Package problematisch ist.

Die Übersichtsgrafik zeigt ein weiteres typisches Problem auf: Es existieren mindestens 10 verschiedene Quality-Gates auf verschiedenen Ebenen und diese werden multipliziert mit der Anzahl der Microservices. Zwar kann man in den verschiedenen Test-Logs (z. B. Jenkins) von Hand nachschauen, aber Spaß macht das für ein hinreichend komplexes Teilsystem nicht!

UI-Unterstützung

In der CME Workbench werden die verschiedenen Quality-Gates visualisiert, hier z. B. auf der Microservice-Ebene:

Im folgenden Beitrag beschreibe ich die Tests, die in der Basisversion der CME Workbench beispielhaft angelegt und in die UI integriert wurden.

Quality-Gates während der Build-Phase

Während des Builds eines einzelnen Microservices werden folgende Tests parallel ausgeführt:

  1. Unit-Tests
  2. Code-Coverage
  3. Clean Code
  4. Threat Analysis (Package-Ebene)

Alle Tests werden ausgeführt und die Ergebnisse in einer Datei summary.json zusammengefasst. Diese wird als ein Artefakt des letzten Build zurückgeliefert. Über den Jenkins-Adapter kann die CME Workbench für einen Microservice die entsprechende Information per REST API abrufen.

Die Leistung der CME Workbench für das DevOps-Team besteht also darin, einen Rahmen zu schaffen in dem die einzelnen Quality Gates normiert und automatisiert abgreifbar sind.

Punkt 4 in obiger Liste – die Bedrohungsanalyse – kann z. B. über den OWASP Dependency Check durchgeführt werden, wobei bekannte Open-Source-Pakete hinsichtlich ihrer Angriffsfläche beurteilt werden. Da die o. g. Tests alle auf dem Build-Server ausgeführt werden, kann z. B. ein Jenkins-Plugin verwendet werden.

Die Kriterien, ab wann ein Build als erfolgreich angesehen werden kann, sind übergreifend für alle Microservices zu definieren. Die CME Workbench macht hierbei (außer einer Farbcodierung) keinerlei Vorgaben.

Quality-Gates auf dem Integrationssystem

Auf dem Integrationssystem werden folgende Tests ausgeführt:

  1. Synthetische Workflows
  2. API-Contracts (Swagger-basiert)
  3. Load-Test (KPI), z. B. über Workflows
  4. e2e coded UI Tests
  5. Penetration Tests

Die Integrationstests sind in der CME-Workbench auf einer separaten Seite (mit dem Reagenzglas-Icon) zusammengefasst. Dort befindet sich z. B. auch die Ausgabe der synthetischen Workflows:

Das synthetische Monitoring bietet eine gute Basis für den Load-Test, der z. B. über Gatling durchgeführt werden kann. Der Load-Test liefert wichtige KPIs (Key Performance Indicators), die darüber entscheiden, ob der Microservice so auf Produktion überführt werden kann: wenn in einem Online-Shop-System die erwartete Anzahl der Bestellvorgänge pro Minute anstatt bei 100 nur bei 2 liegt, wird man über Profiler-Calls zunächst die Ursache dafür feststellen wollen:

Da es bei Load-Tests in der eigenen Infrastruktur einige Klippen zu umschiffen gibt, empfiehlt es sich (falls Sicherheits-technisch möglich) einen externen Service wie flood.io zu nutzen. Dabei sollte man darauf achten, dass die Ergebnisse per API oder Jenkins integrierbar sind.

Die Penetration Tests können z. B. über ZAP (Zed Attack Proxy) durchgeführt werden. Dieser benötigt eine Start-URL, über die er als Spider die UI durchsuchen und z. B. XSS-Angriffsflächen identifizieren kann. Dabei liefert der ZAP-Report eine Liste von Findings, gruppiert nach der Auswirkung („schwer“, „mittel“, „gering“, „info“), der eine detaillierte Liste mit entsprechenden Erklärungen folgt.

Auch dieses Tool kann per Jenkins-Plugin in den CI-Workflow integriert werden.

Quality-Gates auf dem Produktivsystem

Die Quality-Gates auf dem Produktivsystem zählen zu den Akzeptanztests: z. B. wird beim Hinzufügen von neuen Funktionen zu einem Online-Shop getestet, ob diese vom Benutzer wirklich verstanden/angenommen werden.

Für viele Software-Unternehmen, die seit Jahrzehnten in fixen Releases denken, stellen Quality-Gates auf Produktivsystemen eine der am härtesten zu schluckenden „Kröten“ dar. Dies ist vor allem auf den Umstand zurückzuführen, dass die DevOps-Prinzipien „automation & insight“ dort nie gelebt wurden. Rückmeldung erfolgte stets durch den Endkunden oder indirekt über die zentrale Hotline-Abteilung – eine aktive Erfolgsanalyse durch das Entwicklungs- oder Operations-Team stand nie auf der Agenda.

Fazit

Auch wenn viele professionelle Software-Entwickler die o. g. Quality-Gates schon lange kennen bzw. täglich benutzen, ist es in einer Microservice-Umgebung dennoch eine Herausforderung, die Ergebnisse zu integrieren. Als übergreifende UI kann die CME Workbench hier einen schnellen Start in ein eigenes DevOps-Tooling bieten.

Ein Kommentar

Kommentar schreiben

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.