Zugriff auf deinen Cluster

PaaSbox gibt dir vollen Cluster-Admin-Zugriff auf deinen Cluster – eine echte kubeconfig, keine zugenagelte Konsole. Das Credential ist bewusst kurzlebig: du holst dir bei Bedarf ein frisches, aus der Konsole oder über die API, und es läuft von allein ab.

So funktionieren Cluster-Credentials

Jede kubeconfig, die PaaSbox ausstellt, ist:

• Cluster-Admin, beschränkt auf einen Cluster. Sie authentifiziert ausschließlich gegen den API-Server deines Clusters – nie gegen die Plattform.
• Kurzlebig. Du wählst eine Gültigkeit von bis zu 8 Stunden (Standard: 1 Stunde). Danach schlagen Anfragen mit einem Authentifizierungsfehler fehl, und du stellst einfach eine neue aus.
• Nie gespeichert. PaaSbox erzeugt das Credential auf Anfrage und übergibt es dir; auf unserer Seite gibt es keine Kopie, die leaken könnte.
• Auditiert. Jede Ausstellung wird als Event am Cluster festgehalten – wer sie angefordert hat, wann und für wie lange.

Warum kurzlebig? Ein Zertifikats-Credential lässt sich vor Ablauf nicht zurückziehen. Eine Lebensdauer von Stunden heißt: ein kompromittierter Laptop, eine in den Chat gepastete kubeconfig oder ein vergessenes CI-Artefakt altert von selbst heraus – und das Offboarding eines Teammitglieds passiert im Portal, nicht durch Rotieren deines Clusters.

Eine kubeconfig aus der Konsole holen

Öffne in console.paasbox.com deinen Cluster und wähle Download kubeconfig (kubeconfig herunterladen). Zeig kubectl auf die Datei und prüfe die Verbindung:

export KUBECONFIG=~/Downloads/paasbox-kubeconfig.yaml
kubectl get nodes

Eine kubeconfig über die API holen

Für Skripte und CI forderst du eine mit einem Team-API-Key an (Authorization: Token pbx_live_…):

curl -s -X POST \
  -H "Authorization: Token $PAASBOX_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"ttlSeconds": 3600}' \
  https://console.paasbox.com/api/v1/teams/<team>/clusters/<cluster>/kubeconfig/ \
  | jq -r .kubeconfig > kubeconfig.yaml

export KUBECONFIG=$PWD/kubeconfig.yaml
kubectl get nodes

Die Antwort enthält außerdem expiresAt, sodass Automatisierung rechtzeitig erneuern kann. Den vollständigen Vertrag findest du in der API-Referenz.

In CI: pro Lauf holen. Stell am Anfang des Jobs eine kubeconfig mit einer TTL aus, die den Job abdeckt, und lege nie eine als langlebiges Secret oder Artefakt ab – der API-Key ist das langlebige Secret; kubeconfigs sind Wegwerfware.

Wenn sie abläuft

Abgelaufene Credentials schlagen mit einem Unauthorized-Fehler vom API-Server fehl. Mit deinem Cluster ist alles in Ordnung – stell eine frische kubeconfig aus und mach weiter.

Im Team arbeiten

Jede Person in deinem Team, die im Portal Zugriff auf den Cluster hat, kann eine kubeconfig ausstellen, und jede Ausstellung wird auditiert. Um jemandem den Cluster-Zugriff zu entziehen, entfernst du die Person aus dem Team (oder ihren API-Key) – das bestehende Credential läuft innerhalb von Stunden ab.

Wenn dein Team in einem Identity Provider lebt (Entra ID, Okta, Keycloak, Google, …), kannst du noch einen Schritt weitergehen und dich mit deinem eigenen IdP am Cluster anmelden – benannte Benutzer, gruppenbasiertes RBAC und sofortiges Offboarding. Siehe Bring your own Identity Provider.

Was die kubeconfig nicht enthält

• Kein Plattform-Zugriff. Das Credential erreicht den API-Server deines Clusters und sonst nichts – nicht die Kontrollinfrastruktur von PaaSbox, keine anderen Cluster.
• Keine Plattform-Observability-Endpunkte. PaaSbox überwacht deine Control Plane als Teil des Betriebs; Dashboards für deine Workloads betreibst du selbst im Cluster (Prometheus, Grafana, VictoriaMetrics, …) – den Admin-Zugriff, um zu installieren, was du willst, hast du ja. Siehe Was du mitbringst & was wir betreiben.