---
title: "RBAC Overview"
description: "Weaviate provides differentiated access through authorization levels based on the authenticated user identity."
url: https://docs.weaviate.io/weaviate/configuration/rbac
---
# RBAC Overview
Weaviate provides differentiated access through [authorization](https://docs.weaviate.io/deploy/configuration/authorization) levels based on the [authenticated](https://docs.weaviate.io/deploy/configuration/authentication) 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.
```mermaid
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](https://docs.weaviate.io/weaviate/api/rest#tag/authz)** directly or through a **[client library](https://docs.weaviate.io/weaviate/configuration/rbac/manage-roles)** programmatically.
## Roles
### Predefined roles
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`](https://docs.weaviate.io/deploy/configuration/env-vars#rbac-authorization) 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](https://docs.weaviate.io/deploy/configuration/configuring-rbac) page for more information on how to assign predefined roles to users.
Weaviate may also ship other predefined roles like the `operator_metadata_reader`. For more info see [Enable and configure RBAC](https://docs.weaviate.io/deploy/configuration/configuring-rbac#metadata-reader-role).
### Custom roles
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](https://docs.weaviate.io/deploy/configuration/configuring-rbac) or a custom role with [`manage_roles` permissions](https://docs.weaviate.io/weaviate/configuration/rbac/manage-roles#role-management-permissions).
> [!WARNING]
>
> **Role Management Permissions**
>
> Be careful when assigning permissions to roles that manage roles. These permissions can be used to escalate privileges by assigning additional roles to users. Only assign these permissions to trusted users.
## 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
### Available permissions
Permissions can be defined with the following resources, access levels and optional constraints:
| Resource type | Access levels | Optional resource‑specific constraints |
| - | - | - |
| [**Role Management**](https://docs.weaviate.io/weaviate/configuration/rbac/manage-roles#role-management-permissions) | Create roles
Read role info
Update role permissions
Delete roles | Role name filter:
• `string or regex`: specifies which roles can be managed
Role scope:
• `all`: Allow role management with all permissions
• `match`: Only allow role management with the current user's permission level |
| [**User Management**](https://docs.weaviate.io/weaviate/configuration/rbac/manage-roles#user-management-permissions) | Create users
Read user info
Update/rotate user API key
Delete users
Assign and revoke roles to and from users | User name filter:
• `string or regex`: specifies which users can be managed |
| [**Collections**](https://docs.weaviate.io/weaviate/configuration/rbac/manage-roles#collections-permissions)
(collection definitions only, data object permissions are separate) | Create collections
Read collection definitions
Update collection definitions
Delete collections | Collection name filter:
• `string or regex`: specifies which collections can be managed |
| [**Tenants**](https://docs.weaviate.io/weaviate/configuration/rbac/manage-roles#tenants-permissions) | Create tenants
Read tenant info
Update tenants
Delete tenants | Collection name filter:
• `string or regex`: specifies which collections' tenants can be managed
Tenant name filter:
• `string or regex`: specifies which tenants can be managed |
| [**Data Objects**](https://docs.weaviate.io/weaviate/configuration/rbac/manage-roles#data-permissions) | Create objects
Read objects
Update objects
Delete objects | Collection name filter:
• `string or regex`: specifies which collections' objects can be managed
Tenant name filter:
• `string or regex`: specifies which tenants' objects can be managed |
| [**Backups**](https://docs.weaviate.io/weaviate/configuration/rbac/manage-roles#backups-permissions) | Manage backups
Read backups (added in `v1.39.10`) | Collection name filter:
• `string or regex`: specifies which collections' backups can be managed |
| [**Cluster Data Access**](https://docs.weaviate.io/weaviate/configuration/rbac/manage-roles#clusters-permissions) | Read cluster metadata | |
| [**Node Data Access**](https://docs.weaviate.io/weaviate/configuration/rbac/manage-roles#nodes-permissions) | Read node metadata at a specified verbosity level | Verbosity level:
• `minimal`: Minimal read permission for all collections.
• `verbose`: Verbose read permission for specified collections.
Collection name filter (only for `verbose`):
• `string or regex`: specifies which collections can be managed |
| [**Collection aliases**](https://docs.weaviate.io/weaviate/configuration/rbac/manage-roles#aliases-permissions) | Create aliases
Read aliases
Update aliases
Delete aliases | Alias name filter:
• `string or regex`: specifies which aliases can be managed |
| [**Replications**](https://docs.weaviate.io/weaviate/configuration/rbac/manage-roles#replications-permissions) | Create replications
Read replications
Update replications
Delete replications | Collection name filter:
• `string or regex`: specifies which collections' objects can be managed
Shard name filter:
• `string or regex`: specifies which shards can be managed |
| [**Groups**](https://docs.weaviate.io/weaviate/configuration/rbac/manage-roles#groups-permissions) | Read groups
Assign and revoke group membership | Group name filter:
• `string or regex`: specifies which groups can be managed
Group type filter:
• `oidc` (only OIDC user groups are supported at the moment) |
| [**MCP**](https://docs.weaviate.io/weaviate/configuration/rbac/manage-roles#mcp-permissions) | Read through MCP tools (`read_mcp`)
Create through MCP tools (`create_mcp`)
Update through MCP tools (`update_mcp`) | No resource filter. MCP permissions gate the [MCP server](https://docs.weaviate.io/weaviate/configuration/mcp-server) tools, and each tool also requires the matching collection, data or tenant permission. |
### Permission behavior
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.
### Name filters in permissions
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.
### Collection and tenant permissions
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`.
## Users
The [user management](https://docs.weaviate.io/weaviate/configuration/rbac/manage-users) API can be used to create, delete and list users, rotate their API keys and manage their roles.
## Further resources
- [RBAC: Configuration](https://docs.weaviate.io/deploy/configuration/configuring-rbac)
- [RBAC: Manage roles](https://docs.weaviate.io/weaviate/configuration/rbac/manage-roles)
- [RBAC: Manage users](https://docs.weaviate.io/weaviate/configuration/rbac/manage-users)
- [RBAC: Tutorial](https://docs.weaviate.io/weaviate/tutorials/rbac)