> ## Documentation Index
> Fetch the complete documentation index at: https://docs.usenubis.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Roles & Permissions

> How Nubis RBAC works for members, custom roles, and service accounts.

## Role-based access control in Nubis

Role-Based Access Control lets you manage access through roles instead of one-off permission decisions. In Nubis, roles are attached to organization members and can also back service accounts used for automation.

## Key concepts

### Roles

The repo currently defines system roles around this model:

* **Owner**: Full access across the organization, including IAM and billing.
* **Admin**: Broad administrative access without full owner-level control.
* **Member**: General access that is usually narrower and more read-oriented by default.

### Permissions

Permissions are granular capabilities grouped across services such as:

* Compute and scaling
* Networking and DNS
* Storage and databases
* Billing and credits
* IAM, service accounts, and webhooks

### Identities

Team members and service accounts are the identities that receive roles.

## Default roles

<CardGroup cols={2}>
  <Card title="Owner">
    * Full account control
    * Billing management
    * Role and member administration
    * Full infrastructure access
  </Card>

  <Card title="Admin">
    * Create and manage resources
    * Manage team members
    * View billing
    * Broad operational access
  </Card>

  <Card title="Member">
    * Common day-to-day access
    * Usually oriented around read or scoped operations
    * Can be replaced or narrowed by custom roles
    * Good base for standard collaborators
  </Card>
</CardGroup>

## Getting started

<Steps>
  <Step title="Invite team members">
    Open the organization members view and invite the teammate by email.
  </Step>

  <Step title="Assign a role">
    Start with the narrowest role that still lets the person do their job.
  </Step>

  <Step title="Review access regularly">
    Revisit role membership as teams, projects, and automation needs change.
  </Step>
</Steps>

## Custom roles

Create custom roles when the default role set is too broad or too narrow:

1. Start from the permissions your team actually uses.
2. Group them into a role that matches a real responsibility.
3. Reuse that role for both teammates and service accounts where appropriate.
4. Review role membership regularly as teams and systems change.

## Best practices

<Warning>
  Start with least privilege. Grant only the permissions a person or automation path actually needs.
</Warning>

* Keep billing and IAM access limited to trusted operators.
* Use service accounts instead of personal keys for CI/CD and automation.
* Remove stale identities quickly when teammates leave or systems are retired.