Why should TLS be enabled for Qdrant's REST/gRPC endpoints even inside a private VPC?

TLS inside a private VPC is a defense-in-depth control. The argument against it is usually 'the network is private, so no one can sniff the traffic.' That argument has three weaknesses. First, it assumes the network is actually private - VPCs are shared by many services, some of which may be compromised, misconfigured, or operated by a different team with different security standards. A compromised service in the same VPC can potentially capture traffic to other services. Second, it assumes that no attacker ever gets a foothold inside the network. If an attacker compromises any workload in the VPC, they can potentially sniff unencrypted traffic. TLS means that even if they capture the traffic, they cannot read the API keys or the data. Third, it assumes that the Qdrant port is never accidentally exposed - a misconfigured security group or a Kubernetes service exposure can make an internal port reachable from a broader network. TLS is the control that protects the data and the credentials even if the network perimeter fails.

The specific risk that TLS mitigates is the exposure of the API key and the query data. Qdrant API keys are sent in the api-key header, and without TLS they travel in plaintext over the network. Anyone who can capture a single request captures the API key, and with that key they can access the instance. The official documentation explicitly warns: 'Never send API keys over unencrypted connections. Always enable TLS when using API key authentication in production'[reference:39]. The same applies to the query vectors and payloads - if they are unencrypted, a network observer can read them. Inside a VPC, the observer might be a compromised service, a malicious insider, or an attacker who has gained a foothold. TLS does not prevent the compromise, but it limits the damage by ensuring that captured traffic is not readable. This is the essence of defense in depth: you do not rely on a single control (the network perimeter) to protect you, you layer controls so that a failure of one does not lead to a total compromise.

The trade-off is a small amount of operational complexity and a small latency overhead. TLS adds certificate management - generating, distributing, and rotating certificates - and the handshake adds a small amount of latency to each connection (though connection reuse amortizes this). The certificate management is the main operational cost, and it is well-understood. The common mistake is treating the VPC as a security boundary and assuming that everything inside it is trusted. This is the 'crunchy outside, soft inside' model, and it fails when any service in the VPC is compromised. The second mistake is enabling TLS for external traffic but not internal traffic, which leaves the internal path unprotected. The third mistake is using self-signed certificates without proper validation, which can enable man-in-the-middle attacks. The alternative to TLS is a service mesh that provides mutual TLS (mTLS) automatically, which is a valid pattern for large deployments but adds significant infrastructure complexity. Version note: TLS support has been available since Qdrant 1.2 and the configuration format has been stable, but the certificate options (CA certificates, client certificates) have expanded in recent releases.

Version-dependent: TLS support requires Qdrant 1.2 or later. The configuration fields (enable_tls, cert, key) have been stable, but the ability to configure a CA certificate for mutual TLS and the exact certificate validation behavior have evolved. If you are using a service mesh for mTLS, you may not need Qdrant's built-in TLS, but you still need to ensure that the mesh actually provides mTLS and that no plaintext path exists.