Teams & API-Keys

Alles in PaaSbox gehört einem Team, nicht einer Person: Cluster, Verbindungen, adoptierte Server, API-Keys, Rechnungen. Nach der Registrierung bist du schon in einem – deinem persönlichen Team – und kannst weitere erstellen oder ihnen beitreten. Denk dir ein Team als Organisationsgrenze: Was ein Mitglied erstellt, können alle Mitglieder sehen und damit arbeiten.

Rollen

Teams haben zwei Rollen, bewusst einfach gehalten:

• Administrator – verwaltet das Team selbst: Mitglieder und Einladungen, Abrechnung und Zahlungsmethoden, Team-Einstellungen. Das erste Mitglied eines Teams ist sein Administrator.
• Mitglied – arbeitet mit den Ressourcen des Teams: erstellt und betreibt Cluster, adoptiert Server, stellt kubeconfigs aus.

Es gibt keine Kosten pro Sitzplatz – die Preise gelten pro Cluster, lade also alle ein, die Zugriff brauchen.

Einladungen

Administratoren laden per E-Mail-Adresse ein und wählen dabei die Rolle. Die eingeladene Person nimmt an, indem sie sich mit dieser Adresse anmeldet (oder registriert), und landet direkt im Team. Über die Mitgliedschaft entziehst du auch Zugriff: Nimm jemanden aus dem Team, und der Portal-Zugriff endet sofort – das vollständige Bild steht unter Offboarding weiter unten.

Isolation zwischen Teams

Jedes Team ist plattformseitig ein eigenes, isoliertes Projekt – Cluster verschiedener Teams teilen sich nie einen Namensraum aus Namen, Zugangsdaten oder Abrechnung. Das Team ist auch die Abrechnungsgrenze: ein Stripe-Kunde, eine Währung (festgelegt beim ersten Checkout des Teams), ein Ausgabenlimit, eine Rechnung.

API-Keys

Für Skripte, CI und alles Nicht-Interaktive erstellst du in der Konsole einen API-Key. Keys sehen aus wie pbx_live_…, werden einmal bei der Erstellung angezeigt und lassen sich jederzeit widerrufen. Ein Key gehört dem Mitglied, das ihn erstellt hat, und handelt im Team mit dessen Identität – Aktionen über einen Key sind im Aktivitätsprotokoll also einer Person zuzuordnen.

Verwende ihn als Bearer-Token:

curl -s -H "Authorization: Token $PAASBOX_API_KEY" \
  https://console.paasbox.com/api/v1/teams/<team>/clusters/

Das eine Muster, das du verinnerlichen solltest: Der API-Key ist das langlebige Secret; kubeconfigs sind Wegwerfware. Ein CI-Job sollte den API-Key halten und damit pro Lauf eine frische kubeconfig holen – mit einer TTL, die den Job abdeckt. Speichere niemals eine kubeconfig als langlebiges Secret. Die API-Referenz dokumentiert jeden Endpunkt.

Das Aktivitätsprotokoll

Teams bekommen einen auditierten Aktivitäts-Feed. Der Cluster-Lebenszyklus (erstellt, Provisionierung, bereit, in den Ruhezustand versetzt, aufgeweckt, gelöscht), jede kubeconfig-Ausstellung (wer, wann, mit welcher TTL) und Abrechnungsereignisse (Schwellenwert-Abbuchungen, ein am Ausgabenlimit in den Ruhezustand versetzter Cluster) werden mit Akteur und Quelle festgehalten – ob eine Person im Portal, die Automatisierung der Plattform selbst oder das Abrechnungssystem. Wenn du dich fragst „Wer hat um 2 Uhr nachts cluster-admin ausgestellt?“, ist die Antwort eine Seite entfernt.

Offboarding

Eine Person sauber zu entfernen ist eine Geschichte in drei Schichten, und alle drei gehen schnell:

1. Entferne sie aus dem Team – Portal- und API-Zugriff enden sofort.
2. Widerrufe ihre API-Keys – jede Automatisierung, die sie nutzt, kann sich nicht mehr authentifizieren.
3. Cluster-Zugangsdaten laufen von selbst ab – kubeconfigs leben höchstens 8 Stunden, es gibt also nichts Langlebiges einzusammeln.

Lebt dein Team in einem Identity Provider, sorgt Bring your own IdP dafür, dass auch der Cluster-Zugriff deinem IdP folgt – deaktiviere das Konto dort, und die Cluster-Logins stoppen mit.