Bottlerocket - Minimales unveränderliches Linux-OS mit verifiziertem Boot
(bottlerocket.dev)- Bottlerocket ist ein Linux-basiertes OS für Container-Hosting und dient als Basisbetriebssystem für Worker-Nodes in Clustern, die von Orchestratoren wie Kubernetes verwaltet werden
- Mit einer Minimal-Konfiguration, bei der die Pakete, Werkzeuge und Interpreter allgemeiner Distributionen entfernt wurden, verringert es den Betriebsaufwand und die Angriffsfläche und bietet über Varianten nur die jeweils benötigten Kombinationen für die jeweilige Umgebung
- Es gibt weder eine Shell noch einen Paketmanager; das System wird über privilegierte Host-Container und eine API verwaltet, und Updates werden atomar per Image und Partitionswechsel angewendet
- Die Konfiguration wird API-basiert verwaltet, sodass Migrationen und Rollbacks zwischen Versionen möglich sind; das Update-Management kann manuell oder mit orchestratorspezifischen Tools erfolgen
- Ein unveränderliches Root-Dateisystem, dm-verity, restriktives SELinux sowie Implementierungen in Rust und teilweise Golang verringern Systemmanipulationen und Pfade zur Ausführung nicht verifizierten Codes
Basis-OS für Container-Cluster
- Bottlerocket ist ein Linux-basiertes Betriebssystem, das für Container-Hosting optimiert ist
- Es ist freie Open-Source-Software und wird öffentlich auf GitHub entwickelt
- Es wird als Basisbetriebssystem auf Maschinen oder Instanzen installiert, auf denen Container laufen
- Es wurde für den Betrieb mit Container-Orchestratoren wie Kubernetes entwickelt und unterstützt die Automatisierung des Container-Lebenszyklus innerhalb eines Clusters
- Es kann in der Cloud und in Rechenzentren ausgeführt werden
- Die Designziele lassen sich in drei Punkten zusammenfassen: Minimal, Safe Updates und Security Focused
Minimaler Aufbau und umgebungsspezifische Varianten
- Da es ausschließlich für Container-Hosting gedacht ist, entfernt es viele Pakete, Werkzeuge, Interpreter und Abhängigkeiten, die in allgemeinen Linux-Distributionen standardmäßig enthalten sind
- Weniger unnötige Software senkt sowohl den Betriebsaufwand als auch den Sicherheitsaufwand
- Unterschiedliche Anforderungen von Orchestratoren, Plattformen und Architekturen werden über Varianten verwaltet, also Builds für jeweils kompatible Kombinationen
- Eine Variante ist eine Zusammenstellung der Elemente, die für den Betrieb in einer bestimmten Umgebung nötig sind
- Wenn die passende Variante gewählt wird, sind keine zusätzlichen Komponenten nötig, um dem Cluster beizutreten
- Bottlerocket selbst hat keine Shell
- Der Zugriff auf das System erfolgt über privilegierte Host-Container mit Shell
- In Host-Containern kann das zugrunde liegende OS untersucht und die Konfiguration des laufenden Systems per API geändert werden
Sichere imagebasierte Updates
- Bottlerocket ist auf Update-Fähigkeit ausgelegt, enthält aber keinen Paketmanager
- Updates werden als Images bereitgestellt, die auf eine bestimmte Partition heruntergeladen werden
- Beim Update drainiert der Orchestrator zunächst den Node und weist Bottlerocket dann an, das Update anzuwenden und neu zu starten
- Bottlerocket wechselt die Partition und bootet atomar in die neue Version
- Die Systemkonfiguration wird per API verwaltet, sodass Bottlerocket Konfigurationsmigrationen zwischen Versionen durchführen kann
- Wenn während des Updates Probleme auftreten, kann mit beibehaltener Konfiguration auf die zuvor funktionierende Version zurückgerollt werden
- Das Update-Management kann manuell erfolgen oder mit orchestratorspezifischen Tools
Sicherheitsorientiertes Design
- Die minimale Konfiguration und die Update-Methodik stützen das sicherheitsorientierte Design von Bottlerocket
- Da Varianten als Images ausgeliefert werden, sind Paketregister oder Paketmanager, über die das System verändert und Sicherheitsprobleme verursacht werden könnten, nicht erforderlich
- Die spezifischen Funktionen von Bottlerocket sind in Rust und teilweise in Golang geschrieben
- Beide Sprachen sind kompilierte Sprachen und bieten eingebaute Schutzmechanismen gegen Probleme der Speichersicherheit
- Da der gesamte Code als vorkompilierte Images ausgeliefert wird, sind weder Shells noch Interpreter nötig, und die Pfade zur Ausführung nicht verifizierten Codes werden reduziert
- Das Root-Dateisystem ist unveränderlich
- dm-verity bietet eine transparente Integritätsprüfung des Root-Dateisystems
- Wenn Änderungen am zugrunde liegenden Block-Device erkannt werden, startet der Kernel neu
- Auf veränderliche Dateisysteme wird eine restriktive SELinux-Richtlinie angewendet, die stets aktiv und erzwungen ist
- Diese Richtlinie hilft dabei, zu verhindern, dass Container selbst dann gefährliche Aktionen ausführen, wenn sie als root laufen
1 Kommentare
Meinungen auf Hacker News
Es wirkt weiterhin stark wie ein AWS-/Amazon-Projekt, und der Weg zu einem unabhängigen Projekt scheint nicht klar zu sein.
Wenn man zum Beispiel OS-Schwachstellen-Scans braucht, kann man ein Amazon-Produkt verwenden; andernfalls ist der Weg unklar. https://bottlerocket.dev/en/faq/#4_2
Wenn man Bottlerocket nur auf AWS betreiben will, ist das in Ordnung, aber wenn es – wie auf der Website beschrieben – ein Produkt werden soll, das „in der Cloud oder im Rechenzentrum läuft“, müssen solche Punkte gelöst werden.
Wenn man wissen will, ob gepatcht wurde, muss man nur prüfen, ob man die neueste Version ausführt; ist sie aktuell, sind alle verfügbaren Patches angewendet.
In regulierten Branchen kann das allerdings ein Problem sein, weil man in Compliance-Checklisten den Punkt „Schwachstellenmanagement“ ausfüllen muss.
Der Hauptgrund, warum Schwachstellenmanagement bei traditionellen OSes nötig ist: Der Konfigurationsraum ist sehr groß, Software-Konfigurationen werden beliebig aus mehreren Quellen und von mehreren Anbietern gemischt, und jede Version bewegt sich unabhängig.
Ein Container-OS ist aber nicht dafür gedacht, so verwendet zu werden.
Zusätzliche Schwachstellen in „latest“ zu finden, ist weniger die Aufgabe des Systembesitzers, rechtzeitig Upstream-Patches einzuspielen, sondern eher die Aufgabe von Sicherheitsforschern.
Das Projekt ist älter als Bottlerocket.
Wenn es einen Weg gibt, per SSM hineinzukommen oder den Admin-Container zu verwenden, um einen Scan auszuführen, könnte man es dann nicht auf dieselbe Weise machen? Das ist eine reine Frage.
Das kann man tun, bevor man das Image auf die Host-Maschine ausrollt.
Anders als die meisten Enterprise-*nix-Distributionen bietet Bottlerocket keinen FIPS-Modus.
Wer ein Compliance-Programm nutzt, das für geschäftliche Host-OSes FIPS-zugelassene Kryptografie verlangt, sollte sich die Zeit sparen.
Deshalb ist Bottlerocket für uns keine Option; das entsprechende Issue ist seit über zwei Jahren aktiv offen, aber das Entwicklungsteam scheint nicht überzeugt zu sein, dass es wichtig ist.
Wir haben über unseren dedizierten AWS-Ansprechpartner auch mit dem Entwicklungsteam gesprochen, aber es wirkte nicht so, als hätten sie vor, das hinzuzufügen.
Der seit über zwei Jahren offene Thread ist hier: https://github.com/bottlerocket-os/bottlerocket/issues/1667
FIPS-Unterstützung ist weiterhin mit großem Abstand die meistgenannte Kundenanfrage.
Für eine neue Distribution ohne frühere FIPS-Angebote ist der Zeitpunkt allerdings ungünstig.
Neue FIPS-140-2-Zertifizierungen werden nicht mehr angenommen, und neue FIPS-140-3-Zertifizierungen müssen durch eine lange Warteschlange, weil die gesamte Branche gerade umstellt.
Wenn das etwas wäre, das das Entwicklungsteam einfach durchdrücken könnte, wäre es schon erledigt.
Falls der Eindruck entstanden ist, es sei nicht wichtig, entschuldige ich mich; es ist tatsächlich wichtig, aber in diesem Fall hilft das dem Zeitplan nicht.
Wenn man sie braucht, geht es nicht anders, aber persönlich sehe ich eine Zertifizierung eher als leicht negatives Signal.
Mit dieser Ansicht bin ich nicht allein; das Microsoft-Windows-Team scheint es ähnlich zu sehen: https://techcommunity.microsoft.com/t5/microsoft-security-ba...
Selbst wenn FIPS an sich nicht böse ist, sollte man im Hinterkopf behalten, dass es sich mit bösen Menschen und in bösen Umfeldern bewegt. https://threadreaderapp.com/thread/1433451378391883782.html
Es sieht sehr interessant aus, aber wie in anderen Kommentaren wirkt der Weg, es selbst auszuführen, unklar.
Die GitHub-Seite ist auch nur auf der Hauptseite verlinkt.
Die VMware-Anleitung habe ich hier gefunden: https://github.com/bottlerocket-os/bottlerocket/blob/develop...
Es ist der Ausrichtung von CoreOS sehr ähnlich. https://fedoraproject.org/coreos/
Weder unter „Get Started“ noch in der FAQ steht, wie man es ausführt.
Ein gutes Projekt, aber es gibt es schon seit 2020: https://aws.amazon.com/about-aws/whats-new/2020/08/announcin...
Ich frage mich, ob es Leute gibt, die das erfolgreich außerhalb von AWS einsetzen
Für Anwendungsfälle wie AMD SEV-SNP wirkt es ziemlich nützlich
Denn um ein bestimmtes Verhalten einer Maschine zu garantieren, braucht man Messwerte für Kernel + initrd + Argumente
Idealerweise würde man das als Container-Hypervisor verwenden und eine Attestierung erzeugen können, die an die Hashes der laufenden Container gebunden ist
Allerdings dürfte es dann keine Container-Escapes geben; wie der aktuelle Stand in diesem Bereich ist, weiß ich nicht genau
Ich würde eher CoreOS verwenden wollen
Haben die irgendetwas als Open Source veröffentlicht, das außerhalb von AWS breit genutzt wird?
Auf der Website steht, dass das OS keine Shell hat
Ich kann mir kaum einen nützlichen Docker-Container vorstellen, der nicht mindestens ein Shell-Skript enthält
Bedeutet keine Shell dann nicht, dass Bottlerocket außer für einige Nischenszenarien weitgehend unbrauchbar ist?
Keine Shell hat die Host-Maschine; wenn man einen Docker-Container mit Shell holt und ihn privilegiert ausführt, kann man auf dem Host eine Shell nutzen
Es ist nicht üblich, das Shell-Binary der Host-Maschine einem auf dem Host laufenden Container bereitzustellen
Stattdessen wird diese Verantwortung an einen Admin-Container delegiert, und die eigentliche Verbindung erfolgt dorthin per SSM/SSH
Wenn man dort eine Root-Shell braucht, kann man das Utility
sheltieverwendenEin Beispiel dafür ist distroless
Shells | Container | Bottlerocket | OS-Kernel