Rotate Swarm secrets through a new service grant

Bottom line: Plan secret rotation as a service and application transition rather than a file replacement. Keep the old and new secret identities, consumer paths and application acceptance checks together before changing access.

Source fact: documented behavior

The Manage sensitive data with Docker secrets documentation is the primary reference.

Docker says existing Swarm secret contents cannot be updated, and a secret in use by a service cannot be removed; service access can instead be granted or revoked through docker service update. The rotation example grants the MySQL service both secret versions under different target filenames, and the guide documents service updates redeploying tasks. In that example, making the new secret available does not change the MySQL password; the database password is changed separately before the WordPress consumer update.

What the source does not establish

This article reviews the Swarm secret transition, not a universal database rotation script or a zero-downtime guarantee. It does not prescribe the tutorial’s database commands for another application. Keep the application’s supported credential-change and rollback procedure under its owner’s review.

Applicability questions

• Which services consume the current secret and at what target paths?
• What separate identity will name the new secret version?
• What application-side change makes the new credential valid?
• Which observations authorize revoking the old service grant?

DSE recommendation: separate storage, grant and application changes

DSE recommends a transition sheet with the old secret name, new secret name, each service and its intended target path. Reference protected secret material without placing values in the sheet. Have the application owner identify the exact credential authority and the consumer update that must accompany the Swarm change.

Choose the naming and access transition before creating the new version. Preserve the managed service definition and identify the intended period of any old/new coexistence. Do not remove a consumer’s existing access merely to free a name for reuse. Keep task replacement and the application’s availability requirement visible in the plan.

Reconcile the service-visible path with the application’s actual input mechanism. Ask the application owner whether it reads the credential at startup, reloads it or copies it into another configuration. Obtain that behavior from its own primary documentation before selecting the update sequence. A mounted new file is not the application acceptance observation.

Retire the old grant only after the approved application checks. Review any remaining consumers and record the decision before removing the old secret through the documented lifecycle. Keep an unresolved application failure open instead of retrying several grant and database changes without an attributable sequence.

Verification and evidence

Proposed verification, not performed: use an isolated Swarm service and disposable application credentials under the application’s supported test procedure. Record the old and new secret identities and target paths, then compare actual service access with the transition sheet after each approved update.

Verify the application’s new authentication path separately, including the intended old-credential rejection when that is an approved requirement. Retain sanitized task, service and application observations without recording secret values. Reconcile remaining old-secret consumers before cleanup. Report only the tested transition and keep any interruption or rollback result as an actual observation, not a promised outcome.

Official references

• Manage sensitive data with Docker secrets — Docker Docs.

Source review completed October 29, 2026. Recheck the official documentation and deployment-specific applicability before a production change.