Teams & API keys

Everything in PaaSbox belongs to a team, not to a person: clusters, connections, adopted servers, API keys, invoices. Sign up and you’re already in one — your personal team — and you can create or join others. Think of a team as the organization boundary: what one member creates, every member can see and work with.

Roles

Teams have two roles, deliberately simple:

• Administrator — manages the team itself: members and invitations, billing and payment methods, team settings. The first member of a team is its administrator.
• Member — works with the team’s resources: creates and operates clusters, adopts servers, issues kubeconfigs.

There are no per-seat charges — pricing is per cluster, so invite everyone who needs access.

Invitations

Administrators invite by email address, choosing the role at invite time. The invitee accepts by signing in (or signing up) with that address and lands directly in the team. Membership is also how you remove access: take someone out of the team and their portal access ends immediately — see offboarding below for the full picture.

Isolation between teams

Each team maps to its own isolated project on the platform side — clusters from different teams never share a namespace of names, credentials, or billing. The team is also the billing boundary: one Stripe customer, one currency (fixed at the team’s first checkout), one spend cap, one invoice.

API keys

For scripts, CI, and anything non-interactive, create an API key in the console. Keys look like pbx_live_…, are shown once at creation, and can be revoked at any time. A key belongs to the member who created it and acts with that identity inside the team — so actions taken with a key are attributable to a person in the activity log.

Use it as a bearer token:

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

The one pattern to internalize: the API key is the durable secret; kubeconfigs are disposable. A CI job should hold the API key and use it to fetch a fresh kubeconfig per run with a TTL that covers the job — never store a kubeconfig as a long-lived secret. The API reference documents every endpoint.

The activity log

Teams get an audited activity feed. Cluster lifecycle (created, provisioning, ready, hibernated, resumed, deleted), every kubeconfig issuance (who, when, what TTL), and billing events (threshold charges, a cluster hibernated at the spend cap) are recorded with their actor and source — whether a person in the portal, the platform’s own automation, or the billing system. When you’re wondering “who issued cluster-admin at 2 a.m.”, the answer is one page away.

Offboarding

Removing a person cleanly is a three-layer story, and all three are quick:

1. Remove them from the team — portal and API access end immediately.
2. Revoke their API keys — any automation using them stops authenticating.
3. Cluster credentials age out on their own — kubeconfigs live at most 8 hours, so there’s nothing long-lived to hunt down.

If your team lives in an identity provider, bring your own IdP makes cluster access itself follow your IdP — disable the account there and cluster logins stop with it.