Continuous Lifecycle / ContainerConf, Februar 2021, online: Vortrag von Benjamin Tokgöz (@benn0rs, Cloud Solution Architect bei Microsoft) & Josef Fuchshuber (@fuchshuber, Director of Quality, Productivity & Innovation bei bei QAware)
== Dokument bitte herunterladen, falls unscharf! Please download slides if blurred! ==
Abstract: Status quo: Chaos Engineering
Die Prinzipien des Chaos Engineering sind nicht neu. Beim Chaos Engineering werden Experimente am „lebenden System” durchgeführt. Es werden Ausfälle absichtlich herbeigerufen oder Systeme in widrigste Umstände gebracht. Immer mit dem Ziel Schwachstellen zu finden, frühzeitig zu beheben und dadurch stabilere Systeme und Vertrauen in das System zu bekommen.
Durch den Einzug von Microservice-Architekturen und die damit verbundene Vervielfältigung des Verteilungsgrades hat sich die Daseinsberechtigung für Chaos Engineering dramatisch erhöht. Denn die Komplexität des Runtime-Layers kann bei Microservice-Architekturen sehr schnell ins Unermessliche führen.
Dieser Talk führt in die Prinzipien des Chaos Engineering ein und zeigt den aktuellen Stand der Werkzeuge mit denen Experimente an Cloud-Native-Plattformen und -Applikationen durchgeführt werden können.
8. Wie neu sind die
Chaos Engineering
Ideen?
img source: https://www.gettyimages.de/detail/foto/woman-screaming-with-joy-opens-carton-parcel-box-lizenzfreies-bild
9. Wobei hilft uns Chaos Engineering?
§Battle Test für neue Infrastruktur und Services
§Quality Review: Kontinuierlich die Robustheit von Anwendungen verbessern
§Post Mortem: Reproduktion von Ausfällen
§On-Call Training
13. "Chaos Engineeringwithout observability … is just chaos"
@mipsytipsy, CEO of honeycomb
img source: https://www.gettyimages.de/detail/foto/burning-car-lizenzfreies-bild/168266695
15. Produktionsnah starten und nicht gleich in PROD
§ Die ersten Experimente sollte man eine Umgebung wählen, die identisch mit der in
Produktion ist. Nur dann kommt man zu aussagekräftigen Erkenntnissen.
§ Infrastruktur und integrierte Services wie in PROD (keine Mocks)
§ Applikationskonfigurationen analog zu PROD
§ Sobald die ersten Schritte getan sind und es zu Verbesserungen kam, kann der Weg
weiter in Richtung Produktion gehen.
§ Ziel sollte es aber sein, Tests in PROD zu machen:
§ Echte Kundenlast ist nie wie die von Lastgeneratoren oder Akzeptanztests.
§ Sie interagieren oftmals anders mit den Services als erwartet.
17. Die Phasen des Chaos Testings
Steady State
Hypothese
Experiment
ausführen
Verifikation
Analysieren
und
Verbessern
18. Design und Ausführung von Experimenten
§ Stelle eine Hypothese auf
§ Beispiel: Wenn die Datenbank von meinem Webshop ausfällt, erscheint vor Kunde eine Fehlerseite
mit einer Kontaktmöglichkeit zum Support-Team
§ Designe den Umfang Ihres Experiments
§ Beispiel: Wie kann der Ausfall simuliert werden: Datenbank-Server herunterfahren, fehlerhafte
DNS-Routen eintragen, Netzwerkprobleme simulieren
§ Lege die für das Experiment relevanten Metriken fest
§ Beispiel: Health Check der Datenbank, HTTP Response Status Code 200
§ Informieren vor der Durchführung dein Team
§ Beispiel: Wenn ihr auf Shared-Environments experimentiert, Informiert immer das komplette Team
über eure Experimente.
20. Man startet bei den Experimenten klein.
§Erst wenn ein Experiment erfolgreich war, wird der Blast-Radius vergrößert:
§ Weitere Komponenten oder Services werden hinzugenommen
§ Last, Fehlerquoten und Latenzen werden erhöht
§ ...
Blast-Radius
21. Die Eigenschaften der Chaos
Engineering Tools sind vielfältig
§ Kommerziell oder Open Source
§ API oder Operator basierend
§ Support des Chaos Engineering Levels
§ Zufallsbasiert oder experimentbasiert
Es gibt momentan nicht den "One-Stop-Shop", der alle Teams glücklich macht.
22. Chaos Engineering hat in der CNCF-
Landkarte eine eigene Kategorie
https://landscape.cncf.io/card-mode?category=chaos-engineering&grouping=category (Stand 01. Feb. 2021)
26. Penetration Testing + Chaos Engineering
Wissen aus dem Penetration Testing nutzen um mehr
Erkenntnisse über die eigene Infrastruktur zu gewinnen
Gezieltes einsetzen gängiger Tools um Schwachstellen zu
erkennen
Direkte Anbindung an Monitoring-Tools – wenn möglich
27. Use Cases für
Security Chaos
Engineering
Erkennung von Vulnerabilities in
der Software
Dediziert für jeden
Microservice
Kompetenzaufbau bei eigenen
Mitarbeiter zum Thema Exploits
Architektur und
Netzwerkentscheidungen
reviewen
29. Security Chaos Engineering
• Ein Event (oder auch Game day) um direkte und verwertbare Ergebnisse zu erhalten
• Angriffe auf das System beziehen sich hierbei klar auf Exploits und Vulnerabilities
• Reportings werden in Echtzeit von Penetration Testern, Security Engineers, Software
engineers, Business Stakeholdern und Mitgliedern der IT generiert und ausgewertet.
30. Besonderheiten beim Security CE.
Genau wie beim klassischen Chaos Engineering werden verschiedene bekannte Schritte durchlaufen
Aktuelle Bestandsaufnahme des Systems
Entwickeln einer Hypothese
Angriffsgrenzen festlegen
Fallback Pläne erstellen
In Kenntnis setzen der Organisation
Durchführung des Game days
Monitoring, Validation und Fazit
Reconfiguration des vorgesehenen Systems
Automatisiere das Experiment
32. Nmap
Automatisierung über bash scripts
Klassiker
https://github.com/nmap/nmap
Automatisierung über CI Plattformen wie GitHub
33. OWASP ZAP
Automatisierung über (z.B.) python scripts
Klassiker
https://github.com/zaproxy
Automatisierung über CI Plattformen wie GitHub
34. Metasploit Framework
Metasploit interaktiv nutzen während eines Game day
Metasploit automatisieren über resource scripts
Metasploit automatisieren über ruby scripts
Automatisierung über CI Plattformen wie GitHub
Klassiker
https://github.com/rapid7/metasploit-framework
36. Empfehlungen
und
best practices
Ändert nie mehr als eine Variable zu
einer bestimmten Zeit
Kenne den Blast radius des Game
days!
Integriert die Ergebnisse in euer SIEM
Quelle: Securing chaos: How Security
Chaos Engineering tools can improve
design and response (rsa.com)
37. Buchempfehlung
für Secure Engineering
Author:
Ross Anderson
Title:
A guide to building dependable distributed systems
https://www.wiley.com/en-
us/Security+Engineering%3A+A+Guide+to+Building+Dependable+Di
stributed+Systems%2C+3rd+Edition-p-9781119642817
41. Zusammenfassung
§ Das wichtigste am Chaos Engineering ist, dass man es macht:
§ Gamedays im gesamten Team sollten in jedem Team ein festes Ritual sein.
§ Startet in einer produktionsnahen Umgebung und prüft ob euer Monitoring ausreichend ist.
§ Werkzeuge kommen und gehen:
§ Die Chaos Engineering Werkzeuge im Cloud Native Ökosystem entwickeln sich weiter.
§ Der Kontext eurer Chaos Engineering Experimente wird sich erweitern.