Access control and permissions

Loopback uses role-based access control (RBAC) at organization, project, and workspace granularity. This page translates internal permission keys into plain-language capabilities so you can design roles and audits.

Rule of thumb: if an action touches infrastructure, secrets, or money, it has a dedicated permission — not just “workspace read”.

How enforcement works (conceptually)

1. Your account has memberships in organizations.
2. Each membership assigns roles.
3. Each role grants allow on permission keys for specific resources (org-wide, or narrowed to a project / workspace).
4. Every API action checks read / create / update / delete / execute as appropriate.

Organization-level permission areas

• Organization — core org read/update (profile, status-adjacent fields as exposed).
• Organization.billing — invoices, spending, financial settings.
• Organization.project — list/create/update projects.
• Organization.membership — add/remove members, change their roles (where UI exposes).
• Organization.membership_invite — invite users.
• Organization.role — manage custom roles.
• Organization.payment_method — cards/SEPA.
• Organization.authentication_provider — IdP for Loopback login.
• Organization.domain — domain records.
• Organization.dns_record / organization.dns_record_zone — DNS at org scope.
• Organization.firewall / organization.firewall.rule — org firewalls (legacy paths may exist).
• Organization.notification_channel — alert destinations.
• Organization.monitoring_source — monitoring catalog entries.
• Organization.bundle (+ repository, environment, revision, image, manifest, deployment) — bundles lifecycle.

Project-level permission areas

• Project.dns_zone — project DNS zones.
• Project.object_store — list/create buckets.
• Project.object_store.credentials — issue/rotate keys.
• Project.object_store.policy — policy docs.
• Project.load_balancer (+ target, service) — project LBs.
• Project.monitoring_object (+ condition, state) — configure probes.
• Project.monitoring.alert — view/ack alerts (exact split depends on UI).
• Project.bundle.environment / project.bundle.revision — bundle helpers scoped to project navigation.

Workspace-level permission areas

• Project.workspace — baseline workspace CRUD and read.
• Project.workspace.kubernetes — Kubernetes metadata (versions list, etc.).
• Project.workspace.kubernetes.deployments — view/manage deployment listings exposed to portal.
• Project.workspace.kubernetes.kubeconf — download admin kubeconfig.
• Project.workspace.kubernetes.authenticate — retrieve OIDC kubeconfig / exec permission.
• Project.workspace.kubernetes.secrets — portal access to Kubernetes secret workflows (if enabled).
• Project.workspace.host — list/order/delete hosts.
• Project.workspace.host.shell_session — open remote shell sessions (highly sensitive).
• Project.workspace.agent_token — create/list/revoke agent install tokens.
• Project.workspace.scaling_group — autoscaling groups.
• Project.workspace.firewall / firewall.rule — workspace firewalls (environment-gated in some builds).
• Project.workspace.load_balancer (+ targets/services) — workspace-scoped LBs.
• Project.workspace.dns_zone — DNS zones pinned to workspace.
• Project.workspace.bundle.deployment — bundle deployments targeting this workspace.

Sensitive combinations (SOC2-minded)

Audit

Many sensitive routes declare audit keys (e.g. kubeconfig download, host create, maintenance update). Your operator should forward audit logs to SIEM.

Related reading

• Members & roles
• Access & kubeconfig
• Accounts