Access control and permissions
Loopback uses role-based access control (RBAC) at organization, project, and workspace granularity. This page describes capability areas in plain language so you can design roles and audits. Exact permission identifiers in HTTP metadata are an implementation detail your operator can map in diligence packs.
Rule of thumb: if an action touches infrastructure, secrets, or money, it has a dedicated gate - not just “workspace read”.
How enforcement works (conceptually)
- Your account has memberships in organizations.
- Each membership assigns roles.
- Each role grants allow rules on resources at organization, project, or workspace scope (sometimes narrowed to specific object instances).
- Every API action checks read / create / update / delete / execute as appropriate.
Organization-level capability areas
- Organization profile - core org read/update (profile, status-adjacent fields as exposed).
- Billing - invoices, spending, financial settings.
- Projects - list/create/update projects.
- Memberships - add/remove members, change their roles (where UI exposes).
- Invitations - invite users.
- Custom roles - manage role definitions.
- Payment methods - cards/SEPA and similar instruments.
- Authentication providers - IdP for Loopback login.
- Domains - registered names under the org.
- DNS at org scope - records and pattern zones for delegated naming.
- Organization firewalls - baseline policy objects and their rules.
- Notification channels - alert destinations.
- Monitoring sources - monitoring catalog entries.
- Bundles - repositories, environments, revisions, builds, deployments, and related operations across the org.
Project-level capability areas
- Project DNS zones - DNS zones scoped to the project.
- Object storage - list/create buckets; credential issue/rotate; policy documents where exposed.
- Project load balancers - front ends, targets, services.
- Monitoring - monitoring objects, conditions, states; alerts (view/ack splits depend on deployment).
- Bundle navigation helpers - project-scoped views of environments/revisions tied to bundle workflows.
Workspace-level capability areas
- Workspace baseline - workspace CRUD and read.
- Kubernetes metadata - version/upgrade surfaces exposed in the product.
- Kubernetes deployments listing - views or actions on deployment summaries in the product (distinct from raw
kubectl). - Admin kubeconfig - download cluster-admin-class kubeconfig material (break-glass).
- OIDC kubeconfig / exec - human-friendly cluster access through your IdP.
- Kubernetes secrets via product - guided secret workflows (if enabled).
- Hosts - list/order/delete servers.
- Remote shell - interactive sessions to hosts (highly sensitive).
- Agent tokens - create/list/revoke agent install tokens.
- Scaling groups - autoscaling configuration and actions.
- Workspace firewalls - policy + rules (sometimes environment-gated).
- Workspace load balancers - LB + targets + services.
- Workspace DNS zones - DNS zones pinned to the workspace.
- Bundle deployments - deployments targeting this workspace.
Sensitive combinations (SOC2-minded)
| Capability | Risk |
|---|---|
| Admin kubeconfig | Full cluster admin file - treat as break-glass. |
| Remote shell | Interactive control on servers - log heavily; time-bound. |
| Object storage credentials | Data exfiltration / bucket wipe. |
| Agent token create | Lets installer join untrusted machines into workspace fleet. |
| Billing | Financial fraud or invoice visibility. |
Audit
Many sensitive actions are audit-logged (kubeconfig download, host create, maintenance changes, and similar). Your operator should forward audit logs to SIEM.
Related reading
- Auditing and fine-grained access - governance patterns and sensitive combinations.
- Members & roles
- Access & kubeconfig
- Accounts
- Technical verification