github.com/nf/docker@v1.8.1/docs/articles/https.md (about)

     1  <!--[metadata]>
     2  +++
     3  title = "Protect the Docker daemon socket"
     4  description = "How to setup and run Docker with HTTPS"
     5  keywords = ["docker, docs, article, example, https, daemon, tls, ca,  certificate"]
     6  [menu.main]
     7  parent = "smn_administrate"
     8  weight = 5
     9  +++
    10  <![end-metadata]-->
    11  
    12  # Protect the Docker daemon socket
    13  
    14  By default, Docker runs via a non-networked Unix socket. It can also
    15  optionally communicate using a HTTP socket.
    16  
    17  If you need Docker to be reachable via the network in a safe manner, you can
    18  enable TLS by specifying the `tlsverify` flag and pointing Docker's
    19  `tlscacert` flag to a trusted CA certificate.
    20  
    21  In the daemon mode, it will only allow connections from clients
    22  authenticated by a certificate signed by that CA. In the client mode,
    23  it will only connect to servers with a certificate signed by that CA.
    24  
    25  > **Warning**:
    26  > Using TLS and managing a CA is an advanced topic. Please familiarize yourself
    27  > with OpenSSL, x509 and TLS before using it in production.
    28  
    29  > **Warning**:
    30  > These TLS commands will only generate a working set of certificates on Linux.
    31  > Mac OS X comes with a version of OpenSSL that is incompatible with the
    32  > certificates that Docker requires.
    33  
    34  ## Create a CA, server and client keys with OpenSSL
    35  
    36  > **Note**: replace all instances of `$HOST` in the following example with the
    37  > DNS name of your Docker daemon's host.
    38  
    39  First generate CA private and public keys:
    40  
    41      $ openssl genrsa -aes256 -out ca-key.pem 4096
    42      Generating RSA private key, 4096 bit long modulus
    43      ............................................................................................................................................................................................++
    44      ........++
    45      e is 65537 (0x10001)
    46      Enter pass phrase for ca-key.pem:
    47      Verifying - Enter pass phrase for ca-key.pem:
    48      $ openssl req -new -x509 -days 365 -key ca-key.pem -sha256 -out ca.pem
    49      Enter pass phrase for ca-key.pem:
    50      You are about to be asked to enter information that will be incorporated
    51      into your certificate request.
    52      What you are about to enter is what is called a Distinguished Name or a DN.
    53      There are quite a few fields but you can leave some blank
    54      For some fields there will be a default value,
    55      If you enter '.', the field will be left blank.
    56      -----
    57      Country Name (2 letter code) [AU]:
    58      State or Province Name (full name) [Some-State]:Queensland
    59      Locality Name (eg, city) []:Brisbane
    60      Organization Name (eg, company) [Internet Widgits Pty Ltd]:Docker Inc
    61      Organizational Unit Name (eg, section) []:Sales
    62      Common Name (e.g. server FQDN or YOUR name) []:$HOST
    63      Email Address []:Sven@home.org.au
    64  
    65  Now that we have a CA, you can create a server key and certificate
    66  signing request (CSR). Make sure that "Common Name" (i.e., server FQDN or YOUR
    67  name) matches the hostname you will use to connect to Docker:
    68  
    69  > **Note**: replace all instances of `$HOST` in the following example with the
    70  > DNS name of your Docker daemon's host.
    71  
    72      $ openssl genrsa -out server-key.pem 4096
    73      Generating RSA private key, 4096 bit long modulus
    74      .....................................................................++
    75      .................................................................................................++
    76      e is 65537 (0x10001)
    77      $ openssl req -subj "/CN=$HOST" -sha256 -new -key server-key.pem -out server.csr
    78  
    79  Next, we're going to sign the public key with our CA:
    80  
    81  Since TLS connections can be made via IP address as well as DNS name, they need
    82  to be specified when creating the certificate. For example, to allow connections
    83  using `10.10.10.20` and `127.0.0.1`:
    84  
    85      $ echo subjectAltName = IP:10.10.10.20,IP:127.0.0.1 > extfile.cnf
    86  
    87      $ openssl x509 -req -days 365 -sha256 -in server.csr -CA ca.pem -CAkey ca-key.pem \
    88        -CAcreateserial -out server-cert.pem -extfile extfile.cnf
    89      Signature ok
    90      subject=/CN=your.host.com
    91      Getting CA Private Key
    92      Enter pass phrase for ca-key.pem:
    93  
    94  For client authentication, create a client key and certificate signing
    95  request:
    96  
    97      $ openssl genrsa -out key.pem 4096
    98      Generating RSA private key, 4096 bit long modulus
    99      .........................................................++
   100      ................++
   101      e is 65537 (0x10001)
   102      $ openssl req -subj '/CN=client' -new -key key.pem -out client.csr
   103  
   104  To make the key suitable for client authentication, create an extensions
   105  config file:
   106  
   107      $ echo extendedKeyUsage = clientAuth > extfile.cnf
   108  
   109  Now sign the public key:
   110  
   111      $ openssl x509 -req -days 365 -sha256 -in client.csr -CA ca.pem -CAkey ca-key.pem \
   112        -CAcreateserial -out cert.pem -extfile extfile.cnf
   113      Signature ok
   114      subject=/CN=client
   115      Getting CA Private Key
   116      Enter pass phrase for ca-key.pem:
   117  
   118  After generating `cert.pem` and `server-cert.pem` you can safely remove the
   119  two certificate signing requests:
   120  
   121      $ rm -v client.csr server.csr
   122  
   123  With a default `umask` of 022, your secret keys will be *world-readable* and
   124  writable for you and your group.
   125  
   126  In order to protect your keys from accidental damage, you will want to remove their
   127  write permissions. To make them only readable by you, change file modes as follows:
   128  
   129      $ chmod -v 0400 ca-key.pem key.pem server-key.pem
   130  
   131  Certificates can be world-readable, but you might want to remove write access to
   132  prevent accidental damage:
   133  
   134      $ chmod -v 0444 ca.pem server-cert.pem cert.pem
   135  
   136  Now you can make the Docker daemon only accept connections from clients
   137  providing a certificate trusted by our CA:
   138  
   139      $ docker daemon --tlsverify --tlscacert=ca.pem --tlscert=server-cert.pem --tlskey=server-key.pem \
   140        -H=0.0.0.0:2376
   141  
   142  To be able to connect to Docker and validate its certificate, you now
   143  need to provide your client keys, certificates and trusted CA:
   144  
   145  > **Note**: replace all instances of `$HOST` in the following example with the
   146  > DNS name of your Docker daemon's host.
   147  
   148      $ docker --tlsverify --tlscacert=ca.pem --tlscert=cert.pem --tlskey=key.pem \
   149        -H=$HOST:2376 version
   150  
   151  > **Note**:
   152  > Docker over TLS should run on TCP port 2376.
   153  
   154  > **Warning**:
   155  > As shown in the example above, you don't have to run the `docker` client
   156  > with `sudo` or the `docker` group when you use certificate authentication.
   157  > That means anyone with the keys can give any instructions to your Docker
   158  > daemon, giving them root access to the machine hosting the daemon. Guard
   159  > these keys as you would a root password!
   160  
   161  ## Secure by default
   162  
   163  If you want to secure your Docker client connections by default, you can move
   164  the files to the `.docker` directory in your home directory -- and set the
   165  `DOCKER_HOST` and `DOCKER_TLS_VERIFY` variables as well (instead of passing
   166  `-H=tcp://$HOST:2376` and `--tlsverify` on every call).
   167  
   168      $ mkdir -pv ~/.docker
   169      $ cp -v {ca,cert,key}.pem ~/.docker
   170      $ export DOCKER_HOST=tcp://$HOST:2376 DOCKER_TLS_VERIFY=1
   171  
   172  Docker will now connect securely by default:
   173  
   174      $ docker ps
   175  
   176  ## Other modes
   177  
   178  If you don't want to have complete two-way authentication, you can run
   179  Docker in various other modes by mixing the flags.
   180  
   181  ### Daemon modes
   182  
   183   - `tlsverify`, `tlscacert`, `tlscert`, `tlskey` set: Authenticate clients
   184   - `tls`, `tlscert`, `tlskey`: Do not authenticate clients
   185  
   186  ### Client modes
   187  
   188   - `tls`: Authenticate server based on public/default CA pool
   189   - `tlsverify`, `tlscacert`: Authenticate server based on given CA
   190   - `tls`, `tlscert`, `tlskey`: Authenticate with client certificate, do not
   191     authenticate server based on given CA
   192   - `tlsverify`, `tlscacert`, `tlscert`, `tlskey`: Authenticate with client
   193     certificate and authenticate server based on given CA
   194  
   195  If found, the client will send its client certificate, so you just need
   196  to drop your keys into `~/.docker/{ca,cert,key}.pem`. Alternatively,
   197  if you want to store your keys in another location, you can specify that
   198  location using the environment variable `DOCKER_CERT_PATH`.
   199  
   200      $ export DOCKER_CERT_PATH=~/.docker/zone1/
   201      $ docker --tlsverify ps
   202  
   203  ### Connecting to the secure Docker port using `curl`
   204  
   205  To use `curl` to make test API requests, you need to use three extra command line
   206  flags:
   207  
   208      $ curl https://$HOST:2376/images/json \
   209        --cert ~/.docker/cert.pem \
   210        --key ~/.docker/key.pem \
   211        --cacert ~/.docker/ca.pem