etcd Secrets Encryption at Rest
Understanding CoreWeave CKS cluster secrets encryption at rest
CoreWeave provides encryption at rest for etcd data in CoreWeave Kubernetes Service (CKS) clusters using a KMS-backed Vault setup. For new CKS clusters created after June 24, 2025, this feature is enabled by default and requires no action from you.
For existing CKS clusters created on or before June 24, 2025, you need to rotate your existing Kubernetes Secrets once. After that, CoreWeave handles the entire lifecycle securely and transparently.
In Kubernetes, Secrets are stored unencrypted in etcd by default. Encryption at rest is typically configured manually using a Key Management Service (KMS) provider.
With CKS, CoreWeave sets up and maintains this for you automatically.
Rotate secrets in existing clusters
If your CKS cluster was created before June 24, 2025, your existing Secrets may not yet be encrypted. To ensure full encryption coverage, you'll need to replace the existing Secrets once. Any new Secrets you create going forward will be encrypted automatically.
To rotate your Secrets in place, run:
kubectl get secrets --all-namespaces -o json | kubectl replace -f -
Core components of the encryption system
This section gives a behind-the-scenes look at how this encryption system works, without expecting you to manage or interact with any of it directly.
Vault-based encryption service
Each CKS tenant environment includes a dedicated Vault instance, deployed locally within the Kubernetes cluster to manage encryption keys. This service is:
- Deployed as a highly available
StatefulSetwith internal Raft storage - Unsealed and authenticated automatically via a secure link to CoreWeave's central Vault
- Backed up and restored (if needed) automatically
This setup ensures tenant clusters benefit from secure, isolated key management with minimal blast radius and no operational burden.
Vault manager
A custom controller (Vault Manager) handles the lifecycle of the Vault instance. It
- bootstraps and unseals Vault using CoreWeave's upstream Vault via auto-unseal (transit),
- restores backups on redeployments (if enabled), and
- backs up Vault data on a schedule to ensure recoverability.
Kubernetes integration
The Kubernetes API server in your CKS cluster is configured to use Vault as a KMS provider for etcd. It
- uses the Vault transit engine for envelope encryption and
- authenticates using Vault's Kubernetes auth method.
Keys are securely managed and stored centrally, outside of the cluster.
This configuration means that objects like Secrets are encrypted at rest inside etcd using strong, tenant-isolated encryption keys.
TLS and certificate management
Vault uses mutual TLS to secure communication between its components and Kubernetes. All certificates are automatically issued by an internal CA via cert-manager. This ensures end-to-end encrypted communication within the Control Plane.
Comparison to upstream Kubernetes
While Kubernetes offers encryption at rest as an optional config, CoreWeave enables it by default. Your CKS clusters have Secrets encryption at rest via Vault, with none of the operational burden.
| Concept | Upstream Kubernetes | CoreWeave CKS |
|---|---|---|
| KMS provider | You choose and configure it (e.g. Vault, AWS KMS) | CoreWeave pre-configures Vault |
| Who manages keys | You do | CoreWeave does |
| Plugin config | You write and deploy it manually | CoreWeave provisions and injects it automatically |
| Encryption scope | You choose what to encrypt | CoreWeave encrypts Secrets by default |
| Key rotation, unseal, backup | Manual setup and maintenance | Automated by Vault Manager + TVM |