mirror of
https://github.com/qdrant/landing_page.git
synced 2026-09-25 22:18:30 +02:00
Add encryption at rest docs for Managed Cloud (#2661)
* Add encryption at rest docs for Managed Cloud * Make instructions more high-level * Review feedback
This commit is contained in:
@@ -17,7 +17,7 @@ Qdrant Cloud offers an optional premium tier for customers who require additiona
|
||||
* **99.9% Uptime SLA**: We guarantee 99.9% uptime for your Qdrant Cloud clusters (compared to 99.5% in standard).
|
||||
* **Single Sign-On (SSO)**: Premium customers can use their existing SSO provider to manage access to Qdrant Cloud.
|
||||
* **VPC Private Links**: Premium customers can connect their Qdrant Cloud clusters to their VPCs using private links.
|
||||
* **Storage encryption with shared keys**: Premium customers can encrypt their data at rest using their own keys.
|
||||
* **Storage encryption with shared keys**: Premium customers can [encrypt their data at rest using their own keys](/documentation/cloud/encryption/).
|
||||
* **Topology Aware Multi-AZ Setup**: Premium customers can deploy their clusters across multiple availability zones for higher availability and resilience. This guarantees a **99.95% uptime SLA** for Multi-AZ clusters. Multi-AZ is independent of replication factor; see [Multi-AZ Deployments](/documentation/scaling/resilience/#multi-az-deployments) for the distinction.
|
||||
|
||||
Please refer to the [Qdrant Cloud SLA](https://qdrant.to/sla/) for a detailed definition on uptime and support SLAs.
|
||||
|
||||
@@ -20,7 +20,7 @@ Qdrant is committed to maintaining high standards of security and compliance. We
|
||||
|
||||
All Qdrant clusters running in Qdrant Managed Cloud are isolated from each other in hardened, unprivileged containers. Each cluster is sealed off with strict network policies, ensuring that no other customer can access your data, and outbound network access is restricted to prevent data exfiltration. Paid clusters are running on their own dedicated resources to ensure stable performance and further security.
|
||||
|
||||
All storage volumes are encrypted at rest. [Premium customers](/documentation/cloud-premium/) can also bring their own encryption keys for storage volumes.
|
||||
All storage volumes are encrypted at rest. [Premium customers](/documentation/cloud-premium/) can also [bring their own encryption keys for storage volumes](/documentation/cloud/encryption/).
|
||||
|
||||
Data in transit is protected with Transport-Layer-Security (TLS). It is possible to restrict the [IP ranges](/documentation/cloud/configure-cluster/#client-ip-restrictions) that are allowed to access a cluster.
|
||||
|
||||
|
||||
@@ -0,0 +1,58 @@
|
||||
---
|
||||
title: Encryption at Rest
|
||||
short_description: "Use your own AWS KMS, GCP Cloud KMS, or Azure Key Vault key to encrypt Qdrant Managed Cloud storage volumes as a Premium customer."
|
||||
description: "Enable customer-managed encryption keys (BYOK) for Qdrant Managed Cloud storage volumes on AWS, GCP, or Azure as a Premium customer by opening a support ticket."
|
||||
weight: 27
|
||||
---
|
||||
|
||||
# Encryption at Rest
|
||||
|
||||
Qdrant Managed Cloud encrypts all storage volumes at rest by default. [Premium customers](/documentation/cloud-premium/) can also use their own cloud key management service (KMS) key for additional control over their encryption. Enabling this requires opening a support ticket. Qdrant Support provides the cloud-specific identifiers and detailed setup instructions, then configures your cluster once your key is in place.
|
||||
|
||||
## Prerequisites
|
||||
|
||||
- A [Premium Managed Cloud](/documentation/cloud-premium/) subscription
|
||||
- An existing cluster in Qdrant Cloud (create one before requesting encryption)
|
||||
- Whether your cluster is empty or contains data. We recommend starting with an empty cluster where possible.
|
||||
|
||||
## Step 1: Open a Support Ticket
|
||||
|
||||
Open a support ticket via the [Qdrant Cloud Console](https://cloud.qdrant.io/) and include:
|
||||
|
||||
- Your cluster ID
|
||||
- Your cloud provider (AWS, GCP, or Azure)
|
||||
- Whether the cluster is empty or contains data
|
||||
|
||||
Qdrant Support will respond with the cloud-specific identifier you need to complete the next step:
|
||||
|
||||
- **AWS**: Qdrant's AWS account ID
|
||||
- **GCP**: Qdrant's Compute Engine service agent email
|
||||
- **Azure**: Qdrant's Entra application ID (client ID)
|
||||
|
||||
Support will also provide detailed setup instructions.
|
||||
|
||||
## Step 2: Create Your Encryption Key
|
||||
|
||||
Follow the instructions from Qdrant Support to complete the key setup for your cloud provider.
|
||||
|
||||
### AWS
|
||||
|
||||
In AWS KMS, create a symmetric key in the same region as your cluster and grant Qdrant's account access to it using the identifier provided by Support. Copy the resulting **Key ARN**.
|
||||
|
||||
### GCP
|
||||
|
||||
In Cloud KMS, create a key ring and symmetric encrypt/decrypt key in the same region as your cluster and grant Qdrant's service agent access to it using the identifier provided by Support. Copy the resulting **Key ID**.
|
||||
|
||||
### Azure
|
||||
|
||||
Install Qdrant's Entra application into your Azure tenant using the application ID provided by Support, create a Key Vault with an encryption key in the same region as your cluster, and grant Qdrant's service principal access to it. Copy the resulting **Key URL**.
|
||||
|
||||
## Step 3: Reply to the Support Ticket
|
||||
|
||||
Send Qdrant Support your key identifier:
|
||||
|
||||
- **AWS**: Key ARN
|
||||
- **GCP**: Key ID
|
||||
- **Azure**: Key URL
|
||||
|
||||
Qdrant Support will configure encryption for your cluster.
|
||||
Reference in New Issue
Block a user