Roles & RBAC¶

b'nerd uses a preset-based RBAC model. Permissions are tied to a membership — the join between an account and an organization. An account that belongs to multiple organizations holds a separate membership in each, with independent role and permissions per organization. The same account can be an Admin in one organization and a read-only viewer in another.

The permissions evaluated for a given request are those of the membership that matches the request's ?organization_id. See Organization context for how the server resolves which membership to use.

Roles¶

There are always at least two accounts with the Admin role in a healthy organization — the platform prevents you from removing the last admin.

Permission categories¶

Each membership carries permissions across ten categories:

Actions within a category: read, create, update, delete. The members category also has an invite and remove action; features has a single request action.

Built-in presets¶

Apply a preset with POST /memberships/{id}/apply_preset and { "preset": "<name>" }.

admin¶

Full read/write on all categories. Even though admins bypass permission checks via their role, the preset populates permissions for UI clarity and audit trail.

developer¶

Read/write on infrastructure and apps. Cannot manage billing, members, or settings.

operator¶

Read-only on most resources; can update (but not create/delete) compute, Kubernetes, and apps. No write access to billing, members, or settings.

viewer¶

Read-only across all categories. Suitable for stakeholders who need visibility without any write access.

billing_manager¶

Read-only on infrastructure; can read and update billing. Suitable for finance team members.

Applying a preset via the API¶

POST /memberships/{id}/apply_preset
Authorization: Bearer <token>
Content-Type: application/json

{ "preset": "developer" }

Returns the updated membership with the new permissions. Applying a preset overwrites all existing permissions on that membership.

Listing available presets¶

GET /memberships/presets
Authorization: Bearer <token>

Returns a map of all preset names to their permission hashes.

Custom permissions¶

Presets are a starting point. You can update individual permissions without applying a preset:

PATCH /memberships/{id}
Authorization: Bearer <token>
Content-Type: application/json

{
  "membership": {
    "permissions": {
      "rgw": ["read", "create"],
      "billing": ["read"]
    }
  }
}

Only the categories you include are updated — categories you omit are left unchanged.

Project-level membership grants¶

Beyond the organization-level role and permissions, a Member account can receive project-level grants that give them specific capabilities on a single project. This lets you provision a project admin or scoped collaborator without elevating them across the entire organization.

Project-level grants are bounded by the account's organization-level ceiling: you cannot grant a project capability the account's org membership does not also permit.

Endpoints¶

Roles on a project grant¶

Who can manage project grants¶

• Org Admins can create and modify any project grant in their org.
• Org members with members:invite can grant project access (bounded by their own org ceiling).
• Delegated project admins (accounts with role: Admin on a project grant) can grant access on that specific project — they cannot grant more capabilities than they themselves hold, and cannot assign the project Admin role.

Example: grant a developer access to one project¶

POST /projects/{project_id}/memberships
Authorization: Bearer <token>
Content-Type: application/json

{
  "project_membership": {
    "account_id": "<uuid>",
    "role": "Member",
    "permissions": {
      "openstack": ["read", "create", "update"],
      "apps": ["read", "create"]
    }
  }
}

Returns 201 Created with the new grant. The grantee's org membership is unchanged.