RBAC Overview
v1.29Role-based access control (RBAC) is generally available in Weaviate from version v1.29.
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-aanduser-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.
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.
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 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.
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 or a custom role with manage_roles 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 | Read roles Manage roles | Role name filter:
Role scope:
|
| Collections (collection definitions only, data object permissions are separate) | Create collections Read collection definitions Update collection definitions Delete collections | Collection name filter:
|
| Tenants | Create tenants Read tenant info Update tenants Delete tenants | Tenant name filter:
|
| Data Objects | Create objects Read objects Update objects Delete objects | Collection name filter:
|
| Backups | Manage backups | Collection name filter:
|
| Cluster Data Access | Read cluster metadata | |
| Node Data Access | Read node metadata at a specified verbosity level | Verbosity level:
Collection name filter (only for
|
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
readtoFalsefor Collection X - Role B sets
readtoTruefor 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.
Additional resources
Questions and feedback
If you have any questions or feedback, let us know in the user forum.