Users, teams & RBAC
Bootstrap administration, assign least-privileged roles, and keep human sessions separate from machine identities.
Exact release scope. This page documents the reviewed v0.0.1 source at fcc5871. Check release status before enabling a gated capability.
Built-in roles
| Role | Intended use | Guidance |
|---|---|---|
platform_admin | Platform configuration, identity, gates, provider and high-risk administration. | Keep membership small; use separate daily operator accounts. |
ops | Approved infrastructure, cluster, add-on, run, and diagnostic operations. | Primary human operations role; destructive actions still require explicit gates. |
developer | Developer-facing cluster and application workflows within approved scope. | Does not imply platform or provider administration. |
tester | Read, validation, and QA-oriented workflows. | Use for evidence review and bounded validation. |
service_principal | Machine-to-machine integrations. | Use API keys/scopes, rotation, quota, and revocation; never share a human session. |
Legacy qa_operator maps to ops; read_only_operator maps to tester. Review legacy assignments after upgrade rather than assuming the new privilege is equivalent.
Bootstrap the first administrator
- 01
Restrict the initial endpoint
Keep ClusterPilot on an administrator-only network until bootstrap is complete.
- 02
Create the bootstrap administrator
Use the supported first-run flow and a unique identity. Do not ship a shared default password.
- 03
Create teams and operational users
Model durable responsibility through teams and memberships rather than direct one-off privilege.
- 04
Create a separate daily account
Reserve the bootstrap/high-privilege identity for recovery and protected administration.
- 05
Test revoke and recovery
Revoke a session/API key, remove a membership, and prove the documented break/fix path before opening access.
Human sessions
- ✓Use HTTPS, secure cookies, approved same-site policy, and CSRF protection for browser mutations.
- ✓Set session idle and absolute lifetime to the customer policy.
- ✓Revoke sessions after role, membership, password, or incident changes.
- ✓Audit sign-in, sign-out, refresh, failure, lockout, role and membership events.
- ✓Do not copy cookies or anti-CSRF tokens into command examples, tickets, or browser recordings.
Machine identities and API keys
Create a service principal for each integration and environment. Assign only the required scopes, store the token in the calling system’s secret manager, enforce quotas, rotate it, and test revocation. API keys are not browser sessions and should not inherit a human user’s open-ended permissions.
| Control | Requirement |
|---|---|
| Ownership | Named system, team, environment, purpose, and expiry. |
| Scope | Only required read/write endpoint families. |
| Storage | Secret manager; never repository, environment dump, URL, or issue. |
| Rotation | Overlapping cutover with audit of old-key revocation. |
| Incident response | Immediate revoke, identify calls by key ID/correlation, replace affected downstream secrets. |
Quarterly access review
- ✓Export users, teams, memberships, roles, active sessions, service principals, and API key metadata.
- ✓Remove inactive users, unused service principals, stale sessions, and expired ownership.
- ✓Verify platform_admin and ops membership against the current on-call and change-approval model.
- ✓Sample destructive and secret-related audit events for correct actor, scope, correlation, and decision.
- ✓Retest bootstrap-admin recovery without weakening normal controls.