Zugangsdaten rotieren

Ein Cluster von PaaSbox Clusters arbeitet mit mehreren Zugangsdaten: dem Hetzner-Token, mit dem das Portal Server anlegt, dem Hetzner-Token, das der Cluster selbst nutzt, den Schlüsseln deines Snapshot-Buckets, den eigenen Schlüsseln von pbx-agent und den DNS-Tokens einiger Add-ons. Diese Seite ersetzt jedes davon, damit ein geleaktes oder nicht mehr gewolltes Zugangsdatum aufhört zu wirken, ohne dass deine Apps anhalten.

In Arbeit: noch nicht buchbar

Gebaut im Labor: Am 2026-10-10 hat pbx-agent auf einem echten Server seine eigenen Schlüssel in 17 Sekunden gewechselt und sich weiter gemeldet, und ein Tausch der Bucket-Schlüssel dauerte 8 Sekunden; ein falsches Schlüsselpaar wurde abgelehnt, und die geltenden Schlüssel blieben. Das Token des Projekts und das Token im Cluster zu ersetzen, ist In Arbeit: gebaut, auf einem echten Cluster noch nicht gelaufen. Die Oberfläche des Portals ist englisch, darum stehen ihre Beschriftungen hier auf Englisch. Sag mir, wenn es buchbar ist.

Zugangsdatum	Wer es nutzt	Wo du es ersetzt	Stand
Das Hetzner-Token des Projekts	das Portal, um Ressourcen anzulegen und zu löschen	PaaSbox Clusters → Hetzner projects	In Arbeit
Das Hetzner-Token im Cluster	der Cloud Controller und der Volume-Treiber	Settings → Credentials des Clusters	In Arbeit
Die Schlüssel des Buckets	k3s, bei jedem Snapshot	Backups → Bucket keys des Clusters	Gebaut
Die Schlüssel von pbx-agent	pbx-agent, um seine Aufrufe zu signieren und zu öffnen, was das Portal versiegelt	nirgends: Sie wechseln von selbst	Gebaut
DNS-Tokens von Add-ons	cert-manager, external-dns, die PaaSbox Platform	Add-ons des Clusters	In Arbeit
Das k3s-Server-Token	k3s	keine Rotation im Portal	—

Jeden Austausch machen Team-Admins.

Das Hetzner-Token des Projekts

Mit diesem Token legt das Portal die Ressourcen deiner Cluster an, ändert und löscht sie. Im Cluster nutzt es nichts, außer der Cluster wurde mit A copy of the project’s token angelegt (nächster Abschnitt).

1. Leg in der Hetzner-Konsole im selben Projekt ein neues API-Token mit der Berechtigung Read & Write an.

2. Läuft ein Cluster dieses Projekts mit einer Kopie des Projekt-Tokens, ersetz zuerst diese: Unter Settings → Credentials steht dann a copy of the project’s token. Die Kopie ändert sich nicht, wenn du das Token des Projekts ersetzt, und sie hörte auf zu wirken, sobald du das alte widerrufst.

3. Öffne im Portal PaaSbox Clusters → Hetzner projects. Füg unter dem Projekt das neue Token in New token for this project ein und wähle Replace.

4. Widerruf in der Hetzner-Konsole das alte Token.

Das Portal prüft, dass das neue Token funktioniert und die Server jedes Clusters dieses Projekts sieht. Hetzner-Tokens tragen keine Projekt-ID, so stellt das Portal sicher, dass das Token zum selben Projekt gehört; ein Token eines anderen Projekts wird mit dem Namen des Clusters abgelehnt. Hat noch kein Cluster des Projekts einen Server, kann das Portal nichts vergleichen, dann prüf selbst, dass das Token aus dem richtigen Projekt stammt. Check the token prüft das Token in Gebrauch jederzeit, und das Projekt zeigt, wann es zuletzt geprüft wurde.

Das Hetzner-Token im Cluster

Der Cloud Controller und der Volume-Treiber des Clusters rufen mit diesem Token die Hetzner-API auf. Es liegt im Secret kube-system/hcloud.

1. Leg in der Hetzner-Konsole im Projekt des Clusters ein neues API-Token mit der Berechtigung Read & Write an.

2. Füg es auf Settings des Clusters unter Credentials in New Hetzner token ein und wähle Replace the token inside the cluster.

3. Warte auf den nächsten Abgleich von pbx-agent, etwa 30 Sekunden. Er schreibt das neue Token in das Secret kube-system/hcloud und startet den Cloud Controller und den Volume-Treiber neu, so wie kubectl rollout restart es tut. Deine eigenen Workloads werden nicht neu gestartet.

4. Widerruf in der Hetzner-Konsole das alte Token.

Das Portal lehnt ein Token ab, das nicht funktioniert oder die Server des Clusters nicht sieht. Credentials sagt danach a separate token, mit dem Datum, an dem du es gespeichert hast.

Die Schlüssel des Buckets

k3s liest Adresse und Schlüssel des Buckets bei jedem Snapshot aus dem Secret kube-system/pbx-etcd-s3, ein neues Paar braucht also keinen Neustart. Wenn das Portal die Schlüssel hält:

1. Leg bei deinem S3-Anbieter ein neues Schlüsselpaar für den Bucket an. Behalte das alte vorerst.

2. Trag auf Backups des Clusters unter Bucket keys den Access key und den Secret key ein und wähle Save new keys.

3. Die Seite sagt, dass sie darauf wartet, dass pbx-agent den Bucket mit dem neuen Access Key auflistet. pbx-agent probiert das neue Paar zuerst am Bucket aus. Klappt das, ersetzt es das Paar in Gebrauch, und pbx-agent schreibt es in das Secret; In use zeigt dann die ersten Zeichen des neuen Access Keys. Klappt es nicht, bleiben die geltenden Schlüssel, und die fehlgeschlagene Prüfung steht mit ihrer Meldung in der Liste.

4. Widerruf bei deinem S3-Anbieter das alte Paar.

Im Labor dauerte die Prüfung 8 Sekunden, und der nächste Snapshot ging mit dem neuen Paar in den Bucket.

In Arbeit Hältst du die Schlüssel des Buckets selbst, nimmt das Portal keine: Du schreibst das neue Paar selbst in das Secret kube-system/pbx-etcd-s3 (die Schlüssel etcd-s3-access-key und etcd-s3-secret-key), und pbx-agent ändert es nie. Selbst gehaltene Schlüssel sind im Labor noch nicht gelaufen. Backups einrichten erklärt die Wahl zwischen beiden.

Die Schlüssel von pbx-agent

pbx-agent signiert jeden Aufruf an das Portal mit einem eigenen Schlüssel und öffnet mit einem zweiten, was das Portal für ihn versiegelt. Das Portal lässt ihn beide alle 90 Tage von selbst ersetzen: pbx-agent erzeugt neue Schlüssel, meldet sie beim Portal an und bestätigt sie, und der erste Aufruf, der mit dem neuen Schlüssel signiert ist, setzt den alten außer Kraft. Du musst nichts tun; die Operation erscheint unter Operations.

DNS-Tokens von Add-ons

In Arbeit cert-manager mit DNS-01, external-dns und die PaaSbox Platform mit Wildcard-Zertifikaten nutzen ein Token einer DNS-API, das du als Option auf Add-ons des Clusters einträgst. Das Feld zeigt das gespeicherte Token nie. Trag das neue Token ein und speichere; ein leeres Feld behält das gespeicherte. pbx-agent schreibt es in das Secret des Add-ons, kube-system/pbx-addon-<name>. Widerruf das alte Token dann dort, wo du es angelegt hast. Diese Wege der Add-ons sind im Labor noch nicht gelaufen. Add-ons auswählen.

Das k3s-Server-Token

Das Portal kann das k3s-Server-Token nicht rotieren. Rotier es nicht von Hand, solange das Portal den Cluster verwaltet: Das Portal findet das Token, das ein Snapshot braucht, über den Hash des Tokens im Snapshot, und für Snapshots nach einer Rotation von Hand fände es keines, könnte sie also nicht wiederherstellen. Nachdem du abgekoppelt hast, rotierst du das Token selbst; Ohne PaaSbox weiterbetreiben sagt, wie.

SicherheitsmodellWas das Portal verwahrt, und was eine geleakte Datenbank oder ein kompromittiertes Portal damit tun könnten.

Backups einrichtenDer Bucket, wer seine Schlüssel hält, der Zeitplan und wie viele bleiben.