Docker Desktop Security: Enforce Sign In, Isolation and Locked Settings

Docker Desktop gives every developer a local container engine that can pull any image, mount the Docker socket and expose the engine API, so an unmanaged fleet of laptops is a fleet of unmanaged hosts running untrusted code. Docker's Hardened Docker Desktop features let an organisation require corporate sign-in, isolate containers from the Docker Desktop VM, lock settings and restrict which registries developers can reach. This guide explains how identity, administration, tokens, logging and those controls fit together, with the exact settings keys and rollout order from Docker's documentation. It is written for endpoint, platform and security engineers rolling Docker Desktop out across an enterprise; image, Compose and engine hardening are covered in the Docker and Docker Compose Security Guide.

This is an independent guide from NHI Mgmt Group, based on Docker's public documentation as of November 2026. It is not sponsored or reviewed by Docker. Product features change, so confirm settings against Docker's current documentation.

Key takeaways

• Sign-in enforcement comes first. Settings Management, Registry Access Management and other organisation policies only take effect once users sign in with an account in your organisation, so enforce sign-in before anything else.
• Enhanced Container Isolation changes the threat model. ECI runs containers with the Sysbox runtime inside per-container Linux user namespaces, so container root is not root in the Docker Desktop VM, and it blocks Docker socket mounts unless you allow them.
• A setting is only enforced when it is locked. In admin-settings.json or a Docker Home policy, "locked": true stops users changing a value; false is just a default.
• Registry Access Management is DNS-level filtering. It restricts pulls, pushes and builds to approved registry hostnames, covers up to 100 registries and can take up to 24 hours to apply.
• Patch cadence is a control. Docker publishes Docker Desktop CVEs with fixed versions; track them and keep the fleet on a supported release.

How identity and access work in Docker Desktop

Docker Desktop runs the Docker Engine inside a Linux VM (or WSL 2 on Windows). Whoever uses the desktop controls that engine. Organisation control is attached to the Docker account the user signs in with, which is why the Hardened Docker Desktop features, listed by Docker as Docker Business features, depend on sign-in.

Docker supports several ways to enforce sign-in, all keyed on the organisation namespace (not its display name) in allowedOrgs, ALLOWEDORG or --allowed-org:

When sign-in is enforced, Docker Desktop prompts users to sign in with their work email; users signed in with accounts outside the organisation are signed out. The Docker CLI is blocked for commands that reach the engine, such as docker run, docker pull and docker build, while docker version, docker info and docker login still work. Changes apply at the next Docker Desktop restart, as it does not poll for new configuration while running. Sign-in enforcement controls whether users must authenticate; SSO enforcement, a separate feature, controls how. Use both so that joiners and leavers follow your identity provider.

Admin roles and privileged access

Two kinds of administrator matter: organisation administrators in Docker Home, who define policies, and local administrators on each machine, who can alter the files that enforce them.

• Docker Home policies: organisation admins create settings policies under Docker Desktop > Settings Management and registry rules under Docker Desktop > Registry Access. Policies take effect only after the organisation's domain is verified and sign-in is enforced.
• Precedence: user-specific policies override the organisation default policy, which overrides a local admin-settings.json; macOS configuration profiles for proxy settings come last. Know which layer is authoritative before you troubleshoot.
• Local file protection: admin-settings.json lives at /Library/Application Support/com.docker.docker/admin-settings.json on macOS, C:\ProgramData\DockerDesktop\admin-settings.json on Windows and /usr/share/docker-desktop/admin-settings.json on Linux. Docker advises a protected directory and MDM distribution. A developer with local admin rights can edit or delete it, so pair it with Docker Home policies and endpoint controls on local admin.
• Installer flag: the --admin-settings installer flag on macOS and Windows creates the file at install time, which suits scripted deployment.

Removing standing local admin from developer machines is the control that makes all of this hold. See the Developer Workstation and IDE Security Guide.

Integrations, API tokens and service accounts

Docker Desktop holds and uses several machine credentials, and each needs an owner and a rotation plan.

Docker Hub personal and organisation tokens have their own lifecycle; see the Docker Hub Tokens Security Guide. Never bake registry or cloud credentials into images built locally; the general approach is in the Secrets Management Guide.

Docker socket mount exceptions

With ECI on, Docker socket mounts are blocked. Administrators can allow exceptions under enhancedContainerIsolation.dockerSocketMount:

• imageList.images: allowed images as <image_name>[:<tag>] (no tag means :latest, * means any tag) or <image_name>@<digest> for one exact image. Docker's example lists docker.io/testcontainers/ryuk:*, docker.io/localstack/localstack:* and docker:cli.
• imageList.allowDerivedImages: whether images built from an allowed image also qualify. Leaving it off is stricter, because anyone can build a derived image.
• commandList: type allow or deny plus commands; Docker's example denies push and build through the mounted socket.

Prefer digests for the highest-risk tools and review the list as tools are added, because every entry is a container that can drive the engine.

Enhanced Container Isolation and network controls

ECI is the core technical control. It uses Sysbox, a security-enhanced fork of runc, for containers started with docker run or docker create, ignores the --runtime flag, and maps container root to an unprivileged user with a separate mapping per container. Privileged containers still run but are contained: Docker's example is a privileged container failing with "Operation not permitted" when it tries to change Docker Desktop's network configuration. Docker-in-Docker and Kubernetes-in-Docker continue to work. ECI also protects administrator configuration such as Registry Access Management and Settings Management controls.

To confirm ECI on an endpoint, run a container that prints /proc/self/uid_map: with ECI, root maps to a high unprivileged range such as 100000; without it, root maps to 0 across the full range. For runtime controls beyond the desktop, see the Container Runtime Security Guide.

Logging and detection

Most Docker Desktop telemetry for security purposes comes from the endpoint and from Docker Home rather than a central audit stream, so plan detection around your EDR, MDM and proxy.

For ATT&CK mapping, the risks ECI and RAM address are T1611 Escape to Host, T1610 Deploy Container and T1204.003 Malicious Image.

Metrics:

• Percentage of Docker Desktop installs with sign-in enforced and signed in to the organisation.
• Percentage of installs with ECI locked on, verified by the user namespace check.
• Devices running a Docker Desktop version below the latest security fix, and median days to patch.
• Number of socket mount exceptions, and the share pinned by digest.
• Registry Access Management allow list size and the date of its last review.

Hardening baseline

1. Verify the domain and enforce sign-in with the method that suits each platform, scoped to your organisation namespace, and enforce SSO.
2. Pilot a settings policy in Docker Home for a test group (a user-specific policy) before changing the organisation default.
3. Turn on and lock ECI: set "enhancedContainerIsolation": {"value": true, "locked": true} with "configurationFileVersion": 2, or "Always enabled" in Docker Home. Tell users to remove existing containers and fully quit and relaunch, because a menu restart is not enough.
4. Add socket mount exceptions only for tools that fail in the pilot, by digest where practical, with allowDerivedImages off unless needed.
5. Lock risky settings: exposeDockerAPIOnTCP2375 to false, proxy and containersProxy to corporate values, and review the Settings reference for other lockable controls such as extensions and Kubernetes.
6. Enable Registry Access Management with your internal registries, required mirrors and redirect domains. Expect up to 24 hours for changes, or have users sign out and in.
7. Roll out in rings and roll back by removing the policy or setting locked to false, which turns enforced values back into defaults.
8. Patch continuously: monitor Docker's security announcements and push updates through MDM.

Choosing between Docker Home policies and the JSON file

• Docker Home policies: central, auditable in one place and higher in precedence than the local file. They need domain verification and enforced sign-in, and users only receive changes after quitting, relaunching and signing in.
• admin-settings.json: works for scripted installs and offline images, and deploying it also enforces sign-in. It depends on file protection and MDM to stay in place, and on existing installs an unlocked value is ignored if the user already customised it.
• Both: many fleets deploy the file as a floor through MDM and manage day-to-day policy in Docker Home, so a deleted file still leaves organisation policy in force after sign-in.

Small organisations can start with enforced sign-in, ECI and a locked engine API through admin-settings.json; large ones should manage policies centrally in Docker Home and use MDM to deploy sign-in enforcement and verify compliance.

Common misconfigurations

• Unlocked settings: admin-settings.json deployed with "locked": false, so values are defaults that users can change, and on existing installs ignored if the user already customised them.
• Policies without sign-in: Registry Access Management or settings policies configured in Docker Home while sign-in is not enforced, so they never apply to users who stay signed out or use personal accounts.
• ECI on, old containers kept: containers created before ECI was enabled are not protected.
• Broad socket exceptions: a wildcard tag plus allowDerivedImages: true on a general-purpose image lets any developer build an image that drives the engine.
• Missing redirect domains or Windows proxy: Registry Access Management breaks pulls when redirect hosts are not allowed, prompting admins to disable it, or leaves Windows containers unrestricted.
• Stale versions: apply Docker Desktop security updates promptly and follow the Docker security announcements; devices left on old versions miss those fixes.

Framework mapping

Practitioner checklist

• Verify your domain and enforce sign-in on every platform with the organisation namespace.
• Enforce SSO so Docker accounts follow joiner and leaver processes.
• Lock ECI on and confirm it with the /proc/self/uid_map check.
• Keep socket mount exceptions minimal and pinned by digest where possible.
• Lock exposeDockerAPIOnTCP2375 to false and lock proxy settings.
• Enable Registry Access Management with all required registries and redirect domains.
• Protect admin-settings.json and remove standing local admin from developers.
• Track Docker Desktop security announcements and patch within your SLA.
• Treat diagnostics bundles as sensitive data.

Standards and references

• Docker Docs: Hardened Docker Desktop
• Docker Docs: Enhanced Container Isolation
• Docker Docs: Configure advanced ECI settings
• Docker Docs: Settings Management
• Docker Docs: Enforce sign-in for Docker Desktop
• Docker Docs: Registry Access Management
• Docker Docs: Docker security announcements
• NIST: SP 800-53 Rev. 5

Related NHI Mgmt Group resources: Docker and Docker Compose Security Guide · Docker Hub Tokens Security Guide · Developer Workstation and IDE Security Guide · Container Runtime Security Guide