RBAC Overview

Weaviate provides differentiated access through authorization levels based on the authenticated user identity.

If role-based access control (RBAC) is enabled, access can be further restricted based on the roles of users. The diagram below illustrates the RBAC model in Weaviate, where access is governed by defining roles and assigning them specific permissions. These permissions determine which actions users can perform on designated resource types.

The main components are:

• Users: Individual users (e.g., user-a and user-b) are assigned to specific roles.

• Roles: Each role encapsulates a set of permissions. This abstraction lets you manage what actions a group of users can perform.

• Permissions: Permissions are comprised of three parts:

  • Actions: Operations like create, read, update, delete, and manage.
  • Resources: Specific targets for these actions, such as collections and backups.
  • Optional constraints: Resource-specific constraints such as filtering by collection names.

graph LR
  %% Users Subgraph
  subgraph Users
    UA["user-a"]
    UB["user-b"]
  end

  %% Roles Subgraph
  subgraph Roles
    RWR["readWriteRole"]
    BM["backupManager"]
  end

  %% Permissions Group (contains Actions and Resources) with extra newline for spacing
  subgraph Permissions["Permissions"]
    %% Actions Subgraph
    subgraph Actions
      C["create"]
      R["read"]
      U["update"]
      D["delete"]
      M["manage"]
    end

    %% Resources Subgraph
    subgraph Resources
      COL["collections"]
      BAC["backups"]
    end
  end

  %% Connections for user-a
  UA --> RWR
  RWR --> C
  RWR --> R
  RWR --> U
  RWR --> D

  %% Connections for user-b
  UB --> BM
  BM --> M

  %% Connections from actions to resources
  C --> COL
  R --> COL
  U --> COL
  D --> COL
  M --> BAC

%% Styling with soothing, Weaviate-compatible colors and slightly darker borders
style Users fill:#AEDFF7,stroke:#90C7E5,stroke-width:1px
style Roles fill:#C8E6C9,stroke:#A5D6A7,stroke-width:1px
style Actions fill:#ECEFF1,stroke:#B0BEC5,stroke-width:1px
style Resources fill:#CFD8DC,stroke:#AAB4BA,stroke-width:1px
style Permissions fill:#E0F7FA,stroke:#B2EBF2,stroke-width:1px

This RBAC system ensures that users only have the access necessary for their roles, enhancing both security and manageability within Weaviate. Roles and permissions can be managed through the Weaviate REST API directly or through a client library programmatically.

Weaviate comes with a set of predefined roles. These roles are:

• root: The root role has full access to all resources in Weaviate.
• viewer: The viewer role has read-only access to all resources in Weaviate.

The root role can be assigned to a user through the Weaviate configuration file using the AUTHORIZATION_RBAC_ROOT_USERS environment variable. A predefined role cannot be modified. The user can, however, be assigned additional roles through the Weaviate API.

All roles can also be assigned through the Weaviate API, including the predefined role. The predefined roles cannot be modified, but they can be assigned to or revoked from users.

Refer to the RBAC: Configuration page for more information on how to assign predefined roles to users.

Any authenticated user that is not assigned a predefined role has no roles or permissions by default.

These users' permissions can be modified through Weaviate by those with the appropriate permissions for managing roles. This allows for the creation of custom roles, which can be assigned to users as needed.

Role management can be performed with a predefined root role or a custom role with manage_roles permissions.

Permissions in Weaviate define what actions users can perform on specific resources. Each permission consists of:

• A resource type (e.g., collections, objects)
• Access levels (read, write, update, delete, manage)
• Optional resource-specific constraints

Permissions can be defined with the following resources, access levels and optional constraints:

When defining permissions, setting a permission to False indicates that the permission is not set, rather than explicitly denying access. This means that if a user has multiple roles, and one role grants a permission while another sets it to False, the user will still have that permission through the role that grants it.

For example, if a user has two roles:

• Role A sets read to False for Collection X
• Role B sets read to True for Collection X

The user will have read access to Collection X because Role B grants the permission, while Role A's False value simply indicates no permission is set rather than blocking access.

Some permissions require a collection name filter to specify which collections the permission applies to.

In this case, "*" acts as a multi-character wildcard. As an example, setting a permission with "Test*" as the collection name filter would apply that permission to all collections that start with Test. Or, setting a permission with "*" as the collection filter would apply that permission to all available collections.

A collection permission is independent of tenant permissions.

To have permissions to operate on a tenant that belongs to a collection, the user must have the appropriate tenant-level permissions for that collection. Collection-level permissions, such as that to create collections, do not grant the equivalent tenant-level permissions, such as that to create tenants for that collection.

For example, to create a tenant in a collection called TestCollection, the user must have permission to "create" tenants in that collection. This is separate from the permission to create a collection called TestCollection.

The user management API can be used to create, delete and list users, rotate their API keys and manage their roles.

• RBAC: Configuration
• RBAC: Manage roles
• RBAC: Manage users
• RBAC: Tutorial

Have a question or feedback? Here's how to reach us.