Kubernetes can update a Secret mounted as a volume while a Pod is running. The update is eventual, and the application must read the changed file. The behavior changes when the Secret is mounted with subPath. Kubernetes documents that a container using a Secret as a subPath volume mount does not receive automated Secret updates. A rotation process that updates the Secret object and waits for kubelet can therefore leave the application using the old credential indefinitely.
This matters when the old credential is a database password, API token, signing key, or webhook secret. Revoking the old value at the provider may break the application. Leaving it valid preserves the risk that prompted the rotation. The gap becomes visible only when someone compares the mounted file, the Secret object, and the provider's credential state.
Understand the two rotation paths
Without subPath, the projected or Secret volume is refreshed through the kubelet's eventual update process. Applications still need to watch or reread the file because the page cache, configuration loader, and library behavior vary. With subPath, the mount refers to a selected item and the container does not receive the same automatic update. Some workloads use this because they need a stable file name inside a container image. The convenience creates a lifecycle obligation.
The safe rotation procedure names that obligation. It should change the Secret, restart or recreate the affected Pods, verify that the new Pod sees the new content, and only then retire the old credential. Use a rollout annotation or a controller change that reliably triggers a new Pod template. Editing a Secret alone does not guarantee a restart.
Verify identity and file state
Compare a hash of the mounted file with the expected Secret data. Do not print the secret value in logs or a command transcript. Confirm which Kubernetes ServiceAccount, Pod, node, and external identity are using the credential. Check whether the old credential remains valid at the provider, and whether the provider can show a last-use time or an audit event.
For a high-impact credential, rotate in stages. Create the new value, distribute it through the controlled secret path, verify successful use from each replica, then revoke the old value. Keep a rollback window that is short enough to meet the risk decision. A rollback must not require restoring a credential that was already exposed.
Prefer designs that make staleness observable
Use a whole-volume mount when the application can tolerate the file being replaced through the standard update path. Use a controller that recreates workloads from an immutable secret version when the application cannot. The latter makes the rotation event explicit and gives the rollout a visible status.
Record the Secret resource version, Pod template revision, node identity, and provider credential version in the release process. Alert when a Pod runs longer than the maximum rotation age or when a credential remains valid after its approved retirement time. A periodic audit should compare all active Pods with the secrets they mount and flag subPath references for each.
Include emergency rotation
An emergency rotation is a different procedure from a scheduled one. Assume the old credential may already be used by an attacker. Create the replacement, deploy it, verify traffic, and revoke the old value even if some Pods fail. Restore service by recreating those Pods with the new Secret. Do not extend the old credential's lifetime because a subPath mount did not refresh.
Test the procedure in staging with a deliberately mounted subPath Secret and a provider that records credential use. The test passes only when every replica reads the new value and the old value is rejected at the provider.