Einem Agenten Zugriff geben

Diese Seite gibt einem Coding-Agenten oder einem Skript einen eigenen Schlüssel für die Cluster deines Teams: mit nur den Scopes, die er braucht, verbunden über MCP oder die REST-API, und mit jedem Aufruf in einem Log, das du lesen kannst. Ein Schlüssel gehört zu einem Team und handelt mit den Rechten des Admins, der ihn angelegt hat.

In Arbeit: noch nicht buchbar

In Arbeit Die API-Schlüssel, die MCP-Tools und die REST-API sind geschrieben und durch die Tests des Portals abgedeckt, aber sie sind noch nicht gegen einen echten Cluster gelaufen, und das Portal ist nicht live. Namen können sich bis dahin noch ändern. Die Oberfläche des Portals ist englisch, darum stehen ihre Beschriftungen hier auf Englisch. Nachgehen kannst du die Schritte noch nicht. Sag mir, wenn es buchbar ist.

Was du brauchst

• Die Rolle Team-Admin. Nur Team-Admins können API keys & agents öffnen und Schlüssel anlegen.
• Einen MCP-Client, etwa Claude Code, oder curl für die REST-API.
• Für Kubeconfigs: Python 3.10 oder neuer mit dem Paket cryptography, dort, wo der Agent läuft.

Die Scopes wählen

Hak nur an, was der Agent braucht. Ein Scope gibt einem Schlüssel nie mehr, als die Person, die ihn angelegt hat, im Team darf.

Scope	Erlaubt	Tools
k3s:read	Cluster, ihre Gesundheit, Nodes, Snapshots, Operationen, Upgrades und Add-ons sehen.	list_clusters, get_cluster, list_snapshots, list_operations, get_operation, list_addons, list_projects, list_server_types
k3s:write	Snapshots machen, Upgrades einplanen, Add-ons an- und ausschalten oder einstellen.	create_snapshot, schedule_upgrade, set_addon
k3s:access	Temporäre Kubeconfigs anfordern, versiegelt für den eigenen Schlüssel des Agenten, und sie widerrufen.	request_kubeconfig, get_kubeconfig_result, revoke_access
k3s:destructive	Cluster anlegen, löschen, abkoppeln und wiederherstellen, jeweils nur mit dem Namen des Clusters als getippter Bestätigung.	create_cluster, delete_cluster, restore_snapshot, detach_cluster

Ein Agent, der nur zusieht, braucht k3s:read. Ein Agent, der für einen Test einen Wegwerf-Cluster baut, darauf deployt und ihn wieder löscht, braucht k3s:read, k3s:access und k3s:destructive, dazu k3s:write, wenn er ein Add-on anschaltet, etwa die PaaSbox Platform. Den ersten Cluster eines Teams legst du immer im Portal an, weil er das Abonnement startet; ebenso den ersten Cluster, nachdem das Abonnement des Teams geendet hat.

Ein Schlüssel gehört zu einem Team und reicht an jeden seiner Cluster: Kein Scope lässt sich auf einen Cluster begrenzen. Ein Schlüssel mit k3s:destructive, der einen Wegwerf-Cluster löschen darf, darf auch die Produktion im selben Team löschen. Halte die Produktion in einem Team, zu dem der Schlüssel nicht gehört. Der getippte Name, den ein zerstörerischer Aufruf braucht, verhindert eine Verwechslung, keine Entscheidung: Das Portal prüft den Namen, nicht, ob du zugestimmt hast. Ob dein Agent dich vorher fragt, liegt an seinem Client.

Den Schlüssel anlegen

1. Öffne im Menü des Portals API keys & agents.

2. Gib unter Create a key einen Name ein, der sagt, wer ihn benutzt, zum Beispiel claude-code. Hak die Scopes an. Wähle, wann er abläuft (Expires): in 30 days, in 90 days (voreingestellt), in a year oder never.

3. Wähle Create key. Kopier den Schlüssel jetzt: Er wird einmal gezeigt und nur als Hash gespeichert. Wenn du ihn verlierst, widerruf ihn und leg einen neuen an. Ein Team hat höchstens 25 aktive Schlüssel.

Den Agenten verbinden

Die Seite zeigt die Adressen MCP endpoint und REST API deines Teams und diese Snippets mit ihnen ausgefüllt.

Für Claude Code:

claude mcp add --transport http paasbox https://<portal>/mcp/ \
  --header "Authorization: Bearer $PAASBOX_API_KEY"

Für andere MCP-Clients:

{
  "mcpServers": {
    "paasbox": {
      "type": "http",
      "url": "https://<portal>/mcp/",
      "headers": {"Authorization": "Bearer ${PAASBOX_API_KEY}"}
    }
  }
}

Für die REST-API:

curl -H "Authorization: Bearer $PAASBOX_API_KEY" https://<portal>/api/v1/teams/<team>/k3s/clusters/

Bitte den Agenten, deine Cluster aufzulisten. Er sieht nur die Tools, die die Scopes seines Schlüssels erlauben.

Eine Kubeconfig für den Agenten holen

Eine Kubeconfig für einen Agenten wird für ein Schlüsselpaar versiegelt, das der Agent erzeugt; das Portal reicht sie weiter und kann sie nicht lesen. Die Seite bietet den Helfer paasbox_kubeconfig.py an, unter /mcp/paasbox_kubeconfig.py im Portal. Mit der REST-API erledigt er alles in einem Befehl:

export PAASBOX_PORTAL=https://<portal> PAASBOX_API_KEY=<a key with k3s:access>
python3 paasbox_kubeconfig.py fetch --team <team> --cluster upcheck-prod --role admin > kubeconfig

Über MCP führt der Agent keygen aus, gibt den öffentlichen Schlüssel an request_kubeconfig, holt das Ergebnis mit get_kubeconfig_result und führt decrypt aus (MCP-Tools). Die Kubeconfig gilt 10 Minuten bis 24 Stunden, voreingestellt eine Stunde.

Nachlesen, was er getan hat

Recent activity auf derselben Seite listet die letzten 20 Aufrufe; All activity listet jeden Aufruf, 50 pro Seite, mit einem Filter Key. Jede Zeile zeigt When, Key (und die Person), Via (MCP oder REST), Call (das Tool oder die REST-Operation), Cluster und Outcome: ok oder den Fehlercode einer Ablehnung oder eines Fehlers, mit dem Detail beim Darüberfahren.

Jeder MCP-Tool-Aufruf wird festgehalten, und jeder REST-Aufruf, der etwas ändert oder eine Kubeconfig herausgibt. Die Argumente werden ohne Geheimnisse gespeichert. Was der Agent mit einer Kubeconfig im Cluster tut, geht direkt an die Kubernetes-API und steht nicht in diesem Log.

Einen Schlüssel widerrufen

Wähle Revoke neben dem Schlüssel. Der Agent wird ab seinem nächsten Aufruf abgewiesen. Ein Schlüssel hört auch auf zu funktionieren, wenn er abläuft und wenn die Person, die ihn angelegt hat, das Team verlässt.

Wie es weitergeht

Leitplanken für AgentenWas Scopes, Bestätigungen, versiegelte Kubeconfigs und das Audit-Log verhindern, und was nicht.

3 · Einen Agenten im eigenen Cluster testen lassenDer Lernschritt, der diesen Schlüssel einsetzt.