Is it possible to run docker engine without frequent sudo in a manner as secure as docker desktop?

Does running docker "engine" require sudo‘ing constantly during development? Is that what you are doing? Do you sudo -i when operating docker? Or do you set a timer on sudo? Is there a safe way to operate it more handily e.g. enabling a key/pass manager?


Having followed the Docker website’s nudge to install "desktop" (even the "engine" URL endpoint links to desktop, albeit also the engine), I have encountered a few situations making me consider using the engine only on my linux:

  • constantly being prompted a passphrase for desktop upon initializing a credential pass with GPG – ‘fixed’ with seahorse/pass.
  • requiring sudo if using engine – can be fixed with a group albeit this is risky.
  • running two docker contexts: default (engine) and desktop-linux – can be switched but still prompts sudo.
  • engine and desktop showing two different lists upon docker context ls – may be solved by creating a root user context for the same docker endpoint.

This has made me more aware of the differences, described somewhat in the docker docs and forum.

Asked By: Johan

1. Not as with docker on the host machine as root

Docker desktop is more secure (only) because it runs in a virtual machine. This means that a compromised user with docker-desktop access can only do damage to docker containers and and your docker engine, not the whole of your host system.

So a docker daemon running as root on the host system will always have this security vulnerability. That’s just the nature of it.

At least this, running as a root daemon on the host without a VirtualMachine container, this will always drop you into a root terminal:

docker run -it --rm --privileged --pid=host ubuntu:latest nsenter -at 1

2. Docker Engine (no Desktop) in a Virtual Machine

There’s nothing stopping you running docker in a virtual machine yourself, although you’d need to work through the semantics of making bind mounts work.

3. Non-root Docker

Your other option is to run docker as a non-root user. This should mean that docker itself has much less access to your system but it will add limitations to what you can run inside docker. See here:

  • Only the following storage drivers are supported:
    • overlay2 (only if running with kernel 5.11 or later, or Ubuntu-flavored kernel)
    • fuse-overlayfs (only if running with kernel 4.18 or later, and fuse-overlayfs is installed)
    • btrfs (only if running with kernel 4.18 or later, or ~/.local/share/docker is mounted with user_subvol_rm_allowed mount option)
  • Cgroup is supported only when running with cgroup v2 and systemd. See Limiting resources.
  • Following features are not supported:
    • AppArmor
    • Checkpoint
    • Overlay network
    • Exposing SCTP ports
  • To use the ping command, see Routing ping packets.
  • To expose privileged TCP/UDP ports (< 1024), see Exposing privileged ports.
  • IPAddress shown in docker inspect is namespaced inside RootlessKit’s network namespace. This means the > – IP address is not reachable from the host without nsenter-ing into the network namespace.
  • Host network (docker run –net=host) is also namespaced inside RootlessKit.
  • NFS mounts as the docker "data-root" is not supported. This limitation is not specific to rootless mode.
4. Make a dedicated, password-protected docker user

Make a dedicated user that you access with

sudo -iu docker-admin-user
Answered By: Philip Couling
Categories: Answers Tags:
Answers are sorted by their score. The answer accepted by the question owner as the best is marked with
at the top-right corner.