rbac

Use team-based access controls to assign permissions required to files and project access. Access control is done using RBAC (role-based access control). By default, all authenticated users are assigned to the authenticated team, and unauthenticated users are automatically assigned to the anonymous team. All other configuration is done through team-role mapping.

rbac:
  content:
    secrets.md:
      'Admin': read

The recommended way to configure rbac is within the access object:

access:
  rbac:
    content:
      '**':
        authenticated: read

In the following example, default team permissions are assigned to all pages that do not match any other glob patterns. Different permissions are assigned to the developer-keys.md page, the pages in the /secret/chapter folder, and any TypeScript (.tsx) pages:

access:
  rbac:
    content:
      '**':
        Admin: admin
        Developer: maintain
        Employee: read
        authenticated: read
      developer-keys.md:
        Developer: read
      '/secret/chapter':
        Admin: write
        Developer: read
        Employee: read
      '**/*.tsx':
        Developer: write

In the following example, only the Developer team can create a branch, create a pull request, or create a deployment.

access:
  rbac:
    reunite:
      Developer: write

The following example shows a comprehensive RBAC configuration with project access, content access, environment variables, and authentication requirements:

access:
  rbac:
    # Project administration access
    reunite:
      Developers: write
      Writers: read
      Admin: admin
    
    # File and content access
    content:
    # Default permissions for all files
    '**':
      Developers: maintain
      Writers: write
      authenticated: read
    
    # Specific permissions for sensitive files
    'security/*.md':
      Admin: admin
      Developers: read
    
    # API documentation access
    'apis/**':
      Developers: write
      Writers: read

  # Feature access
  features:
    aiSearch:
      authenticated: read

Environment variables can be used for role assignments, useful for different deployment environments:

access:
  rbac:
    reunite:
      Writers: '{{process.env.RBAC_WRITERS_ROLE}}'
      Developers: '{{process.env.RBAC_DEVELOPERS_ROLE}}'
    content:
      '**':
        Developers: '{{process.env.RBAC_DEFAULT_ROLE}}'
        authenticated: read

To require users to log in before viewing any content:

access:
  rbac:
    content:
      '**':
        authenticated: read

This configuration directs users to a login page where they can authenticate using configured identity providers.

Define the folders and the patterns that the team names match. The following is an example configuration; the curly braces { and } and the placeholder names are shown as they should be used in a configuration file.

  teamFolders:
    - /docs/{teamPathSegment}
    - /apis/{teamPathSegment}
  teamNamePatterns:
    - REDOCLY-{teamPathSegment}-{projectRole}
    - BUSINESS-{teamPathSegment}-{projectRole}

Given the above configuration and the following list of team names:

• REDOCLY-PEARL-triage
• REDOCLY-PEARL-admin
• BUSINESS-AMETHYST-maintain

The effective access control settings would be like the following example configuration:

access:
  rbac:
    reunite:
      REDOCLY-PEARL-triage: triage
      REDOCLY-PEARL-admin: admin
      BUSINESS-AMETHYST-maintain: maintain
    content:
      '/docs/pearl/**':
        REDOCLY-PEARL-triage: triage
        REDOCLY-PEARL-admin: admin
        authenticated: read
      '/apis/pearl/**':
        REDOCLY-PEARL-triage: triage
        REDOCLY-PEARL-admin: admin
        authenticated: read
      '/docs/amethyst/**':
        BUSINESS-AMETHYST-maintain: maintain
        authenticated: read
      '/apis/amethyst/**':
        BUSINESS-AMETHYST-maintain: maintain
        authenticated: read

In the following example, anonymous users have no access to the AI search feature, while authenticated users can access the AI search feature.

access:
  rbac:
    features:
      aiSearch:
        authenticated: read

Access to the MCP server is controlled the same way through the mcp feature. In the following example, only members of the Developers team can access the MCP server, while all other users are denied access.

access:
  rbac:
    features:
      mcp:
        Developers: read

When a team-based role is set for the mcp feature, only teams with a role other than none can access the MCP server. Users must sign in unless the anonymous team is granted such a role, either directly or through the * wildcard. The wildcard covers all teams that are not listed explicitly, including anonymous.

In the following example, members of the Developers team can access Markdown files in the /security folder, except top-secret.md. That file has the none value for Developers in its front matter.

access:
  rbac:
    content:
      'security/*.md':
          Admin: admin
        Developers: read

---
rbac:
  Admin: admin
  Developers: none
---

• Role-based access control (RBAC) concepts - Understand the fundamentals and components of RBAC systems for comprehensive access management
• RBAC configuration guide - Complete implementation guide with examples for projects, pages, and navigation access control
• Front matter configuration - Configure role-based access on individual pages using front matter for granular permission control
• Configuration options - Explore other project configuration options for comprehensive documentation and platform customization
• SSO configuration - Configure single sign-on to identify users and integrate with RBAC for comprehensive authentication and authorization
• SSO Direct configuration - Configure direct SSO integration for streamlined user identification and RBAC implementation
• Requires login configuration - Set up login requirements to enforce authentication before accessing RBAC-protected content
• MCP server - Restrict MCP server access to specific teams with the mcp feature role