Roles and Permissions (RBAC)¶

MazeVault Role-Based Access Control — Roles, Permissions, and Domain Separation

Document Version: 2.2.0
Last Updated: 2026-05-30

1. Overview¶

MazeVault uses a Role-Based Access Control (RBAC) system to manage user permissions. Each user is assigned one or more roles that determine what they can see and do in the system.

Key principles:

Least Privilege — Users receive only the permissions they need
Domain Separation — Certificate Manager cannot access secrets; Secret Manager cannot access certificates
Environment Scoping — A role can be assigned for one environment (dev, staging, prod), one project or one organization. Such an assignment applies there only, whichever way the user signs in (web interface, API token, JWT). The project of a request is the one its path names (/projects/{id}) or the one the resource it names belongs to (a secret, also an archived one, a certificate, an approval request or policy, a project integration, a sync rule or conflict, a consistency group or warning). A project_id in the query or the JSON body is the request's project only on the routes that act on that project: reading a secret by project and key (GET /api/v1/secrets/, GET /api/v2/secrets), creating a secret (POST /api/v1/secrets/, POST /api/v2/secrets), comparing environments (POST /api/v2/secrets/compare), drift detection (POST /api/v1/secrets/drift/detect) and the consistency groups of a project (GET /api/v1/consistency-groups). On every other route it is no scope, and one that differs from the route's project is refused, whatever the body's Content-Type: the check reads the body as the route does (its first JSON value, keys in any case), treats a project_id or organization_id that is not a string as one where nobody holds a scoped role, and refuses a write body over 16 MiB with 413 (after checking that the caller holds the permission at all). On PUT /api/v1/certificates/{id} and PUT /api/v1/rotation/templates/{id} the body's project_id moves the resource: the permission must hold in its project and in the target project. Updating a sync rule, an approval policy or a configuration template never changes its project or organization, and a sync rule takes only an integration of its own project. A project-scoped assignment does not count for a request without a project, so managing users, roles, the organization and its settings, or creating projects, needs a role assigned without a project. A web interface session and an API token request belong to the default organization. A request that names another organization (its /organizations/{id} path, an organization_id query or body field) needs the permission there as well, so an assignment scoped to one organization applies to that organization only. The routes that act on several projects (the projects list, drift detection over every project, the migration of several secrets to zero-knowledge, the organization's secret naming check) accept a role on any project and then act per project: the projects list shows only the projects the user may read, and the others need the permission on every project they touch. On a project page the web interface shows the actions the user may take in that project. The role shown on a user is the highest role assigned without a scope; it is a label and grants nothing by itself. A user created at first sign-in (SSO, LDAP, SAML, SPNEGO) or by SCIM is assigned its default role everywhere: Viewer, or the default role configured for SPNEGO.
Two-Level Cloud Access — Access to Azure resources requires BOTH MazeVault role AND Azure RBAC permission

2. System Roles¶

MazeVault provides the following built-in roles:

Role	Description	Domain
Viewer	Dashboard and system outputs only — no access to secrets, certificates, or projects	Read-only
User	Standard user — can create/edit secrets, request certificates, view projects	General
Certificate Manager	Full certificate lifecycle management — NO access to secrets	Certificates
Secret Manager	Full secret lifecycle management — NO access to certificates	Secrets
Project Admin	Full project management including create/delete projects, manage settings	Administration
Admin	Full system access — all permissions	System
Auditor	Read-only access to audit logs, user lists, and deployment status	Compliance
Finance	Read-only access to billing and usage data	Billing

Domain Separation

Certificate Manager and Secret Manager are mutually exclusive domains. A Certificate Manager cannot view or manage secrets, and a Secret Manager cannot view or manage certificates. This ensures separation of duties in enterprise environments.

What each role can see in the MazeVault UI:

Section	Viewer	User	Cert Mgr	Secret Mgr	Project Admin	Admin	Auditor	Finance
Dashboard Overview	✅	✅	✅	✅	✅	✅	📖	❌
Dashboard Certificates	✅	✅	✅	✅	✅	✅	❌	❌
Dashboard Entra	✅	✅	✅	✅	✅	✅	❌	❌
Projects	❌	📖	✅	✅	✅	✅	❌	❌
Discovered Certificates	❌	📖	✅	✅	✅	✅	❌	❌
Deployment	❌	❌	✅	✅	✅	✅	❌	❌
Access Control	❌	📖	📖	📖	✅	✅	📖	❌
Organization Settings	❌	❌	❌	❌	✅	✅	❌	❌
Environments	❌	📖	📖	📖	✅	✅	❌	❌
Usage and Billing	❌	❌	❌	❌	❌	✅	❌	📖
Archived Items	❌	❌	📖	📖	✅	✅	❌	❌
Audit Logs	❌	❌	❌	❌	✅	✅	📖	❌
KeyTab Management	❌	📖	❌	✅	✅	✅	📖	❌
Reports / System Outputs	❌	📖	📖	📖	✅	✅	📖	❌

📖 = Read-only access

4. Permission Matrix — Secrets¶

Action	Viewer	User	Cert Mgr	Secret Mgr	Project Admin	Admin
Read secret value	❌	✅	❌	✅	✅	✅
Create secret	❌	✅	❌	✅	✅	✅
Edit secret	❌	✅	❌	✅	✅	✅
Rotate secret	❌	✅	❌	✅	✅	✅
Archive secret	❌	✅	❌	✅	✅	✅
Delete secret	❌	❌	❌	✅	✅	✅
Permanently delete	❌	❌	❌	❌	❌	✅
Import/Export	❌	✅	❌	✅	✅	✅

5. Permission Matrix — Certificates¶

Action	Viewer	User	Cert Mgr	Secret Mgr	Project Admin	Admin
Read certificate	❌	✅	✅	❌	✅	✅
Request certificate	❌	✅	✅	❌	✅	✅
Import certificate	❌	✅	✅	❌	✅	✅
Approve CSR	❌	❌	✅	❌	✅	✅
Enroll certificate	❌	❌	✅	❌	✅	✅
Archive certificate	❌	❌	✅	❌	✅	✅
Revoke certificate	❌	❌	✅	❌	✅	✅
Permanently delete	❌	❌	❌	❌	❌	✅

6. Permission Matrix — Projects & Organization¶

Action	Viewer	User	Cert Mgr	Secret Mgr	Project Admin	Admin
View projects	❌	📖	✅	✅	✅	✅
Create project	❌	❌	❌	❌	✅	✅
Edit project	❌	❌	❌	❌	✅	✅
Archive project	❌	❌	❌	❌	✅	✅
Delete project	❌	❌	❌	❌	✅	✅
Permanently delete	❌	❌	❌	❌	❌	✅
View org settings	❌	❌	❌	❌	✅	✅
Edit org settings	❌	❌	❌	❌	❌	✅
Manage users/roles	❌	❌	❌	❌	❌	✅

6.1 Resource Visibility Policy¶

resource_visibility_policy is a special organization-level governance template under Organization Settings → Config Templates.

Only Admin users with organization-admin authority can create, preview, edit, delete, or see this template type.
Project Admin can still access Organization Settings generally, but does not gain access to this admin-only template type.
Preview uses live Azure / Microsoft Graph discovery data and requires project_id context so MazeVault can resolve the correct organization policy.
Discovery filtering is enforced server-side for non-admin callers. Hidden app registrations and Key Vaults are removed from discovery results instead of being shown as placeholders.
Key Vault matching uses Azure ARM resource tags. App registration matching uses Microsoft Graph application.tags.

This keeps sensitive discovery governance with organization administrators while preserving the broader config template workflow for non-admin template types.

7. Role Incompatibilities¶

Certain roles have domain separation and redundancy rules:

Role Combination	Allowed?	Reason
Certificate Manager + Secret Manager	⚠️ Not recommended	Defeats domain separation purpose
Certificate Manager + User	✅ Allowed	User adds general read access
Secret Manager + User	✅ Allowed	User adds general read access
Any role + Admin	⚠️ Not recommended	Admin already has all permissions — additional roles are redundant, unnecessary, and create complexity in audit trails
Auditor + any operational role	⚠️ Not recommended	Auditor should be independent

Admin Role Best Practice

The Admin role includes every permission in the system. Assigning additional roles alongside Admin provides no extra access and is not recommended. It complicates role auditing and may create confusion about the actual source of permissions. If a user needs Admin access, assign only the Admin role.

8. Azure Cloud Resource Access — Two-Level Control¶

When MazeVault is integrated with Azure Key Vault, access to cloud resources requires two simultaneous conditions:

MazeVault RBAC — User must have the appropriate MazeVault role and permission
Azure RBAC — User must have the corresponding Azure role assignment on the Key Vault

Managed Identity vs User Access

Managed Identity is used ONLY for automated operations (scheduled rotations, background sync). For ALL user-initiated operations (reading secrets, manual rotation, editing), the user's own Azure identity is used via On-Behalf-Of (OBO) token flow. MazeVault never uses Managed Identity to bypass Azure RBAC for user operations.

Operation	Token Type	Azure RBAC Required
Scheduled secret rotation	Managed Identity	MI must have Key Vault access
User reads secret from KV	OBO (user token)	User must have Key Vault Secrets User
User edits secret in KV	OBO (user token)	User must have Key Vault Secrets Officer
Agent certificate discovery	Managed Identity	MI must have read access
Admin imports secrets from KV	OBO (user token)	User must have Key Vault Secrets Officer

9. Group Mapping¶

MazeVault supports mapping external identity provider groups to system roles:

Entra ID (Azure AD) — Map Entra security groups to MazeVault roles
LDAP / Active Directory — Map LDAP groups to MazeVault roles
SPNEGO / Kerberos — Map Kerberos groups via LDAP fallback

Group mappings are managed in Access Control → Groups tab. Each mapping specifies:

External group identifier
Target MazeVault role
Optional scope (organization, project, environment): a scoped mapping grants its role in that scope only

10. Custom Roles¶

Administrators can create custom roles with specific permission sets. Custom roles can combine any available permissions to match your organization's needs.

Available permission categories:

secret:read, secret:write, secret:delete, secret:archive, secret:rotate
certificate:read, certificate:write, certificate:revoke, certificate:approve, certificate:archive
project:read, project:write, project:delete, project:archive
rotation:read, rotation:write, rotation:execute
audit:read, role:read, role:write, billing:read
keytab:read, keytab:write, keytab:delete, keytab:admin
token:read, token:write, token:delete, token:admin — Token Management (Enterprise Function)
config:read, config:write — Configuration Management (Enterprise Function)
report:read, report:write
sync:read, consistency:read, consistency:write
integration:read, integration:write
And many more...

Contact your MazeVault administrator for custom role creation.

11. Permission Matrix — KeyTab Management¶

Since v1.0.38

Action	Viewer	User	Cert Mgr	Secret Mgr	Project Admin	Admin	Auditor
View keytabs	❌	✅	❌	✅	✅	✅	✅
Import keytab	❌	❌	❌	✅	✅	✅	❌
Update keytab	❌	❌	❌	✅	✅	✅	❌
Delete keytab	❌	❌	❌	✅	✅	✅	❌
Manage cipher policy	❌	❌	❌	❌	✅	✅	❌
View discovered keytabs	❌	✅	❌	✅	✅	✅	✅
Import discovered keytab	❌	❌	❌	✅	✅	✅	❌
View dashboard	❌	✅	❌	✅	✅	✅	✅

12. Permission Matrix — Reports¶