How does Qdrant secure access to its REST and gRPC APIs by default, and what must you configure to enable it?

Out of the box, a self-hosted Qdrant instance has no authentication and no encryption. It binds to all network interfaces and accepts requests from anyone who can reach the port. The official documentation is explicit about this: 'By default, all self-deployed Qdrant instances are not secure. They are open to all network interfaces and do not have any kind of authentication configured. They may be open to everybody on the internet without any restrictions'[reference:0]. Qdrant Cloud instances are secure by default, but self-hosted deployments require you to explicitly enable security features before going to production[reference:1]. This is a deliberate design choice - it makes local development frictionless - but it means the burden of securing the instance is entirely on you.

To enable authentication, you set an api_key in the service configuration. There are two ways to do this: in config/config.yaml under the service section, or via the QDRANT__SERVICE__API_KEY environment variable[reference:2]. Once set, every REST and gRPC request must include the key in the api-key header (or the Authorization: Bearer header, which follows standard OAuth conventions)[reference:3]. The API key authentication feature requires Qdrant 1.2 or later[reference:4]. It is critical to enable TLS alongside the API key - sending an API key over an unencrypted connection exposes it to anyone on the network, and the official documentation explicitly warns: 'Never send API keys over unencrypted connections. Always enable TLS when using API key authentication in production'[reference:5]. Beyond authentication, the recommended production security posture also includes binding to a private network interface rather than 0.0.0.0, and enabling TLS for all traffic[reference:6].

The trade-off is operational simplicity against security. Leaving authentication off makes local development and quick prototyping easy, but it means an instance exposed to a network is fully open - anyone can read, write, or delete all data. The common mistake is deploying a self-hosted Qdrant instance to a cloud VM or a Kubernetes cluster without setting an API key, relying on the network perimeter for protection. Security researchers have found significant percentages of publicly reachable vector database instances running without authentication, and Qdrant is among the engines with this pattern[reference:7]. The second mistake is enabling the API key but not TLS, which protects against casual access but not against anyone who can sniff network traffic. The third mistake is binding to 0.0.0.0 and relying solely on firewall rules, which fails if the firewall is misconfigured. The alternative to Qdrant's built-in authentication is to put the instance behind a reverse proxy or API gateway that handles authentication, which is a valid pattern but adds a component to the architecture. Version note: the configuration format and the available authentication options have changed across releases - API key support was added in 1.2, and JWT RBAC in 1.9 - so verify the exact configuration on your version.

Version-dependent: API key authentication requires Qdrant 1.2 or later, and TLS requires 1.2 or later as well. Granular access API keys using JWT require 1.9 or later[reference:8]. The configuration format (YAML keys and environment variable names) has been stable across recent releases, but the set of available security features has expanded. Qdrant Cloud enables authentication and TLS by default, so the self-hosted configuration described here does not apply to Cloud deployments.