Auditing and fine-grained access

Loopback is built for multi-team organizations: finance, SRE, security, contractors, and auditors often share a tenant. That only works if permissions are granular, defaults are safe, and sensitive actions leave evidence.

This page complements the capability checklist in Access control and permissions with governance patterns, audit expectations, and how to think about blast radius when you design roles.

The three scopes (mental model)

Every permission decision ultimately answers: who can touch what, where?

1. Organization - billing, domains, org-wide DNS, notification channels, bundle repositories, some networking bridges, custom roles, and membership administration.
2. Project - object storage, project load balancers, project DNS zones, monitoring objects, bundle navigation helpers—resources shared across workspaces when you design them that way.
3. Workspace - hosts, kubeconfig surfaces, Kubernetes API proxy, agent tokens, scaling groups, workspace firewalls and LBs, workspace DNS zones—environment-local power.

Fine-grained means: you can grant read-only project access without host create, or deploy rights without shell, or DNS self-service only inside approved name patterns (see DNS zones and access control).

Sensitive capabilities (always treat as “privileged”)

These are the crown jewels in most enterprises:

Loopback separates these into distinct capability areas so you can build SoD (separation of duties): for example SRE deploy without billing admin, or read-only auditor without token mint.

Custom roles (how enterprises actually use Loopback)

Built-in role names vary by deployment, but the pattern is always:

• Start from a least-privilege template (read-only).
• Add narrow bundles: “DNS editor for project X”, “host operator but no shell”, “break-glass shell with time-bound membership”.
• Review quarterly - especially for contractors and integration accounts.

Tip: mirror your ITSM categories. If a ticket type is “infra change”, the role that maps to it should not also include billing.

Auditing: what you should expect

Loopback’s public documentation stays at the capability level; your operator confirms what is logged in your deployment. As a buyer, ask for:

• Authentication events - logins, MFA challenges, failures (often via your IdP + Loopback session layer).
• Authorization failures - repeated 403 patterns can signal probing.
• Privileged actions - kubeconfig download, shell start, host create/destroy, maintenance changes, DNS changes in regulated zones, bundle deploy to production environments.
• Export - SIEM-friendly format, retention aligned with your policy, immutable storage for regulated industries.

If an action is sensitive in the RBAC matrix, assume it should be auditable; if your operator says otherwise, treat that as a gap to close before production.

Fine-grained DNS and shared responsibility

DNS is a common least-privilege puzzle: you want developers to own *.dev.example.com but not the apex domain used for email and corporate identity. Loopback’s pattern-based zones are designed for that story—see DNS zones and access control.

Kubernetes identity: OIDC

Cluster login is not the same as Loopback console login. For the Kubernetes story, read:

• Kubernetes OIDC and authentication providers

Procurement checklist (send to your security team)

• [ ] Map IdP groups → Loopback roles with least privilege.
• [ ] Confirm shell and kubeconfig are disabled by default for broad roles.
• [ ] Require ticket ID or change record in break-glass procedures (process, not only product).
• [ ] Validate audit log coverage for top 10 privileged actions.
• [ ] Run a tabletop: “compromised CI token”, “compromised agent token”, “ex-contractor still in IdP”—what breaks, what is contained?

Related reading

• Access control and permissions
• Members, roles, and IdP
• DNS zones and access control
• Kubernetes OIDC and authentication providers
• Agents, tokens, and shell access
• Technical verification