{ "id": "732c5868-a7a6-48ad-b0bb-799c9cdc1a84", "created_at": "2026-04-06T00:12:16.629078Z", "updated_at": "2026-04-10T03:24:29.234394Z", "deleted_at": null, "sha1_hash": "1a90e9246088b7afef2c7a25ec45cd4140d4d2c8", "title": "Protect the Docker daemon socket", "llm_title": "", "authors": "", "file_creation_date": "0001-01-01T00:00:00Z", "file_modification_date": "0001-01-01T00:00:00Z", "file_size": 74650, "plain_text": "Protect the Docker daemon socket\r\nBy Docker Inc\r\nPublished: 2024-09-10 ยท Archived: 2026-04-05 16:03:01 UTC\r\nBy default, Docker runs through a non-networked UNIX socket. It can also optionally communicate using SSH or\r\na TLS (HTTPS) socket.\r\nThe given USERNAME must have permissions to access the docker socket on the remote machine. Refer\r\nto manage Docker as a non-root user to learn how to give a non-root user access to the docker socket.\r\nThe following example creates a docker context to connect with a remote dockerd daemon on\r\nhost1.example.com using SSH, and as the docker-user user on the remote machine:\r\nAfter creating the context, use docker context use to switch the docker CLI to use it, and to connect to the\r\nremote engine:\r\nUse the default context to switch back to the default (local) daemon:\r\nAlternatively, use the DOCKER_HOST environment variable to temporarily switch the docker CLI to connect to\r\nthe remote host using SSH. This does not require creating a context, and can be useful to create an ad-hoc\r\nconnection with a different engine:\r\nSSH Tips\r\nFor the best user experience with SSH, configure ~/.ssh/config as follows to allow reusing a SSH connection\r\nfor multiple invocations of the docker CLI:\r\nIf you need Docker to be reachable through HTTP rather than SSH in a safe manner, you can enable TLS\r\n(HTTPS) by specifying the tlsverify flag and pointing Docker's tlscacert flag to a trusted CA certificate.\r\nIn the daemon mode, it only allows connections from clients authenticated by a certificate signed by that CA. In\r\nthe client mode, it only connects to servers with a certificate signed by that CA.\r\nUsing TLS and managing a CA is an advanced topic. Familiarize yourself with OpenSSL, x509, and\r\nTLS before using it in production.\r\nCreate a CA, server and client keys with OpenSSL\r\nReplace all instances of $HOST in the following example with the DNS name of your Docker daemon's\r\nhost.\r\nFirst, on the Docker daemon's host machine, generate CA private and public keys:\r\nhttps://docs.docker.com/engine/security/protect-access/\r\nPage 1 of 4\n\nNow that you have a CA, you can create a server key and certificate signing request (CSR). Make sure that\r\n\"Common Name\" matches the hostname you use to connect to Docker:\r\nReplace all instances of $HOST in the following example with the DNS name of your Docker daemon's\r\nhost.\r\nNext, we're going to sign the public key with our CA:\r\nSince TLS connections can be made through IP address as well as DNS name, the IP addresses need to be\r\nspecified when creating the certificate. For example, to allow connections using 10.10.10.20 and 127.0.0.1 :\r\nSet the Docker daemon key's extended usage attributes to be used only for server authentication:\r\nNow, generate the signed certificate:\r\nAuthorization plugins offer more fine-grained control to supplement authentication from mutual TLS. In addition\r\nto other information described in the above document, authorization plugins running on a Docker daemon receive\r\nthe certificate information for connecting Docker clients.\r\nFor client authentication, create a client key and certificate signing request:\r\nFor simplicity of the next couple of steps, you may perform this step on the Docker daemon's host\r\nmachine as well.\r\nTo make the key suitable for client authentication, create a new extensions config file:\r\nNow, generate the signed certificate:\r\nAfter generating cert.pem and server-cert.pem you can safely remove the two certificate signing requests\r\nand extensions config files:\r\nWith a default umask of 022, your secret keys are world-readable and writable for you and your group.\r\nTo protect your keys from accidental damage, remove their write permissions. To make them only readable by\r\nyou, change file modes as follows:\r\nCertificates can be world-readable, but you might want to remove write access to prevent accidental damage:\r\nNow you can make the Docker daemon only accept connections from clients providing a certificate trusted by\r\nyour CA:\r\nTo connect to Docker and validate its certificate, provide your client keys, certificates and trusted CA:\r\nThis step should be run on your Docker client machine. As such, you need to copy your CA certificate,\r\nyour server certificate, and your client certificate to that machine.\r\nReplace all instances of $HOST in the following example with the DNS name of your Docker daemon's\r\nhost.\r\nhttps://docs.docker.com/engine/security/protect-access/\r\nPage 2 of 4\n\nDocker over TLS should run on TCP port 2376.\r\nAs shown in the example above, you don't need to run the docker client with sudo or the docker\r\ngroup when you use certificate authentication. That means anyone with the keys can give any\r\ninstructions to your Docker daemon, giving them root access to the machine hosting the daemon. Guard\r\nthese keys as you would a root password!\r\nSecure by default\r\nIf you want to secure your Docker client connections by default, you can move the files to the .docker directory\r\nin your home directory --- and set the DOCKER_HOST and DOCKER_TLS_VERIFY variables as well (instead of\r\npassing -H=tcp://$HOST:2376 and --tlsverify on every call).\r\nDocker now connects securely by default:\r\n$ docker ps\r\nOther modes\r\nIf you don't want to have complete two-way authentication, you can run Docker in various other modes by mixing\r\nthe flags.\r\nDaemon modes\r\ntlsverify , tlscacert , tlscert , tlskey set: Authenticate clients\r\ntls , tlscert , tlskey : Do not authenticate clients\r\nClient modes\r\ntls : Authenticate server based on public/default CA pool\r\ntlsverify , tlscacert : Authenticate server based on given CA\r\ntls , tlscert , tlskey : Authenticate with client certificate, do not authenticate server based on given\r\nCA\r\ntlsverify , tlscacert , tlscert , tlskey : Authenticate with client certificate and authenticate server\r\nbased on given CA\r\nIf found, the client sends its client certificate, so you just need to drop your keys into\r\n~/.docker/{ca,cert,key}.pem . Alternatively, if you want to store your keys in another location, you can specify\r\nthat location using the environment variable DOCKER_CERT_PATH .\r\nConnecting to the secure Docker port using curl\r\nTo use curl to make test API requests, you need to use three extra command line flags:\r\nUsing certificates for repository client verification\r\nhttps://docs.docker.com/engine/security/protect-access/\r\nPage 3 of 4\n\nUse trusted images\r\nSource: https://docs.docker.com/engine/security/protect-access/\r\nhttps://docs.docker.com/engine/security/protect-access/\r\nPage 4 of 4", "extraction_quality": 1, "language": "EN", "sources": [ "MITRE" ], "references": [ "https://docs.docker.com/engine/security/protect-access/" ], "report_names": [ "protect-access" ], "threat_actors": [ { "id": "aa73cd6a-868c-4ae4-a5b2-7cb2c5ad1e9d", "created_at": "2022-10-25T16:07:24.139848Z", "updated_at": "2026-04-10T02:00:04.878798Z", "deleted_at": null, "main_name": "Safe", "aliases": [], "source_name": "ETDA:Safe", "tools": [ "DebugView", "LZ77", "OpenDoc", "SafeDisk", "TypeConfig", "UPXShell", "UsbDoc", "UsbExe" ], "source_id": "ETDA", "reports": null } ], "ts_created_at": 1775434336, "ts_updated_at": 1775791469, "ts_creation_date": 0, "ts_modification_date": 0, "files": { "pdf": "https://archive.orkl.eu/1a90e9246088b7afef2c7a25ec45cd4140d4d2c8.pdf", "text": "https://archive.orkl.eu/1a90e9246088b7afef2c7a25ec45cd4140d4d2c8.txt", "img": "https://archive.orkl.eu/1a90e9246088b7afef2c7a25ec45cd4140d4d2c8.jpg" } }