Eine Kubeconfig holen

Das Portal gibt nur befristete Kubeconfigs heraus, eine pro Anfrage, mit der Rolle und der Laufzeit, die du wählst. pbx-agent erzeugt jede auf dem Node und verschlüsselt sie für deinen Browser; das Portal reicht sie weiter, ohne sie lesen zu können, und speichert keine.

In Arbeit: noch nicht buchbar

Gebaut im Labor: Am 2026-10-10 dauerte eine view-Kubeconfig auf einem echten Server 10,7 Sekunden von der Anfrage bis zur entschlüsselten Datei und eine admin-Kubeconfig 21 Sekunden; nach einem Widerruf wurde dasselbe Token binnen 11 Sekunden abgewiesen. Die Oberfläche des Portals ist englisch, darum stehen ihre Beschriftungen hier auf Englisch. Sag mir, wenn es buchbar ist.

Was du brauchst

• Einen Cluster, der bereit ist oder gerade ein Upgrade oder eine Wiederherstellung durchläuft. Die Kubeconfig entsteht auf dem Node, also muss pbx-agent sich melden.
• Einen Browser mit JavaScript. Das Schlüsselpaar für die Anfrage entsteht im Browser-Tab.
• Für admin: Du bist Team-Admin, oder ein Team-Admin hat Mitgliedern erlaubt, danach zu fragen (unten).

Eine holen

1. Öffne auf der Seite des Clusters Access.
2. Wähle eine Rolle (Role): admin (cluster-admin) oder view (nur lesend). Die Seite steht zu Beginn auf view. Eine view-Kubeconfig nutzt die Kubernetes-eigene Rolle view, die keine Nodes auflisten kann; nimm admin für alles, was kubectl get nodes braucht.
3. Wähle, wie lange sie gilt (Valid for): 10 Minuten, 30 Minuten, 1, 2, 4, 8, 12 oder 24 Stunden. Voreingestellt ist 1 Stunde.
4. Wähle Get kubeconfig. Die Anfrage geht beim nächsten Abgleich an pbx-agent, etwa alle 30 Sekunden.
5. Sobald Download kubeconfig erscheint, speichere die Datei. Sie heißt nach dem DNS-Label des Clusters und der Rolle, etwa upcheck-prod-admin.kubeconfig.

export KUBECONFIG=~/Downloads/upcheck-prod-admin.kubeconfig
kubectl get nodes

Die Kubeconfig zeigt auf den API-Namen des Clusters, Port 6443. Deine Adresse muss in den Bereichen liegen, die die Firewall des Clusters hereinlässt; Festlegen, wer die API erreicht zeigt, wie du sie hinzufügst.

Was darunter passiert

• Dein Browser erzeugt ein Schlüsselpaar für genau diese Anfrage. Die private Hälfte verlässt den Browser-Tab nie.
• pbx-agent legt den ServiceAccount pbx-u-<user>-<role> im Namespace pbx-access an, gebunden an cluster-admin oder view, und bittet Kubernetes um ein Token mit der Laufzeit, die du gewählt hast.
• Er baut die Kubeconfig und verschlüsselt sie für den Schlüssel deines Browsers (ECDH P-256, HKDF-SHA256, AES-256-GCM).
• Das Portal reicht die verschlüsselte Datei einmal an deinen Browser weiter und löscht sie nach der Übergabe oder nach 5 Minuten. Ein zweiter Abruf findet nichts. Dein Browser entschlüsselt die Datei und bietet sie zum Download an; die entschlüsselte Datei wird nirgendwohin geschickt.

Die Kubeconfig enthält ein ServiceAccount-Token, kein Client-Zertifikat. Ein Zertifikat kann Kubernetes nicht widerrufen, ein Token dagegen hört in dem Moment auf zu wirken, in dem sein ServiceAccount gelöscht wird.

Solange die Kubernetes-API nicht erreichbar ist, beim Neustart eines Upgrades oder bei einer Wiederherstellung, nimmt pbx-agent nur Wiederherstellungen und Diagnosen an. Eine Kubeconfig-Anfrage wartet dann im Portal; ist die API nach 5 Minuten nicht zurück, verfällt die Anfrage, und du fragst neu.

Wer welche Rolle anfragen darf

• Team-Admins dürfen admin und view anfragen.
• Andere Team-Mitglieder bekommen view. Ein Team-Admin kann ihnen unter Access → Who may ask for admin access auch admin erlauben; das gilt für jeden Cluster des Teams. Dein Team dazuholen hat die übrigen Rollen.

In Arbeit Jede Anfrage nach einer Kubeconfig geht per Mail an die Admins des Teams, mit dem Namen dessen, der gefragt hat; das Labor hat keine Mail verschickt. Issued kubeconfigs auf der Seite Access listet, wer für welche Rolle wann gefragt hat, wann sie ausgestellt wurde, bis wann sie gilt und ob sie widerrufen wurde. Im Cluster erscheint jede Aktion damit unter dem Namen des ServiceAccounts dieser Person.

Widerrufen

• Revoke mine löscht deine ServiceAccounts im Cluster. Jede Kubeconfig, die dir ausgestellt wurde, hört sofort auf zu wirken.
• Ein Team-Admin kann in der Liste den Zugang einer Person widerrufen (Revoke) oder Revoke everyone’s wählen.
• In Arbeit Wer aus dem Team entfernt wird, verliert seinen Zugang auf jedem Cluster des Teams (Dein Team dazuholen).

Ein Widerruf ist eine Operation wie die anderen: pbx-agent löscht die ServiceAccounts beim nächsten Abgleich, und die Seite listet ihn unter Revocations.

Die Admin-Datei auf dem Server

k3s schreibt eine dauerhafte Admin-Kubeconfig auf den Server: /etc/rancher/k3s/k3s.yaml. Sie gehört dir, für Notfälle, etwa wenn das Portal für eine API keine Kubeconfigs ausstellen kann, oder für einen Cluster, den du ohne PaaSbox betreibst. Das Portal liest, kopiert und speichert sie nie. Sie zeigt auf https://127.0.0.1:6443; um sie von deinem Rechner aus zu nutzen, ändere die Zeile server: auf den API-Namen des Clusters. Um an die Datei zu kommen, brauchst du root auf dem Server: Root auf dem Server bekommen.

Diese Datei verfällt nicht. Gerät sie in falsche Hände, macht nur ein Austausch der Zertifizierungsstelle des Clusters sie wertlos, was k3s mit k3s certificate rotate-ca unterstützt. Lass sie auf dem Server.

Für einen Agenten

In Arbeit Ein Agent fragt über die REST-API oder die MCP-Tools nach einer Kubeconfig, mit einem API-Schlüssel, der den Scope k3s:access hat. Die Kubeconfig ist für ein Schlüsselpaar versiegelt, das dein Agent erzeugt hat, genauso wie für deinen Browser. Einem Agenten Zugriff geben.

Festlegen, wer die API erreichtPort 6443 auf die Adressen beschränken, von denen aus du arbeitest.

Root auf dem Server bekommenEinen SSH-Schlüssel über den Cluster hinzufügen, oder das Rescue-System von Hetzner nutzen.