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.
\nThe Manage sensitive data with Docker secrets documentation is the primary reference.
\nDocker 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.
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.
\nDSE 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.
\nChoose 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.
\nReconcile 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.
\nRetire 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.
\nProposed 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.
\nVerify 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.
\nSource review completed October 29, 2026. Recheck the official documentation and deployment-specific applicability before a production change.
\n", "content_text": "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.\nSource fact: documented behavior\nThe Manage sensitive data with Docker secrets documentation is the primary reference.\nDocker 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.\nWhat the source does not establish\nThis 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.\nApplicability questions\n\nWhich services consume the current secret and at what target paths?\nWhat separate identity will name the new secret version?\nWhat application-side change makes the new credential valid?\nWhich observations authorize revoking the old service grant?\n\nDSE recommendation: separate storage, grant and application changes\nDSE 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.\nChoose 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.\nReconcile 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.\nRetire 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.\nVerification and evidence\nProposed 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.\nVerify 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.\nOfficial references\n\nManage sensitive data with Docker secrets — Docker Docs.\n\nSource review completed October 29, 2026. Recheck the official documentation and deployment-specific applicability before a production change.", "content_markdown": "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.\n\n## Source fact: documented behavior\n\nThe [Manage sensitive data with Docker secrets](https://docs.docker.com/engine/swarm/secrets/) documentation is the primary reference.\n\nDocker 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.\n\n## What the source does not establish\n\nThis 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.\n\n## Applicability questions\n\n- Which services consume the current secret and at what target paths?\n\n- What separate identity will name the new secret version?\n\n- What application-side change makes the new credential valid?\n\n- Which observations authorize revoking the old service grant?\n\n## DSE recommendation: separate storage, grant and application changes\n\nDSE 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.\n\nChoose 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.\n\nReconcile 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.\n\nRetire 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.\n\n## Verification and evidence\n\nProposed 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.\n\nVerify 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.\n\n## Official references\n\n- [Manage sensitive data with Docker secrets](https://docs.docker.com/engine/swarm/secrets/) — Docker Docs.\n\nSource review completed October 29, 2026. Recheck the official documentation and deployment-specific applicability before a production change." }, "json_ld": { "@context": "https://schema.org", "@graph": [ { "@type": "Organization", "@id": "https://dsesecurity.com/#organization", "name": "Detection Systems & Engineering", "alternateName": "DSE Security", "url": "https://dsesecurity.com/", "logo": { "@type": "ImageObject", "url": "https://update.dsesecurity.com/assets/dse-logo-20260812.png?v=1.8.20" } }, { "@type": "Organization", "@id": "https://update.dsesecurity.com/#editorial-team", "name": "DSE Security Editorial Team", "url": "https://update.dsesecurity.com/", "parentOrganization": { "@id": "https://dsesecurity.com/#organization" } }, { "@type": "WebSite", "@id": "https://update.dsesecurity.com/#website", "name": "DSE Updates", "alternateName": "DSE Security Knowledge Hub", "url": "https://update.dsesecurity.com/", "inLanguage": "en-US", "publisher": { "@id": "https://dsesecurity.com/#organization" }, "potentialAction": { "@type": "SearchAction", "target": { "@type": "EntryPoint", "urlTemplate": "https://update.dsesecurity.com/?q={search_term_string}" }, "query-input": "required name=search_term_string" } }, { "@type": "WebPage", "@id": "https://update.dsesecurity.com/updates/rotate-swarm-secrets-through-a-new-service-grant/", "url": "https://update.dsesecurity.com/updates/rotate-swarm-secrets-through-a-new-service-grant/", "isPartOf": { "@id": "https://update.dsesecurity.com/#website" }, "lastReviewed": "2026-10-29" }, { "@type": "BreadcrumbList", "@id": "https://update.dsesecurity.com/updates/rotate-swarm-secrets-through-a-new-service-grant/#breadcrumbs", "itemListElement": [ { "@type": "ListItem", "position": 1, "name": "DSE Updates", "item": "https://update.dsesecurity.com/" }, { "@type": "ListItem", "position": 2, "name": "Cybersecurity", "item": "https://update.dsesecurity.com/topic/cybersecurity/" }, { "@type": "ListItem", "position": 3, "name": "Rotate Swarm secrets through a new service grant", "item": "https://update.dsesecurity.com/updates/rotate-swarm-secrets-through-a-new-service-grant/" } ] }, { "@type": [ "Article", "TechArticle" ], "@id": "https://update.dsesecurity.com/updates/rotate-swarm-secrets-through-a-new-service-grant/#article", "identifier": "https://update.dsesecurity.com/updates/rotate-swarm-secrets-through-a-new-service-grant/", "url": "https://update.dsesecurity.com/updates/rotate-swarm-secrets-through-a-new-service-grant/", "headline": "Rotate Swarm secrets through a new service grant", "description": "Docker Swarm secret contents cannot be updated in place, and a secret cannot be removed while a service uses it.", "abstract": "Docker Swarm secret contents cannot be updated in place, and a secret cannot be removed while a service uses it. Plan the new content, service grant and application credential change separately.", "articleBody": "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.\nSource fact: documented behavior\nThe Manage sensitive data with Docker secrets documentation is the primary reference.\nDocker 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.\nWhat the source does not establish\nThis 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.\nApplicability questions\n\nWhich services consume the current secret and at what target paths?\nWhat separate identity will name the new secret version?\nWhat application-side change makes the new credential valid?\nWhich observations authorize revoking the old service grant?\n\nDSE recommendation: separate storage, grant and application changes\nDSE 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.\nChoose 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.\nReconcile 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.\nRetire 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.\nVerification and evidence\nProposed 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.\nVerify 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.\nOfficial references\n\nManage sensitive data with Docker secrets — Docker Docs.\n\nSource review completed October 29, 2026. Recheck the official documentation and deployment-specific applicability before a production change.", "datePublished": "2026-10-29T19:49:21+00:00", "dateModified": "2026-10-29T19:50:09+00:00", "mainEntityOfPage": { "@id": "https://update.dsesecurity.com/updates/rotate-swarm-secrets-through-a-new-service-grant/" }, "inLanguage": "en-US", "isAccessibleForFree": true, "author": { "@type": "Organization", "name": "DSE Security Editorial Team", "url": "https://update.dsesecurity.com/#editorial-team" }, "publisher": { "@id": "https://dsesecurity.com/#organization" }, "image": { "@type": "ImageObject", "@id": "https://update.dsesecurity.com/updates/rotate-swarm-secrets-through-a-new-service-grant/#primaryimage", "url": "https://update.dsesecurity.com/assets/editorial/cyber-defense-social-v2.jpg?v=1.8.20", "contentUrl": "https://update.dsesecurity.com/assets/editorial/cyber-defense-social-v2.jpg?v=1.8.20", "width": 1200, "height": 630, "caption": "Rotate Swarm secrets through a new service grant" }, "articleSection": [ "Cybersecurity", "IT" ], "keywords": [ "Cybersecurity", "IT", "Guide", "Advisory priority" ], "genre": "Guide", "about": [ { "@type": "Thing", "name": "Cybersecurity", "url": "https://update.dsesecurity.com/topic/cybersecurity/" }, { "@type": "Thing", "name": "IT", "url": "https://update.dsesecurity.com/topic/it/" } ], "wordCount": 543, "timeRequired": "PT3M", "publishingPrinciples": "https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/", "usageInfo": "https://update.dsesecurity.com/usage/", "copyrightHolder": { "@id": "https://dsesecurity.com/#organization" }, "copyrightNotice": "Copyright © 2026 Detection Systems & Engineering. All rights reserved.", "citation": { "@type": "CreativeWork", "name": "Docker Docs — Manage sensitive data with Docker secrets", "url": "https://docs.docker.com/engine/swarm/secrets/" } } ] } }