logo_w

Zürich DevSecOps Meetup

Vielen Dank, Jan, dass du das mit uns geteilt hast https://www.linkedin.com/pulse /z%25C3%25BCrich-devsecops-meetup-jan-jambor

Das zweite Zürich DevSecOps Meetup organisiert von < a href=“https://www.linkedin.com/in/retokaeser/“ target=“_blank“ rel=“noreferrer noopener“>Reto und Ken von astarios mit Unterstützung des „DevOPS“-Unternehmens VSHN und gehostet von Swisscom.

zurich devsecops meetup

DEVSECOPS-AUTOMATISIERUNG MIT OPEN-SOURCE-TOOLS

Der erste Teil war eine Präsentation mit einigen Demos von Ken. Er hat an der Automatisierung bestimmter Aspekte seines Entwicklungsprozesses gearbeitet und einige Erfahrungen und Tools mit uns geteilt.

Detecting secrets in your code

Github hat vor kurzem damit begonnen, Repos nach API-Schlüsseln und Passwörtern zu durchsuchen und warnt die Besitzer. Einige haben auch berichtet, dass AWS API-Schlüssel widerruft, die in öffentlichen Repositories gefunden werden. Shhgit erregte kürzlich einige Aufmerksamkeit, da es Informationen über öffentlich geteilte Geheimnisse sammelt.

Wäre es nicht klug, wenn ein Tool Ihnen dabei helfen würde, Geheimnisse in Ihren Commits zu erkennen, bevor Sie sie an Github & Co.? Und das hat Ken uns in seiner ersten Demo gezeigt: Talisman. Als Pre-Commit-Hook installiert, prüft es auf Passwörter und andere Geheimnisse und bricht den Commit ab, wenn etwas gefunden wird.

Für diese Aufgaben stehen auch andere Tools wie <a href=“https://www.sonarqube.org/“ target=“_blank“ rel=“noreferrer noopener“>SonarQube</a> zur Verfügung, die ebenfalls mehr Funktionen bieten.

Where to store secrets

Da wir bereits über Geheimnisse gesprochen haben, haben wir darüber gesprochen, wie man richtig mit ihnen umgeht. Und hier hat Ken einige Tresorlösungen gezeigt. HashiCorp Vault ist eine der bekannteren Lösungen, aber auch alle großen Cloud-Anbieter bieten eigene Lösungen an – wie Azure Key Vault – die auch gut sind. Der Punkt, den Sie berücksichtigen müssen, ist die Portabilität Ihrer Lösung. Es gibt also keine Ausreden mehr für hartcodierte Passwörter, auch nicht zum Testen. Tun Sie das nicht, es wird schnell und hart auf Sie zurückkommen.

Package managers and dependencies

Die Kurzfassung dieses Teils der Demo lautet: Alle Paketmanager sind grundsätzlich kaputt. Wir haben nicht nur eine Menge Abhängigkeiten für einfache „Hallo Welt“-Apps, es gibt auch unbekannte, potenziell unsichere Pakete, die nicht gut aktualisiert sind. Ein Beispiel für SQL-Injections ist im Bild unten dargestellt (Quelle: https://snyk.io/blog).

SQL injection

Die großen SaaS-Quellcode-Repository-Lösungen wie Github haben Sicherheitsüberprüfungen für Paketmanager und Abhängigkeiten Ihrer App eingeführt. Aber auch On-Prem-Lösungen können durch entsprechende Prüfungen in der Build-Pipeline erweitert werden.

Dynamic analysis scanning

Wir haben auch schnell die OWASP-Top-10 besprochen, die sich überraschenderweise (oder nicht überraschend?) Über Jahrzehnte hinweg nicht so sehr verändert haben. Es gibt viele kommerzielle und Open-Source-Tools, die Sie bei der dynamischen Analyse unterstützen. OWASP selbst hat eine riesige Liste von Tools auf seiner Website.

Infrastructure as code

Auch Infrastructure as Code ist ein großes Thema. Meistens ist es stark auf Komponenten und Bilder angewiesen, die aus öffentlichen Ressourcen stammen. Genau wie die oben erwähnten Paketmanager verfügen wir über unbekannte und möglicherweise unsichere Quellen dieser Komponenten. Hier kommen statische Analysegeräte wie Clair für Docker-Images ins Spiel und helfen bei der Identifizierung potenzieller Probleme.

Update: Ich habe gerade vulnerablecontainers.org gefunden, eine riesige Sammlung von Wenn Sie öffentlich verfügbare Container-Images (z. B. Docker Hub) mit Scan-Ergebnissen verwenden, sollte dies ziemlich alarmierend sein, wenn Sie diese Images sofort in der Produktion verwenden.

Keeping track

Mittlerweile haben wir im Tagesgeschäft eines Sicherheitsbeamten viele verschiedene Werkzeuge und „Lärmquellen“ gesehen. Was wir brauchen, ist eine Möglichkeit, den Überblick über die wichtigen Dinge zu behalten, im Grunde ist ein „Nagios“ für DevSecOPS erforderlich. Ken hat uns Bogenschießen gezeigt, das genau das tut. Es hilft Ihnen, alle Informationen aus den verschiedenen Quellen zu sammeln und in all dem Chaos die wirklich wichtigen Punkte zu identifizieren.

PROJEKT SYN VON VSHN

Der zweite Teil des Treffens wurde von Adrian Kosmaczewski, verantwortlich für Developer Relations bei VSHN, moderiert, der uns das sehr coole kommende Projekt SYN das dabei helfen soll, die 5 großen Punkte von DevSecOPS abzudecken: GitOPS, Wartung, Protokollierung, vertrauenswürdige Quellen und Richtlinienverwaltung.

Einige große Pluspunkte sind in meinen Augen:

Erstens: Alles wird Open Source sein, nicht nur der Code, sondern auch der ganze Diskussion über die Spezifikationen und vor allem die Organisation was einen großen Unterschied macht. Nur ein Projekt auf Github zu stellen, ist in meinen Augen nicht einmal annähernd die vollständige Aufgabe. Versuchen Sie, eines der Apache-Projekte wie Superset in weniger als einem Tag in einem PoC zum Laufen zu bringen, und Sie werden sehen, wovon ich spreche.

Zweitens: Adrian beschrieb es als „niedrig hängende“ Früchte, als er sagte, dass das Projekt SYN in die drei großen Cloud-Anbieter (AKS, EKS und GKE) und auch in bestehende Cluster integriert werden wird. Das ist in meinen Augen ein riesiges Plus. Ich habe nach ähnlichen Lösungen wie dem neuen Controller v3.0 von nginx gesucht, der nur vollständig neu erstellte Cluster auf Bare-Metal oder VMs unterstützt, was aus meiner Sicht ein großes Problem darstellt. Wenn Projekt SYN also auch nur annähernd hält, was hier versprochen wurde: riesig!

Drittens: VSHN isst sein eigenes Hundefutter! Und sie haben mit Abstand die größte Erfahrung, wenn es um Cloud-native-Infrastruktur, Kubernetes und Open Shift geht. Was wir hier also sehen werden, ist, was VSHN jeden Tag antreibt. Und das kann nicht schlecht sein.

Einige Einblicke, die Adrian uns gezeigt hat:

Ein großer Punkt ist die enge Zusammenarbeit mit crossplane. Diese recht neue Lösung hilft bei der Verwaltung von Cloud-nativen Apps und VSHN, indem sie sie nutzt und im Gegenzug dazu beiträgt, ist für beide ein großes Plus. Einige weitere verwendete Tools sind unten aufgeführt (keine vollständige Liste).

GitOPS

  • Basierend auf ArgoCD
  • Signierte Commits werden erzwungen
  • Geheimnisse müssen im Tresor aufbewahrt werden

Wartung

  • Wartung & Aktualisierungen wurden basierend auf renovate verbessert
  • Überblick über offene Wartungs-PRs, um bei Bedarf eine einfache Diskussion und schnelle Maßnahmen zu ermöglichen

Protokollierung

  • basierend auf Prometheus; Alertmanager; Signalio

Containerregistrierung

  • Überprüfung und Validierung von Bildern, automatische Schwachstellenscans
  • kompatibel mit K8s und OpenShift
  • zentrales Register & Inventar basierend auf lieutenant und steward

Richtlinienverwaltung

  • basierend auf dem CNCF Open Policy Agent

WAS KOMMT ALS NÄCHSTES

Das zweite Zürich DevSecOps Meetup war ein großer Erfolg in meinen Augen. Ich freue mich schon sehr auf das nächste Treffen.

In der Zwischenzeit gehe ich zum Praktischer Workshop zu Best Practices für Docker-Image-Sicherheit der am 9. März 2020 stattfindet (soweit ich weiß, ausgebucht, aber wenn Sie Interesse haben, tragen Sie sich in die Warteliste ein). Und natürlich bin ich beim DevOPS Day Zurich im September 2020 dabei.

Ihr Formular wurde erfolgreich übermittelt
Wir werden Sie in Kürze kontaktieren