Qdrant RBAC

What Qdrant RBAC does

The Qdrant RBAC MCP server exposes Qdrant vector-store operations through a streamable HTTP MCP endpoint. It authenticates callers with OIDC access tokens, maps their roles to grants, and forwards permitted requests to Qdrant with a derived JWT. Keycloak-compatible OIDC providers are supported through discovery and JWKS endpoints.

Access can be assigned at the collection level as read-only, read/write, or manage. Grants are stored as points in a dedicated ACL collection rather than in static configuration. The server can create that collection on its first read. Administrators can manage grants at runtime through MCP tools, including grant_access.

Optional document policies narrow access within a collection. Policies can allow or deny documents according to payload fields such as acl_tags or source. This makes the Qdrant RBAC MCP server suitable for separating collections and individual records by role.

How it works

An MCP client sends an Authorization: Bearer token to the /mcp endpoint. The authentication middleware checks the token signature, expiry, issuer, audience, required subject, and optional not-before claim against the OIDC provider's published keys. Supported signing algorithms are RSA and elliptic-curve variants: RS256, RS384, RS512, ES256, ES384, and ES512. Symmetric and unsigned tokens are rejected.

Roles are read from realm_access.roles and from client roles under resource_access. Users in the configured break-glass administrator role receive a global-manage Qdrant token. Other users are evaluated against the cached role-to-grant mapping from the ACL collection. Each tool checks access for its target collection before making a Qdrant request.

For reads, a document policy becomes a Qdrant payload filter added as a required condition. Caller-provided filters remain active, so both restrictions apply. Multiple grants are merged using the most-permissive applicable policy; an unrestricted grant removes document-level restrictions for that collection.

Setup and configuration

The server runs as a container or as its own Python project. A typical container exposes port 8000 and uses /mcp for streamable HTTP. /health is unauthenticated. Required configuration includes the OIDC issuer URL, OIDC audience, Qdrant URL, and the same JWT secret configured as Qdrant's API key.

Useful settings also include the administrator role, ACL collection name, and JWKS cache lifetime. The ACL collection defaults to _rbac_acl. The repository provides a Docker environment template with the complete variable set.

Tools and capabilities

Available MCP operations include:

• list_collections to return collections readable by the caller.
• get_collection_info to inspect an accessible collection.
• search_collection and search_collection_by_text for vector and text-based retrieval.
• scroll_collection and list_documents for reading points and document facets.
• upsert_points and delete_points for collections where the caller has write access.
• grant_access for runtime administration of role grants, including document policies.

Limitations and notes

The server depends on an OIDC provider, reachable JWKS discovery, Qdrant, and a shared JWT secret. Role changes are read through a TTL-cached ACL resolver, so updates may not take effect until the relevant cache expires. The iat claim is not checked, although expiry, issuer, audience, signature, subject, and nbf are enforced.

Document policies operate on Qdrant payload fields. Documents without acl_tags remain visible under matching default-allow rules but do not satisfy allow conditions under default-deny rules. The service does not require acl_tags; other payload fields can be used instead.