Skip to main content

RBAC (Role-Based Access Control) Documentation

Overview

The system implements a comprehensive RBAC model to manage access control across different resources and actions. It consists of roles, policies, and user-role assignments.

Core Components

Resources

The system defines the following protected resources:

  • Audit
  • DevPod
  • Image
  • Payment
  • Pubkey
  • Registry
  • Region
  • Resource
  • Serverless
  • Storage
  • Team
  • Role
  • UserRole

Actions

Available actions on resources:

  • List
  • Get
  • Create
  • Update
  • Delete

Role System

A role is a collection of permissions that defines what actions a user can perform on specific resources. Roles help organize and manage access rights efficiently by grouping related permissions together.

Predefined Roles

  1. AccountAdmin

    • Full access to account-level resources
    • Can manage team members
    • Can configure account settings
  2. Developer

    • Can manage DevPods
    • Can manage Serverless resources
    • Can manage Images
    • Can manage Storage (Create/Read only)
  3. Auditor

    • Read-only access to Audit logs
  4. Finance

    • Full access to Payment functions
  5. Ops

    • Read access to DevPods and Serverless
    • Full access to Images, Storage, Pubkey, and Resources

Policies

Policies are the fundamental building blocks of access control that define specific permissions. Each policy represents a rule that grants permission to perform certain actions on specific resources.

Policy Structure

  • Resource: Target resource
  • Action: Permitted action

Policy Assignment

  • Policies are assigned to roles through RolePolicy mapping
  • Multiple policies can be assigned to a single role
  • Policy assignments are unique per role

User Permission Control

The system implements permission control through a three-tier model: Users, Roles, and Policies. Roles act as a bridge between users and policies, providing a flexible and manageable way to control access rights.

Control Flow

  1. User Assignment

    • Users are assigned one or more roles
    • Role assignments are specific to each account
    • A user can have different roles in different accounts
  2. Role as Bridge

    • Roles serve as containers for collections of policies
    • Each role defines a specific set of responsibilities
    • Roles make permission management more maintainable
  3. Policy Enforcement

    • Policies define the actual permissions
    • Each request is validated against the user's roles' policies
    • Access is granted only if a matching policy exists

Authorization Process

  1. Request Processing

    • Extract account information
    • Identify target resource and action
    • Verify user roles and policies
  2. Permission Checking

    • Account-specific roles are validated against target account
    • Policy matching considers both exact matches and wildcards
  3. Access Control

    • Access granted if any assigned role has matching policy
    • Denied requests return empty results rather than errors
    • Audit logging occurs after RBAC validation

Best Practices

  1. Role Management

    • Use predefined roles when possible
    • Create custom roles with minimum required permissions
    • Regularly review role assignments
  2. Security Considerations

    • Always validate account context
    • Implement role-based UI restrictions
    • Maintain audit logs for role changes
  3. Performance

    • Role and policy assignments are cached
    • Batch operations available for bulk assignments
    • Optimized database queries for permission checks