Amutable: Wer falsch konfiguriert ist, fliegt aus dem Linux-Cluster

1. Amutable Foundations: Linux, das seinen Zustand beweist
   • Signierte Konfiguration
   • Identität aus Messwerten
   • Pakete aus Fedora, Betrieb durch Amutable

Was hat ein bestimmter Knoten im Cluster gebootet? Die Antwort ziehen Admins heute meist noch aus Inventarlisten, Config-Management und Scannern. Das Berliner Start-up Amutable, das systemd-Erfinder Lennart Poettering mitgegründet hat, will das über Kryptografie belegen. Sein Amutable Foundations Linux verwaltet den beabsichtigten Zustand jedes Rechners in der Versionskontrolle. Seit Ende Oktober ist die Anmeldung zur Private Preview geöffnet und eine kleine Gruppe von Design-Partnern soll in den nächsten Wochen Zugang bekommen.

Signierte Konfiguration

Foundations ist schreibgeschützt und imagebasiert. dm-verity schützt die System-Volumes. Die Maschine startet nur signierte Unified Kernel Images und misst per Measured Boot, was sie lädt. Einen Paketmanager, SSH oder eine interaktive Shell gibt es nicht. Admins arbeiten über eine strukturierte Schnittstelle. Jede Änderung, auch an der Konfiguration, kommt als neues signiertes Image auf die betroffenen Maschinen.

Das ist laut Amutable nämlich der größte Unterschied zu bisherigen Immutable-Distributionen: Die Konfiguration wird Teil der Vertrauenskette. Measured Boot erfasst zwar bestenfalls Firmware, Bootloader und das Unified Kernel Image und deckt das System-Volume über den dm-verity-Root-Hash in der gemessenen Kernel-Kommandozeile indirekt mit ab. Aber die Konfiguration liegt meist in Form loser Dateien auf einer beschreibbaren Partition, geschrieben etwa von Ansible oder cloud-init, und fließt in der Regel in keinen Messwert ein.

Zwei Server mit identischen PCR-Werten können also völlig unterschiedlich konfiguriert sein, zum Beispiel mit einer anderen sshd_config oder einem zusätzlichen CA-Zertifikat. Foundations kompiliert die Konfiguration deshalb in eigene signierte, integritätsgeschützte Images. Die Maschine prüft und misst sie beim Einspielen, so landet der Messwert im signierten Bericht an die Control Plane.

Identität aus Messwerten

So einen Bericht schickt jede Maschine beim Start und danach regelmäßig. Er enthält die Messwerte von Boot-Kette und Konfiguration und ist vom TPM signiert. Die Messwerte lassen sich bis zum nächsten Neustart nicht zurücksetzen. Deshalb kann eine manipulierte Maschine ihren Bericht nicht schönen. Den Bericht erzeugt systemd-report, an dem Amutable mitentwickelt hat. Signieren kann das noch experimentelle Werkzeug seit systemd 262.

Die Control Plane vergleicht jeden Bericht mit dem Soll-Zustand. Davon hängt ab, was die Maschine darf. Mit veralteter Konfiguration bekommt sie keine Datenbank-Zugangsdaten. Weichen ihre Messwerte nach einem Neustart ab, darf sie keinem Cluster mehr beitreten. Ein Rollout läuft nur weiter, solange die aktualisierten Maschinen einen korrekten Zustand melden. Host-Keys, Zertifikate oder API-Tokens kann laut Amutable auch ein manipulierter Rechner vorzeigen, einen korrekten Messwert dagegen nicht. Für Audits sollen signierte Messwerte, SBOMs und Herkunftsnachweise als Belege dienen. Maschinen ohne passende Hardware können auf einen Software-Schlüssel ausweichen. Dann fehlt allerdings der Hardware-Anker.

Pakete aus Fedora, Betrieb durch Amutable

Eine Distribution von Grund auf baut Amutable nicht. Das Buck2-basierte Build-System tine übernimmt Pakete aus festgepinnten Quellen bestehender Distributionen wie Fedora oder CentOS Stream. Laut Amutable entstehen daraus reproduzierbare Images samt SBOM. Das Werkzeug Quarry verteilt sie von statischem Hosting aus. The Update Framework (TUF) schützt dabei die Update-Metadaten vor Manipulation und Rollback. tine (MPL-2.0) und Quarry (Apache-2.0) sind Open Source. Foundations ergänzt sie um einen Dienst: Die Maschinen betreibt der Kunde selbst. Amutable baut und pflegt die Images, betreibt Update-Repositories und Control Plane und liefert Sicherheitsupdates.

Für die Teile, die Amutable selbst betreibt, nennt die Firma bisher keine Lizenz. Wie viel von Foundations über tine und Quarry hinaus Open Source wird, ist ebenfalls offen. Und Attestierung hat Grenzen: Sie belegt, welcher Zustand gemessen wurde, nicht dass die signierte Software frei von Lücken ist. Wer nach dem Start über eine Schwachstelle in einen laufenden Prozess eindringt, ändert keinen Messwert.

Gegründet haben Amutable Anfang 2026 Chris Kühl, Christian Brauner und Lennart Poettering. Kühl ist CEO und gründete Kinvolk, die Firma hinter Flatcar Container Linux. Brauner ist CTO und betreut das VFS-Subsystem des Linux-Kernels, Poettering ist Chief Engineer. Als Nächstes will Amutable Foundations für Kubernetes-Cluster bringen. Auf der KubeCon North America im November in Salt Lake City ist das Team an Stand 347.

(kki)