From 876bdfeaa78aad313079020370740bf1fee413ad Mon Sep 17 00:00:00 2001 From: Tycho Andersen Date: Tue, 29 Aug 2017 14:23:56 -0700 Subject: [PATCH] add two little auth docs blurbs (#4405) --- engine/security/https.md | 17 +++++++++++++++-- 1 file changed, 15 insertions(+), 2 deletions(-) diff --git a/engine/security/https.md b/engine/security/https.md index 7419f18bf3..7145b84bb1 100644 --- a/engine/security/https.md +++ b/engine/security/https.md @@ -76,12 +76,19 @@ name) matches the hostname you will use to connect to Docker: Next, we're going to sign the public key with our CA: -Since TLS connections can be made via IP address as well as DNS name, they need -to be specified when creating the certificate. For example, to allow connections +Since TLS connections can be made via IP address as well as DNS name, the IP addresses +need to be specified when creating the certificate. For example, to allow connections using `10.10.10.20` and `127.0.0.1`: $ echo subjectAltName = DNS:$HOST,IP:10.10.10.20,IP:127.0.0.1 > extfile.cnf +Set the Docker daemon key's extended usage attributes to be used only for +server authentication: + + $ echo extendedKeyUsage = serverAuth > extfile.cnf + +Now, generate the key: + $ openssl x509 -req -days 365 -sha256 -in server.csr -CA ca.pem -CAkey ca-key.pem \ -CAcreateserial -out server-cert.pem -extfile extfile.cnf Signature ok @@ -89,6 +96,12 @@ using `10.10.10.20` and `127.0.0.1`: Getting CA Private Key Enter pass phrase for ca-key.pem: +[Authorization plugins](../extend/plugins_authorization) offer more +fine-grained control to supplement authentication from mutual TLS. In addition +to other information described in the above document, authorization plugins +running on a Docker daemon receive the certificate information for connecting +Docker clients. + For client authentication, create a client key and certificate signing request: