Security & Administration

This section documents the current Qdrant 1.x line (latest 1.19.1), written and verified against the official Qdrant documentation. No specific patch version is pinned. Some capabilities (Qdrant Cloud-only features and the full breadth of client-library APIs beyond Python and Java) are linked, not documented in depth.

This content was generated with the assistance of AI and should be verified against the official documentation before being relied on in production.

This section’s bibliography lists the reference material consulted while preparing these pages.

By default a Qdrant node accepts unauthenticated requests over plain HTTP/gRPC — fine for a local trial, not for anything reachable over a network you don’t fully trust. This page covers the built-in API-key authentication and TLS options for a self-managed node, points to Qdrant Cloud’s managed RBAC, and covers the /metrics and /telemetry endpoints every node exposes for observability.

API keys

A self-managed node can require a static API key on every request. Set it in config.yaml under service.api_key, or with the QDRANTSERVICEAPI_KEY environment variable — the environment variable takes precedence and is the usual way to inject it in a container without baking a secret into the image. Once set, every REST and gRPC request must present it or the node rejects it with an authentication error. See Security.

# config.yaml
service:
  api_key: ${QDRANT_API_KEY}          # read-write key
  read_only_api_key: ${QDRANT_RO_API_KEY}   # optional, read-only key (1.x)

On more recent 1.x versions a second, read-only API key (service.read_only_api_key / QDRANTSERVICEREAD_ONLY_API_KEY) can be configured alongside the read-write one. A client authenticating with the read-only key can perform search and retrieval but is rejected on any operation that creates, updates, or deletes a collection, point, or index — useful for handing a key to a read-only consumer (a dashboard, an analytics job) without granting it write access.

A REST client sends the key as the api-key header; a gRPC client sends it as call metadata under the same key name.

curl -s http://localhost:6333/collections \
  -H "api-key: ${QDRANT_API_KEY}"

# gRPC (grpcurl), key sent as call metadata instead of an HTTP header
grpcurl -plaintext \
  -H "api-key: ${QDRANT_API_KEY}" \
  localhost:6334 qdrant.Collections/List

TLS

TLS for both the REST (HTTP) and gRPC listeners is enabled under the tls section of config.yaml, pointing at a certificate and private key (PEM files); service.enable_tls turns it on. Once enabled, clients must connect with https:///a TLS-wrapped gRPC channel and, if the certificate is not publicly trusted, must be configured with the CA used to sign it. See Security.

# config.yaml
service:
  enable_tls: true

tls:
  cert: ./tls/cert.pem
  key: ./tls/key.pem
  # ca_cert: ./tls/ca.pem   # only needed if clients must verify a private CA

Combine enable_tls with api_key so credentials are never sent over an unencrypted channel — an API key alone only authenticates the request, it does not protect it in transit.

Qdrant Cloud RBAC

Role-based access control — scoping a key to specific collections, or to specific operations within a collection, rather than the all-or-nothing read-write/read-only split above — is a Qdrant Cloud feature: it is managed through the Cloud console rather than a config file, so it is described here only in outline rather than documented step by step. Qdrant Cloud lets an account define roles with fine-grained permissions (per-collection, per-operation) and issue API keys scoped to a given role, on top of the cluster-level TLS and network-isolation controls the managed offering already provides. See Security for the current scope of what Cloud RBAC covers.

Monitoring and telemetry endpoints

Every Qdrant node exposes two unauthenticated-by-default HTTP endpoints for operational visibility (they still sit behind the API key when one is configured, like any other REST endpoint):

/metrics — runtime metrics in the Prometheus exposition format: collection counts, point counts, request latencies and throughput, gRPC/REST request counters, and process-level resource usage.
/telemetry — a JSON document describing the cluster’s operational and usage state: collection configuration and sizes, hardware/resource usage, and feature-usage counters, useful for support requests and for dashboards that want more structure than a flat metrics scrape.

See Monitoring for the full field reference of both endpoints.

curl -s -H "api-key: ${QDRANT_API_KEY}" http://localhost:6333/metrics

Where to go next

Clustering & Storage — distribution, replication, and storage tuning for the cluster these endpoints and credentials protect.
Qdrant’s /metrics endpoint is itself a Prometheus exposition format target, so scraping it is an ordinary Prometheus job like any other — see Prometheus & Monitoring for how to actually run Prometheus, scrape it, and alert on it.
RAG Integration Patterns — putting a secured, monitored cluster to work in a retrieval-augmented generation pipeline.