Document P2P TLS support for private cloud (#1476)

This commit is contained in:
Predrag Knezevic
2025-02-21 13:14:10 +01:00
committed by GitHub
parent 6f7e0b80c3
commit ee646df4ac
@@ -139,7 +139,7 @@ spec:
If you set the `jwt_rbac` flag, you will also be able to create granular [JWT tokens for role based access control](/documentation/guides/security/#granular-access-control-with-jwt).
### Configuring TLS
### Configuring TLS for Database Access
If you want to configure TLS for accessing your Qdrant database, there are two options:
@@ -195,3 +195,96 @@ spec:
name: qdrant-tls
key: tls.key
```
### Configuring TLS for Inter-cluster Communication
*Available as of Operator v2.2.0*
<aside role="alert">
The feature can be enabled only at the cluster creation. Later changes are not possible.
</aside>
If you want to encrypt communication between Qdrant nodes, you need to enable TLS by providing
certificate, key, and root CA certificate used for generating the former.
Similar to the instruction stated in the previous section, you need to create a secret:
```shell
kubectl create secret generic qdrant-p2p-tls \
--from-file=tls.crt=qdrant-nodes.crt \
--from-file=tls.key=qdrant-nodes.key \
--from-file=ca.crt=root-ca.crt
--namespace the-qdrant-namespace
```
The resulting secret will look like this:
```yaml
apiVersion: v1
data:
tls.crt: ...
tls.key: ...
ca.crt: ...
kind: Secret
metadata:
name: qdrant-p2p-tls
namespace: the-qdrant-namespace
type: Opaque
```
You can reference the secret in the QdrantCluster spec:
```yaml
apiVersion: qdrant.io/v1
kind: QdrantCluster
metadata:
name: test-cluster
labels:
cluster-id: "my-cluster"
customer-id: "acme-industries"
spec:
id: "my-cluster"
version: "v1.13.3"
size: 2
resources:
cpu: 100m
memory: "1Gi"
storage: "2Gi"
config:
service:
enable_tls: true
tls:
caCert:
secretKeyRef:
name: qdrant-p2p-tls
key: ca.crt
cert:
secretKeyRef:
name: qdrant-p2p-tls
key: tls.crt
key:
secretKeyRef:
name: qdrant-p2p-tls
key: tls.key
```
<aside role="status">
The operator assigns the names to nodes in cluster according to the following convention:
```
qdrant-{spec.id}-{node-index}.qdrant-headless-{spec.id}
```
Therefore, in addition to the domain used for accessing the database,
the provided certificate must contain Subjective Alternative Names (SAN) for all foreseen nodes.
It can be created with a tool of your choice, e.g.,
using [step CLI](https://smallstep.com/docs/step-cli/installation/).
Following the example `QdrantCluster`, the proper certificate can be obtained with:
```shell
step certificate create mydomain.com qdrant-nodes.crt qdrant-nodes.key \
--profile leaf --not-after 43800h \
--ca root-ca.crt --ca-key root-ca.key \
--san qdrant-my-cluster-0.qdrant-headless-my-cluster \
--san qdrant-my-cluster-1.qdrant-headless-my-cluster
```
</aside>