{ "api_version": "1", "kind": "dse_post", "self": "https://update.dsesecurity.com/api/v1/posts/verify-the-daemon-context-when-adopting-docker-rootless-mode/", "item": { "id": "https://update.dsesecurity.com/updates/verify-the-daemon-context-when-adopting-docker-rootless-mode/", "slug": "verify-the-daemon-context-when-adopting-docker-rootless-mode", "url": "https://update.dsesecurity.com/updates/verify-the-daemon-context-when-adopting-docker-rootless-mode/", "alternate_urls": { "markdown": "https://update.dsesecurity.com/updates/verify-the-daemon-context-when-adopting-docker-rootless-mode.md", "json": "https://update.dsesecurity.com/api/v1/posts/verify-the-daemon-context-when-adopting-docker-rootless-mode/" }, "title": "Verify the daemon context when adopting Docker rootless mode", "summary": "Running a process as an ordinary container user is different from running the daemon without root.", "format": { "slug": "guide", "name": "Guide" }, "priority": { "slug": "info", "name": "Information" }, "featured": false, "image": { "theme": "network-infrastructure", "label": "Networks & infrastructure", "alt": "Resilient network core with engineered blue and gold data paths.", "card_url": "https://update.dsesecurity.com/assets/editorial/network-infrastructure-card.webp?v=1.8.20", "hero_url": "https://update.dsesecurity.com/assets/editorial/network-infrastructure-hero.webp?v=1.8.20", "social_url": "https://update.dsesecurity.com/assets/editorial/network-infrastructure-social-v2.jpg?v=1.8.20", "width": 2400, "height": 1350 }, "topics": [ { "slug": "it", "name": "IT", "url": "https://update.dsesecurity.com/topic/it/" }, { "slug": "networks-infrastructure", "name": "Networks & Infrastructure", "url": "https://update.dsesecurity.com/topic/networks-infrastructure/" } ], "author": { "name": "DSE Security Editorial Team", "url": "https://update.dsesecurity.com/#editorial-team", "type": "Organization" }, "publisher": { "name": "Detection Systems & Engineering", "url": "https://dsesecurity.com/" }, "published_at": "2026-10-20T18:15:09+00:00", "modified_at": "2026-10-20T18:34:32+00:00", "reviewed_on": "2026-10-20", "reading_minutes": 2, "word_count": 252, "potentially_affected": "Review rootless daemon identity and prerequisites, distinguishing it from user-namespace remapping and an independently running rootful daemon.", "dse_recommendation": "DSE recommends inventorying required host integrations before moving a workload to rootless operation.", "primary_source": { "name": "Docker documentation — Rootless mode", "url": "https://docs.docker.com/engine/security/rootless/", "published_on": null, "authority": "docs.docker.com" }, "publishing_principles": "https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/", "usage_info": "https://update.dsesecurity.com/usage/", "copyright_notice": "Copyright © 2026 Detection Systems & Engineering. All rights reserved.", "content_html": "

Running a process as an ordinary container user is different from running the daemon without root.

\n

Source facts

\n

Docker rootless mode runs both the daemon and containers as a non-root user. It executes them inside a user namespace. Docker distinguishes this from userns-remap, where the daemon itself remains privileged. Its prerequisites include newuidmap, newgidmap and subordinate UID/GID allocations.

\n

Source: Docker documentation — Rootless mode.

\n

Applicability

\n

Review rootless daemon identity and prerequisites, distinguishing it from user-namespace remapping and an independently running rootful daemon.

\n

DSE recommendation

\n

DSE recommends inventorying required host integrations before moving a workload to rootless operation. Record the service-owning user, daemon endpoint, storage location, startup behavior, and administrative access path. Review any feature that previously depended on host privileges rather than compensating by adding broad exceptions. Make the active Docker context visible to administrators so commands do not accidentally target another daemon. Treat non-root execution as one defense in a broader image, secret, networking, and patching design.

\n

Verification

\n

On an approved test host, inspect the effective daemon user and active endpoint, then exercise the application’s required storage and networking functions. Confirm automatic service startup and recovery under the intended user context. Verify that unsupported requirements are identified before production migration rather than discovered during an outage. Retain the endpoint and user identity with the test output. Ask another administrator to target the intended daemon explicitly and inspect its workloads, so a working command against a different context cannot close the migration check.

\n

Official reference

\n

Docker documentation — Rootless mode. Reviewed October 20, 2026.

", "content_text": "Running a process as an ordinary container user is different from running the daemon without root.\nSource facts\nDocker rootless mode runs both the daemon and containers as a non-root user. It executes them inside a user namespace. Docker distinguishes this from userns-remap, where the daemon itself remains privileged. Its prerequisites include newuidmap, newgidmap and subordinate UID/GID allocations.\nSource: Docker documentation — Rootless mode.\nApplicability\nReview rootless daemon identity and prerequisites, distinguishing it from user-namespace remapping and an independently running rootful daemon.\nDSE recommendation\nDSE recommends inventorying required host integrations before moving a workload to rootless operation. Record the service-owning user, daemon endpoint, storage location, startup behavior, and administrative access path. Review any feature that previously depended on host privileges rather than compensating by adding broad exceptions. Make the active Docker context visible to administrators so commands do not accidentally target another daemon. Treat non-root execution as one defense in a broader image, secret, networking, and patching design.\nVerification\nOn an approved test host, inspect the effective daemon user and active endpoint, then exercise the application’s required storage and networking functions. Confirm automatic service startup and recovery under the intended user context. Verify that unsupported requirements are identified before production migration rather than discovered during an outage. Retain the endpoint and user identity with the test output. Ask another administrator to target the intended daemon explicitly and inspect its workloads, so a working command against a different context cannot close the migration check.\nOfficial reference\nDocker documentation — Rootless mode. Reviewed October 20, 2026.", "content_markdown": "Running a process as an ordinary container user is different from running the daemon without root.\n\n## Source facts\n\nDocker rootless mode runs both the daemon and containers as a non-root user. It executes them inside a user namespace. Docker distinguishes this from userns-remap, where the daemon itself remains privileged. Its prerequisites include newuidmap, newgidmap and subordinate UID/GID allocations.\n\nSource: [Docker documentation — Rootless mode](https://docs.docker.com/engine/security/rootless/).\n\n## Applicability\n\nReview rootless daemon identity and prerequisites, distinguishing it from user-namespace remapping and an independently running rootful daemon.\n\n## DSE recommendation\n\nDSE recommends inventorying required host integrations before moving a workload to rootless operation. Record the service-owning user, daemon endpoint, storage location, startup behavior, and administrative access path. Review any feature that previously depended on host privileges rather than compensating by adding broad exceptions. Make the active Docker context visible to administrators so commands do not accidentally target another daemon. Treat non-root execution as one defense in a broader image, secret, networking, and patching design.\n\n## Verification\n\nOn an approved test host, inspect the effective daemon user and active endpoint, then exercise the application’s required storage and networking functions. Confirm automatic service startup and recovery under the intended user context. Verify that unsupported requirements are identified before production migration rather than discovered during an outage. Retain the endpoint and user identity with the test output. Ask another administrator to target the intended daemon explicitly and inspect its workloads, so a working command against a different context cannot close the migration check.\n\n## Official reference\n\n[Docker documentation — Rootless mode](https://docs.docker.com/engine/security/rootless/). Reviewed October 20, 2026." }, "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/verify-the-daemon-context-when-adopting-docker-rootless-mode/", "url": "https://update.dsesecurity.com/updates/verify-the-daemon-context-when-adopting-docker-rootless-mode/", "isPartOf": { "@id": "https://update.dsesecurity.com/#website" }, "lastReviewed": "2026-10-20" }, { "@type": "BreadcrumbList", "@id": "https://update.dsesecurity.com/updates/verify-the-daemon-context-when-adopting-docker-rootless-mode/#breadcrumbs", "itemListElement": [ { "@type": "ListItem", "position": 1, "name": "DSE Updates", "item": "https://update.dsesecurity.com/" }, { "@type": "ListItem", "position": 2, "name": "IT", "item": "https://update.dsesecurity.com/topic/it/" }, { "@type": "ListItem", "position": 3, "name": "Verify the daemon context when adopting Docker rootless mode", "item": "https://update.dsesecurity.com/updates/verify-the-daemon-context-when-adopting-docker-rootless-mode/" } ] }, { "@type": [ "Article", "TechArticle" ], "@id": "https://update.dsesecurity.com/updates/verify-the-daemon-context-when-adopting-docker-rootless-mode/#article", "identifier": "https://update.dsesecurity.com/updates/verify-the-daemon-context-when-adopting-docker-rootless-mode/", "url": "https://update.dsesecurity.com/updates/verify-the-daemon-context-when-adopting-docker-rootless-mode/", "headline": "Verify the daemon context when adopting Docker rootless mode", "description": "Running a process as an ordinary container user is different from running the daemon without root.", "abstract": "Running a process as an ordinary container user is different from running the daemon without root.", "articleBody": "Running a process as an ordinary container user is different from running the daemon without root.\nSource facts\nDocker rootless mode runs both the daemon and containers as a non-root user. It executes them inside a user namespace. Docker distinguishes this from userns-remap, where the daemon itself remains privileged. Its prerequisites include newuidmap, newgidmap and subordinate UID/GID allocations.\nSource: Docker documentation — Rootless mode.\nApplicability\nReview rootless daemon identity and prerequisites, distinguishing it from user-namespace remapping and an independently running rootful daemon.\nDSE recommendation\nDSE recommends inventorying required host integrations before moving a workload to rootless operation. Record the service-owning user, daemon endpoint, storage location, startup behavior, and administrative access path. Review any feature that previously depended on host privileges rather than compensating by adding broad exceptions. Make the active Docker context visible to administrators so commands do not accidentally target another daemon. Treat non-root execution as one defense in a broader image, secret, networking, and patching design.\nVerification\nOn an approved test host, inspect the effective daemon user and active endpoint, then exercise the application’s required storage and networking functions. Confirm automatic service startup and recovery under the intended user context. Verify that unsupported requirements are identified before production migration rather than discovered during an outage. Retain the endpoint and user identity with the test output. Ask another administrator to target the intended daemon explicitly and inspect its workloads, so a working command against a different context cannot close the migration check.\nOfficial reference\nDocker documentation — Rootless mode. Reviewed October 20, 2026.", "datePublished": "2026-10-20T18:15:09+00:00", "dateModified": "2026-10-20T18:34:32+00:00", "mainEntityOfPage": { "@id": "https://update.dsesecurity.com/updates/verify-the-daemon-context-when-adopting-docker-rootless-mode/" }, "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/verify-the-daemon-context-when-adopting-docker-rootless-mode/#primaryimage", "url": "https://update.dsesecurity.com/assets/editorial/network-infrastructure-social-v2.jpg?v=1.8.20", "contentUrl": "https://update.dsesecurity.com/assets/editorial/network-infrastructure-social-v2.jpg?v=1.8.20", "width": 1200, "height": 630, "caption": "Verify the daemon context when adopting Docker rootless mode" }, "articleSection": [ "IT", "Networks & Infrastructure" ], "keywords": [ "IT", "Networks & Infrastructure", "Guide", "Information priority" ], "genre": "Guide", "about": [ { "@type": "Thing", "name": "IT", "url": "https://update.dsesecurity.com/topic/it/" }, { "@type": "Thing", "name": "Networks & Infrastructure", "url": "https://update.dsesecurity.com/topic/networks-infrastructure/" } ], "wordCount": 252, "timeRequired": "PT2M", "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 documentation — Rootless mode", "url": "https://docs.docker.com/engine/security/rootless/" } } ] } }