Skip to main content

RBAC & tenancy

Organisation is the hard tenancy boundary. Project is the soft scoping inside an org. Roles compose across the two: an org role applies to every project by default; a project role can override that for one project. This page explains the model; the action matrices live in Auth → RBAC.

Tenancy model​

Organisation (hard boundary)
├── Users (org-level role)
├── Projects (soft scoping)
│   ├── Certificates
│   ├── ACME accounts
│   ├── MSCA connections
│   ├── DNS credentials
│   ├── Zones
│   ├── Modules / Targets / Credentials
│   ├── Distributions
│   ├── Discovery sources
│   ├── Notification channels + rules
│   ├── Certificate policy
│   ├── Approval workflow
│   └── Project variables
└── Org-level settings
    ├── LDAP / AD
    ├── Syslog forwarding
    ├── General auth policy (OTP, session TTL)
    └── License

Cross-org isolation​

  • Every collection with tenant scope carries both org_id and (where applicable) project_id.
  • Every repository method requires the caller's org_id as a filter. A missing org filter is a lint error at review time.
  • No API path allows cross-org reads. A user in one org cannot list, read, or enumerate anything in another org.
  • MongoDB-level: nothing stops a DB-level operator from running db.certificates.find({}) across orgs. Operator trust is assumed at the DB tier; RBAC is application-layer enforcement.

Project scope​

Inside one org, projects are the normal partition unit:

  • Environments — production, staging, dr.
  • Business units — payments, edge, internal-tools.
  • Customers (in managed-service setups) — one project per downstream tenant.

Projects are not a hard security boundary the way org is. An org admin can freely move resources between projects; project-role users enforce the boundary for everyone else.

Role hierarchy​

Four roles: owner > admin > operator > viewer. Higher role implies every lower role's capabilities. Scope matters:

  • Some actions are org-only (create users, configure LDAP, license). Project roles don't grant them.
  • Most day-to-day actions are project-scoped (issue cert, configure DNS, manage distributions). Both org and project roles can grant them.

Full matrix: Auth → RBAC.

How the roles compose​

A user has one org role and zero-or-more project roles. For any action in a project:

  1. Compute effective role = max(org_role, project_role_for_this_project).
  2. Compare to the action's minimum role. Reject if lower.

Example: Alice is org-viewer with project-operator on production.

  • Issue a cert in production? Effective role is operator. Action needs operator. ✅
  • Issue a cert in staging? Effective role is viewer (no project override). Action needs operator. ❌
  • Create a new user? Action is org-only, needs org-admin. Alice's org role is viewer. ❌

Programmatic access and tenancy​

Programmatic callers (scripts, CI/CD, Terraform) authenticate as a regular user with a JWT bearer token — there is no separate API-key credential with its own role or scope. Tenancy is therefore enforced by the calling user's org role and project roles, exactly as it is in the UI.

To scope automation tightly, create a dedicated user with a minimal role (e.g. an operator bound to one project); it can't reach cross-project or cross-org resources. See Programmatic access.

Tenancy in audit logs​

Every audit record carries org_id, project_id (when applicable), actor identity, and IP. Auditors query by tenant easily; admins can't accidentally read another org's audit trail.

Moving resources between projects​

  • Certificates are pinned to a project by their issuer's project; move-project requires reissuance against the target project's issuer.
  • DNS credentials are project-scoped and cannot be cloned implicitly — copy-by-upload if you need the same credential in two projects.
  • Targets + modules are per-project. A target group that spans projects is not possible.

Managed-service / multi-tenant patterns​

If CertAutoPilot powers a managed-service layer where each customer gets its own "workspace":

  • Strong separation → one org per customer. Cross-tenant reads are impossible. Each customer has their own LDAP / license / users.
  • Shared operations → one org, one project per customer. Your SRE team sees across projects; customers see their own project. Automation users scoped per project.

See also​