Encryption protects two different things
Kubernetes backups can expose Secrets, service-account tokens, registry credentials, database passwords, TLS certificates, RBAC assignments and persistent-volume data. Encryption can reduce the impact of lost media, exposed buckets, stolen disks or unauthorized repository access — but it also creates a new recovery dependency. An encrypted backup can be complete and structurally healthy while remaining unusable, because the repository password was lost, the encryption configuration disappeared with the control plane, or the KMS key was deleted.
A sound strategy protects two things at once:
Encryption may apply at several layers — API data before it is stored in etcd, etcd snapshot files, Velero backup data, object storage, persistent-volume snapshots, or database-native backup files. These layers are not interchangeable; a complete design typically uses several of them together.
Encryption in transit versus at rest
Encryption in transit protects backup data while it moves between Kubernetes and object storage, node agents and backup repositories, or a recovery cluster and S3-compatible storage. TLS is commonly used for these connections, but protection stops when the transfer ends — the destination still needs appropriate encryption at rest and access control.
Encryption at rest protects stored information — etcd, etcd snapshots, Kubernetes-resource backup files, persistent-volume backups, object-storage buckets, and archive tiers. A mature strategy evaluates both.
Kubernetes Secrets are not automatically encrypted in etcd
Kubernetes Secret values are base64 encoded, but encoding is not encryption.
Current Kubernetes documentation warns that Secrets are stored unencrypted in etcd by default unless API-data encryption is configured. Anyone with appropriate API or direct etcd access may be able to retrieve them.
This has direct backup implications — an etcd snapshot may contain readable Secret data when API encryption at rest isn't enabled, the resource wasn't covered by the encryption policy, or data existed before encryption was enabled and was never rewritten. Protect etcd snapshots as highly sensitive backup data.
Local keys versus KMS v2
Kubernetes encryption configuration uses an ordered provider list — the first provider is normally used for new writes, but older providers may remain necessary to decrypt older data. Removing an old provider too early can make historical etcd data and old snapshots unreadable. Do not treat key rotation as immediate key destruction.
What Velero encrypts — and what it doesn't
Velero protection can contain several different data categories, and they may use different encryption mechanisms.
Velero creates a velero-repo-credentials Secret containing the repository password. The password can be changed before the first backup creates a repository — changing it afterward can prevent Velero from accessing older repositories.
This makes the repository password a permanent recovery dependency for existing backups. Do not keep the only copy inside Kubernetes — the source cluster may be unavailable during recovery. Maintain one operational copy for Velero and one protected emergency copy stored independently.
Object storage encryption models
Confirm supported encryption modes, KMS integration, multipart-upload encryption, replication behaviour and key rotation for the specific S3-compatible provider — S3 compatibility does not guarantee identical encryption behaviour across vendors.
Encryption, immutability and integrity solve different problems
Protects confidentiality. An encrypted backup can still be deleted.
Protects a recovery point from modification or deletion for a period. An immutable backup may still be readable by an authorized identity.
Proves the backup is complete, undamaged and application-consistent — encryption proves none of this.
A resilient Kubernetes backup typically needs all three, plus historical retention, separate credentials and offsite storage. See the 3-2-1-1-0 backup rule for the broader framework.
Key inventory, storage, rotation and retirement
A Kubernetes recovery point may depend on several simultaneous keys — the API-server encryption key, an external KMS key, the Velero repository password, an object-storage customer-managed key, a database backup key, and a guest-OS recovery key for Kubernetes-hosted VMs. The effective backup retention is limited by the shortest-lived required key: a backup retained for one year is unusable when its decryption key expires after three months.
Where not to store the only key
Rotation and retirement
Key rotation introduces a new key for future encryption — it may not automatically re-encrypt historical backups. Before rotating, determine which backups still use the old key and how long it must remain available. Destroy the final key only after confirming no required backup, archive, cross-region copy or legal hold still depends on it — destroying the final key is effectively irreversible data deletion.
Cross-cluster, cross-cloud and air-gapped recovery
A replacement cluster may differ in cloud account, region, KMS, Kubernetes version, or storage provider. Object-storage access alone does not prove decryptability — test whether the replacement cluster can actually reach the KMS, the API encryption configuration, database keys and required certificates.
An air-gapped recovery environment may lack access to cloud KMS or external identity entirely — prepare offline key copies, approved recovery software and a manual key-import procedure, and test these materials before relying on them.
Six levels of encrypted-backup testing
Common Kubernetes backup-encryption mistakes
Kubernetes Secret values are encoded, not encrypted, by base64. Configure appropriate API-data encryption and backup protection.
Snapshot files may expose sensitive cluster state. Encrypt and restrict them separately.
The etcd data may remain unreadable. Keep protected independent copies.
Cluster loss removes both the backup client and the decryption path. Maintain external recovery copies.
Older repositories may become inaccessible. Plan password changes before repository creation.
Historical backups may still depend on it. Align key retention with backup retention.
Identity failure may block recovery. Use the emergency recovery account.
Encrypted backups can still be deleted, and encrypted data can still be incomplete or corrupted. Restore and validate it.
Documentation systems may not be appropriate secret stores. Record identifiers and protected locations only.
Old recovery points may silently become unusable. Restore an older point after rotation.
Kubernetes backup-encryption checklist
0 / 26Frequently asked questions
Sensitive, offsite, hosted, cloud, removable or shared-infrastructure backups should be evaluated for encryption according to their exposure and recovery requirements.
No. Current Kubernetes documentation warns that Secrets are stored unencrypted in etcd by default unless API-data encryption is configured.
No. Base64 is an encoding format and does not provide confidentiality.
It encrypts selected API resources before they are stored in etcd.
KMS v2 is Kubernetes' stable envelope-encryption integration for protecting API data using data-encryption keys secured by a key-encryption key managed through a KMS.
No. Persistent-volume data requires storage-level, filesystem, application or backup-repository encryption.
Velero backup components use different mechanisms. Kubernetes-resource data and provider snapshots may rely on storage-provider encryption, while filesystem backup and CSI data movement use repositories protected by repository credentials. Confirm the installed version and provider behaviour.
It is the credential used by Velero's filesystem backup or snapshot data-movement repositories. It must remain available for every dependent recovery point.
It can be configured before the first repository is created. Velero documentation warns that changing it after repository creation can prevent access to older backups.
Every backup or API resource that still depends on the key may become permanently unreadable.
It protects confidentiality. It does not prevent backup deletion, corruption, malicious configuration or restoration of compromised data.
Restore Kubernetes resources and persistent data into an isolated replacement cluster using independently protected credentials and keys, then validate the complete application.
Protect confidentiality and preserve the recovery path
Kubernetes backup encryption should prevent unauthorized access without creating an unrecoverable archive. Encrypt sensitive API data, protect etcd snapshots, encrypt backup transfers and repositories, and understand which Velero data is protected by the storage provider versus a repository password.
Keep operational and emergency recovery materials separate from the source cluster, align key retention with backup retention, and then restore a historical encrypted recovery point into a replacement cluster without using the original administrator, node, or only local key copy. Encryption succeeds only when unauthorized parties cannot read the backup and authorized recovery teams still can.