Die neueste Hauptversion von cnquery und cnspec haben die größte Änderung seit ihrer Gründung eingeführt! Wir haben Monate damit verbracht, die Grundlagen beider Projekte zu überarbeiten, um sie auf eine wachsende Gemeinschaft und eine dauerhafte Zukunft vorzubereiten.

Wir wollten schon immer, dass unsere Benutzer ihre eigenen Anbieter (steckbare Komponenten, die Funktionen hinzufügen) erstellen können, um die Projekte nach Belieben zu erweitern. Das explosive Wachstum der Arten von Technologien, die wir unterstützen, war ein starkes Indiz für dieses Modell.

Gleichzeitig wollten wir sicherstellen, dass sowohl cnquery als auch cnspec für jede Umgebung flexibel genug sind (einschließlich eingebetteter Geräte und anderer winziger Laufzeiten). Es wurde uns klar, dass sich beide Projekte ändern mussten.

Tatsächlich wurden mit diesem Update 2.357 Dateien geändert und insgesamt 536.512 Codezeilen geändert. Wir haben die Größe beider Binärdateien um 90% reduziert. Wir haben nicht nur erweiterbare Anbieter eingeführt, sondern auch cnquery und cnspec vollständig modularisiert und sie um effizientes Caching herum neu aufgebaut.

Erweiterbarkeit

Von Anfang an wurden sowohl cnquery als auch cnspec mit Erweiterbarkeit als Kern entwickelt. Da diese Projekte jedoch als Monolithen gebaut wurden, einschließlich der von uns generierten Binärdateien, war es extrem schwierig, zu ihnen beizutragen, da jeder Beitrag schnell zu einer Änderung des ständig wachsenden Kernprojekts wurde.

Das Testen hat lange gedauert. Änderungsanträge waren schwierig. Die Mitwirkenden mussten alles in Go schreiben. Es musste von Mondoo gebaut und vertrieben werden. Außerdem waren private Anbieter praktisch unmöglich (es sei denn, Sie haben Ihre eigene Binärdatei erstellt).

Mit der Veröffentlichung von v9 änderte sich dies endlich.

Sowohl cnquery als auch cnspec basieren jetzt auf einem vollständig erweiterbaren Ökosystem von Plugin-Anbietern.

Mit v9 verwendet cnquery jetzt die Plugin-Bibliothek von Terraform als Grundlage für alle integrierten und benutzerdefinierten Anbieter. Wir haben uns für diesen Mechanismus für die Erstellung und Wartung von Plugins entschieden, weil er gut getestet wurde und in Produktionsumgebungen so weit verbreitet ist.

Provider-Plugins sind jetzt eigenständige Prozesse, die mithilfe von gRPC und Protokollpuffern mit ihrer Laufzeit kommunizieren. Jetzt kann jeder seinen eigenen Anbieter schreiben, veröffentlichen und verwalten. Es steht Ihnen frei, jede beliebige Programmiersprache zu verwenden, solange das Ergebnis eine ausführbare Datei ist, die dieselbe Plugin-API implementiert.

Mit diesem neuen System ist es sogar möglich, vollständig private Anbieter zu gründen. Dies ist nützlich, wenn Sie MQL-Tools mit Ihren eigenen APIs verwenden möchten, aber deren Implementierung oder SDK nicht an die Außenwelt weitergeben möchten. Andere können aufgrund seines Schemas immer noch Code gegen einen privaten Anbieter schreiben, auch wenn sie keinen Zugriff auf den Anbieter selbst haben.

Beispiele für unsere integrierten Anbieter in GitHub finden Sie in der Ordner cnquery providers.

Es gibt auch Hilfsprogramme, mit denen Sie einen neuen Anbieter finden können:

go install apps/provider-scaffold/provider-scaffold.go
provider-scaffold \
  --path providers/my-name \
  --provider-id my-name \
  --provider-name "My Name" \
  --go-package github.com/user/cnquery-provider-my-name

‍

Jedes Provider-Plugin, das Sie installieren, wird sowohl für cnquery als auch für cnspec (und jede andere MQL-Laufzeit) verfügbar. Dadurch werden doppelte und aufgeblähte Dateien auf dem System vermieden. Wenn es für eine Laufzeit funktioniert, funktioniert es für alle.

Modularisierung

Diese neuen Plugins sind unglaublich einfach zu bedienen. Wir wollten sicherstellen, dass die Benutzer nach dem Update auf Version 9 nichts Neues lernen müssen.

Anbieter installieren und aktualisieren im Handumdrehen und eigenständig. Wenn Sie Ihr lokales System scannen, wird der Betriebssystemanbieter verwendet. Wenn Sie AWS scannen, wird der AWS-Anbieter automatisch installiert. Wenn Sie GitHub scannen, wird der GitHub-Anbieter automatisch installiert. Wenn du Okta scannst... nun, du hast die Idee.

Diese Änderung ermöglichte es uns, unsere wichtigsten Binärdateien klein zu halten (90% kleiner als Version 8) und ihren Sicherheitsbedarf drastisch zu reduzieren, da jetzt nur die erforderlichen Funktionen installiert sind.

Immer wenn Sie einen installierten Anbieter verwenden, prüft er, ob Updates verfügbar sind. Wir wissen, dass die meisten Benutzer Schwierigkeiten haben, die Software auf dem neuesten Stand zu halten. Um einen reibungslosen Ablauf zu gewährleisten, haben wir das Standardverhalten geändert, um bessere Sicherheitspraktiken zu ermöglichen und den Aufwand für den Benutzer zu reduzieren. Und keine Sorge, es gibt Sicherheitsvorkehrungen, die verhindern, dass das System zu oft überprüft wird.

Am wichtigsten ist, dass Sie die Kontrolle behalten. Sie können die Funktion zur automatischen Installation und automatischen Aktualisierung vollständig deaktivieren. Dies ist nützlich für Container und serverlose Umgebungen. Für diese Umgebungen empfehlen wir, cnquery oder cnspec mit der Untergruppe der Anbieter zu installieren, die Sie voraussichtlich verwenden werden. Ihre Versionen werden dann angeheftet und Sie können automatische Updates mithilfe der CLI deaktivieren (--auto-update=falsch) oder die Konfigurationsdatei (auto_update: falsch). Dadurch wird sichergestellt, dass die Container nicht bei jedem Lauf versuchen, neue oder aktualisierte Anbieter zu installieren.

Alle Anbieter (außer Core, zum Zeitpunkt der Erstellung dieses Artikels) sind jetzt optional. Das heißt, wenn Sie den Betriebssystemanbieter nicht verwenden möchten, müssen Sie ihn nicht installieren. Wenn Sie der Meinung sind, dass Ihr cnspec nur Azure oder Google Cloud scannt, installieren Sie nur diese Anbieter. Aus Sicherheitsgründen ist das großartig, da der Betriebssystemanbieter (der mit dem lokalen System interagiert) nicht verfügbar ist, wenn Sie automatische Updates deaktivieren.

Caching und Aufzeichnungen

Die letzte Änderung, die wir in Version 9 eingeführt haben, befasst sich mit dem Caching im Kern. Vor dieser Version konnten wir nur Anrufe zwischenspeichern und teilen, die auf dem Betriebssystem getätigt wurden. Diese Einschränkung ist jetzt aufgehoben.

Mit der Veröffentlichung von v9 stehen uns nun umfassende Caching- und Aufzeichnungsfunktionen für alle bestehenden, benutzerdefinierten und zukünftigen Anbieter zur Verfügung. Dies ermöglicht es uns nicht nur, die Anzahl der Aufrufe (teurer) APIs stetig zu reduzieren, sondern es hilft uns auch beim Debuggen und beim Eintauchen in die gesammelten Daten.

Wir werden die Caching-Ebene in kommenden Versionen weiter erweitern. Mit der Einführung der Aufnahmefunktion können wir jetzt jede Datenebene für unsere Sammlung und Wiedergabe verwenden.

Derzeit unterstützen wir das Cachen/Aufzeichnen in lokalen JSON-Dateien. Diese können mit jedem unserer Kernbefehle verwendet werden: scan, run oder shell. Das bedeutet, dass Sie ein Ziel scannen und alle Daten sammeln können, die in einer Datei verwendet werden. Oder Sie können eine interaktive Shell öffnen und alle gesammelten Ressourcen und Felder erfassen. Beide Funktionen sind für Diffs, Drifts und Debugging-Zwecke hilfreich (da die Person, die Ihre Aufnahme verwendet, keinen Zugriff auf das Zielsystem benötigt).

Wir werden diese Funktion bald erweitern, um mit zusätzlichen Daten-Backends zu arbeiten. Wenn Sie einen registrierten Kunden haben, können Sie Mondoo als transparente Datenebene verwenden und die Anzahl der teuren (und drosselnden) API-Aufrufe massiv reduzieren. Bleiben Sie dran: Wir freuen uns, diese neue Funktion in naher Zukunft ankündigen zu können!