Skip to main content
Weaviate Docs (migrated from docs.weaviate.io) Docs

Search documentation

Type to search this documentation.

On this pageOverview

Enable and configure RBAC

Role-based access control (RBAC) is a method of restricting access to resources based on the roles of users. In Weaviate, RBAC allows you to define roles and assign permissions to those roles. Users can then be assigned to roles and inherit the permissions associated with those 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 through the Weaviate configuration file. A predefined role cannot be modified. The user can, however, be assigned additional roles through the Weaviate API.

RBAC authorization can be configured using environment variables. In Docker Compose, set them in the configuration file (docker-compose.yml) such as in the following example:

YAML
services:
  weaviate:
    ...
    environment:
      ...
      # Example authentication configuration using API keys
      # OIDC access can also be used with RBAC
      AUTHENTICATION_ANONYMOUS_ACCESS_ENABLED: 'false'
      AUTHENTICATION_APIKEY_ENABLED: 'true'
      AUTHENTICATION_APIKEY_ALLOWED_KEYS: 'root-user-key'
      AUTHENTICATION_APIKEY_USERS: 'root-user'

      # Authorization configuration
      # Enable RBAC
      AUTHORIZATION_RBAC_ENABLED: 'true'

      # Provide pre-configured roles to users
      # This assumes that the relevant user has been authenticated and identified

      # You MUST define at least one root user
      AUTHORIZATION_RBAC_ROOT_USERS: 'root-user'
      # Enable the runtime user management
      AUTHENTICATION_DB_USERS_ENABLED: 'true'

This configuration:

  • Enables RBAC
  • Configures root-user as a user with built-in admin permissions

You can connect to your instance with the root user in order to create new users which can be assigned custom roles and permissions using the REST API or programmatically using a client library.

For Kubernetes deployments using Helm, API key authentication can be configured in the values.yaml file under the authorization section. Here's an example configuration:

YAML
# Example authentication configuration using API keys
authentication:
  anonymous_access:
    enabled: false
  apikey:
    enabled: true
    allowed_keys:
      - root-user-key
    users:
      - root-user

# Authorization configuration
authorization:
  rbac:
    # Enable RBAC
    enabled: true
    # Provide pre-configured roles to users
    # This assumes that the relevant user has been authenticated and identified
    #
    # You MUST define at least one root user
    root_users:
    - root-user

This configuration:

  • Enables RBAC
  • Configures root-user as a user with built-in admin permissions

You can connect to your instance with the root user in order to create new users which can be assigned custom roles and permissions using the REST API or programmatically using a client library.

When RBAC is enabled, Weaviate automatically logs all authorization decisions for audit purposes. These logs capture:

  • User making the request
  • Action being authorized
  • Authorization decision (allowed or denied)
  • User groups (if applicable)
  • Source IP address (optional)
  • Resource being accessed

Audit logs are written at the info level for successful authorizations and error level for denials. No additional configuration is required - audit logging is automatic when RBAC is enabled.

For details on log format, how to collect and analyze authorization audit logs, and best practices for log retention, see the Logging configuration page.

RBAC is a powerful feature that allows you to define fine-grained access control policies. However, it can also have an impact on performance as each operation must be checked against the user's permissions.

The exact performance impact will depend on your setup and use case. In our internal testing, the most significant performance impact was seen for object creation operations.

We did not observe additional performance penalties for using custom roles over the built-in roles.

Here are some tips to optimize performance when using RBAC:

  • Monitor object creation performance
  • Use a high availability (i.e. 3+ nodes) setup to distribute the load

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

Suggest an edit

Propose a replacement for this page. The site team reviews it before applying any changes.

Export
Documentation menu