Migrate existing Kubernetes data when enabling at-rest encryption

Changing encryption configuration does not by itself prove that older stored objects were rewritten.

Source facts

Kubernetes uses the first encryption provider in its configured list for new writes, while matching providers are tried in order to read stored data. An identity provider first in the list provides no confidentiality protection. Checking that encryption is enabled does not establish successful migration of previously stored data. The guide’s migration procedure replaces each stored Secret with the same data to apply server-side encryption.

Source: Kubernetes documentation — Encrypting Confidential Data at Rest.

Applicability

Review API-server datastore encryption configuration and the separate migration of previously stored resources.

DSE recommendation

DSE recommends treating provider configuration, key distribution, object migration, and removal of obsolete decryption capability as distinct change stages. Keep a recovery plan and protect every required key before rewriting stored resources. Verify that all API servers use the intended configuration so one server does not write data differently from another. Record which resource types are covered and which historical objects have been verified. Do not discard an older key solely because new writes use a newer provider.

Verification

In an approved test cluster, confirm new data is stored under the intended provider and inspect a preexisting disposable object before and after migration. Verify reads through every API-server instance. Keep secret values and raw datastore output out of ordinary tickets and screenshots. Record the provider prefix and object identity through a protected review path instead of copying plaintext content. Have the key custodian approve the migration evidence before any older decryption material is retired.

Official reference

Kubernetes documentation — Encrypting Confidential Data at Rest. Reviewed October 20, 2026.