Wer was darf

Zwei Wege hinein, ein Benutzer dahinter

Ein Mensch meldet sich mit Namen und Kennwort an und arbeitet mit einer Sitzung weiter. Ein Skript benutzt einen API-Schlüssel, der zu einem Benutzer gehört und nicht abläuft — das will eine Build-Strecke, und ein Mensch braucht es nicht.

Beim allerersten Start entsteht ein root-Schlüssel und wird in eine Datei geschrieben, die nur root lesen kann. Er ist der Weg zurück, falls die Anmeldung per Kennwort einmal nicht funktioniert, und es gibt ihn genau deshalb, damit für diesen Fall niemand eine zweite Tür offen lassen muss.

Rechte je Aktion, nicht je Person

Rechte heißen nach Bereich und Aktion — ansehen, anlegen, ändern, ein- und ausschalten, Konsole, Snapshot, exportieren, löschen — und hängen direkt am Benutzer. Es gibt einen Katalog dafür, und er dient drei Dingen zugleich: der Prüfung im Programm, dem Rechte-Editor der Oberfläche und den fertigen Vorlagen. Ein Recht, das in diesem Katalog fehlt, gibt es nirgends.

Manche Rechte sind bewusst abgetrennt, statt beim Nachbarn mitzulaufen. Exportieren gehört nicht zum Klonen, denn wer exportieren und herunterladen darf, hält die ganze Platte eines Gastes in der Hand. Eine Aktualisierung einspielen gehört nicht zum Ansehen des Hosts, denn sie ersetzt den Programmcode, der als root läuft. Den Speicher eines angehaltenen Gastes durchsuchen gehört nicht zum Bedienen der Notbremse, denn dieses Abbild enthält alles, was im Gast war, als er stehen blieb.

Fertige Vorlagen — nur ansehen, VM-Betrieb, VM-Verwaltung, Container-Verwaltung — setzen die Häkchen, und jedes Häkchen lässt sich danach einzeln ändern.

Verschlüsselt ab dem ersten Start

Oberfläche und API laufen von Haus aus über TLS; beim ersten Start entsteht ein Zertifikat. Wo eine Domain auf den Host zeigt, lässt sich ein öffentlich vertrauenswürdiges Zertifikat anfordern und übernehmen.

Der Server liest seine Zertifikatsdateien beim Start, eine Änderung braucht also einen Neustart. Ob einer aussteht, wird aus dem Vergleich von Datei und laufendem Prozess ermittelt — daran muss sich niemand erinnern.

Eine Aktualisierung, die unterwegs nicht getauscht werden kann

Eine Aktualisierung ersetzt Programmcode, der als root läuft. Wer bestimmen kann, was ankommt, besitzt jeden Host, auf dem es ankommt, und das gilt auf beiden Wegen: online könnte jemand die Verbindung übernehmen, offline reist die Datei per USB-Stick oder Post, und man sieht ihr nicht an, ob sie unterwegs verändert wurde.

Jedes Paket trägt deshalb eine Signatur, und ohne eine gültige wird nichts ausgepackt. Der öffentliche Schlüssel steckt im Programm; der private gehört ausschließlich auf die Maschine, auf der Pakete gebaut werden. Signiert ist die Nutzlast selbst und nicht ihre Beschreibung — sonst ließe sich eine echte Signatur mit fremdem Inhalt kombinieren.

Dieselbe Bauart trägt die Lizenzierung: In Phillux steckt nur der öffentliche Schlüssel, aus einer Installation heraus kann also niemand eine Lizenz ausstellen — auch nicht, wer Quelltext und Datenbank hat.