1. 安全模式
etcd 支持自动 TLS 以及通过客户端证书的身份验证, 包括客户端到服务器以及对等(服务器到服务器/集群)的通信。
要开始运行,首先要为成员设置 CA 证书和已签名的密钥对。建议为集群中的每个成员创建并签署一个新的密钥对。
为方便起见,cfssl工具为证书生成提供了简单的界面,我们使用这里的工具提供了示例。或者,尝试生成自签名密钥对的指南。
1.1. 基本设置
etcd 通过命令行标志或环境变量来设置几个与证书相关的配置选项:
客户端到服务器端通讯:
--cert-file=<path>
: 用于到 etcd d的 SSL / TLS连接的证书。当设置此选项时,advertise-client-urls 可以使用 HTTPS 模式。
--key-file=<path>
: 证书的秘钥, 必须是不加密的.
--client-cert-auth
: 当这个选项被设置时,etcd 将为受信任CA签名的客户端证书检查所有的传入的 HTTPS 请求,不能提供有效客户端证书的请求将会失败。
--trusted-ca-file=<path>
: 受信任的认证机构
--auto-tls
: 为客户端的 TLS 连接,使用自动生成的自签名证书
对等通讯 (服务器到服务器 / 集群):
对等选项的工作方式与客户端到服务器的选项相同:
--peer-cert-file=<path>
: 用于对等体之间的 SSL / TLS 连接的证书。这将用于在对等地址上监听以及向其他对等体发送请求
--peer-key-file=<path>
: 证书的秘钥, 必须是不加密的.
--peer-client-cert-auth
: 当这个选项被设置时,etcd 将为受信任CA签名的客户端证书检查所有的传入的对等请求。
--peer-trusted-ca-file=<path>
: 受信任的认证机构.
--peer-auto-tls
: 为对等体之间的 TLS 连接使用自动生成的自签名证书
如果提供了客户端到服务器或对等证书,则必须设置密钥。所有这些配置选项也可以通过环境变量 “ETCD_CA_FILE”,“ETCD_PEER_CA_FILE”等提供。
1.2. 示例 1: 用HTTPS的客户端到服务器端传输安全
为此,准备好CA证书(ca.crt
)和签名密钥对(server.crt
, server.key
)。
Let us configure etcd to provide simple HTTPS transport security step by step:
让我们一步一步配置 etcd 来提供简单的 HTTPS 传输安全:
$ etcd --name infra0 --data-dir infra0 \
--cert-file=/path/to/server.crt --key-file=/path/to/server.key \
--advertise-client-urls=https://127.0.0.1:2379 --listen-client-urls=https://127.0.0.1:2379
应该可以启动,可以通过使用 HTTPS 访问 etcd 来测试配置:
$ curl --cacert /path/to/ca.crt https://127.0.0.1:2379/v2/keys/foo -XPUT -d value=bar -v
该命令应该显示握手成功。 由于我们用自己的证书颁发机构使用自签名证书,CA必须使用--cacert
选项传递给curl。 另一种可能性是将CA证书添加到系统的可信证书目录(通常位于 /etc/pki/tls/certs
或 /etc/ssl/certs
)中。
OSX 10.9+ 用户: curl 7.30.0 在 OSX 10.9+ 不能理解通过命令行传递的证书.
取而代之的,将虚拟 ca.crt 直接导入 keychain 或给 curl 添加-k
标志来忽略错误。
要测试没有-k'标志,运行
open ./fixtures/ca/ca.crt` 并按照提示进行操作。
测试后请删除此证书!
如果有解决方法,请告诉我们。
1.3. 示例 2: 用HTTPS客户端证书的客户端到服务器端认证
现在我们已经给了 etcd 客户端验证服务器身份和提供传输安全性的能力。我们也可以使用客户端证书来防止对 etcd 未经授权的访问。
客户端将向服务器提供证书,服务器将检查证书是否由CA签名,并决定是否服务请求。
为此需要第一个示例中提到的相同文件,以及由同一证书颁发机构签名的客户端(client.crt
, client.key
) 密钥对。
$ etcd --name infra0 --data-dir infra0 \
--client-cert-auth --trusted-ca-file=/path/to/ca.crt --cert-file=/path/to/server.crt --key-file=/path/to/server.key \
--advertise-client-urls https://127.0.0.1:2379 --listen-client-urls https://127.0.0.1:2379
现在尝试发送与上面相同的请求到服务器:
$ curl --cacert /path/to/ca.crt https://127.0.0.1:2379/v2/keys/foo -XPUT -d value=bar -v
该请求会被服务器拒绝:
...
routines:SSL3_READ_BYTES:sslv3 alert bad certificate
...
要想请求成功,我们需要将CA签名的客户端证书发送给服务器:
$ curl --cacert /path/to/ca.crt --cert /path/to/client.crt --key /path/to/client.key \
-L https://127.0.0.1:2379/v2/keys/foo -XPUT -d value=bar -v
输出为:
...
SSLv3, TLS handshake, CERT verify (15):
...
TLS handshake, Finished (20)
还有来自服务器的响应:
{
"action": "set",
"node": {
"createdIndex": 12,
"key": "/foo",
"modifiedIndex": 12,
"value": "bar"
}
}
1.4. 示例 3: 集群中的传输安全和客户端证书
对于对等通信,etcd 支持与上述相同的模型,这意味着集群中的 etcd 成员之间的通信。
Assuming we have our ca.crt
and two members with their own keypairs (member1.crt
& member1.key
, member2.crt
& member2.key
) signed by this CA, we launch etcd as follows:
假设我们有我们的 ca.crt
和两个成员,他们有这个CA签名的自己的 keypairs(member1.crt
&member1.key
,member2.crt
&member2.key
),我们如下启动 etcd:
DISCOVERY_URL=... # from https://discovery.etcd.io/new
# member1
$ etcd --name infra1 --data-dir infra1 \
--peer-client-cert-auth --peer-trusted-ca-file=/path/to/ca.crt --peer-cert-file=/path/to/member1.crt --peer-key-file=/path/to/member1.key \
--initial-advertise-peer-urls=https://10.0.1.10:2380 --listen-peer-urls=https://10.0.1.10:2380 \
--discovery ${DISCOVERY_URL}
# member2
$ etcd --name infra2 --data-dir infra2 \
--peer-client-cert-auth --peer-trusted-ca-file=/path/to/ca.crt --peer-cert-file=/path/to/member2.crt --peer-key-file=/path/to/member2.key \
--initial-advertise-peer-urls=https://10.0.1.11:2380 --listen-peer-urls=https://10.0.1.11:2380 \
--discovery ${DISCOVERY_URL}
etcd 成员将组成一个集群,集群中成员之间的所有通信将使用客户端证书进行加密和验证。etcd的输出将显示其连接的地址使用HTTPS。
1.5. Example 4: 自动自签名安全
对于需要通信加密而需要认证的情况,etcd 支持使用自动生成的自签名证书来加密其消息。这样可以简化部署,因为不需要管理 etcd 以外的证书和密钥。
使用标志--auto-tls
和--peer-auto-tls
配置 etcd 为客户端和对等连接使用自签名证书:
DISCOVERY_URL=... # from https://discovery.etcd.io/new
# member1
$ etcd --name infra1 --data-dir infra1 \
--auto-tls --peer-auto-tls \
--initial-advertise-peer-urls=https://10.0.1.10:2380 --listen-peer-urls=https://10.0.1.10:2380 \
--discovery ${DISCOVERY_URL}
# member2
$ etcd --name infra2 --data-dir infra2 \
--auto-tls --peer-auto-tls \
--initial-advertise-peer-urls=https://10.0.1.11:2380 --listen-peer-urls=https://10.0.1.11:2380 \
--discovery ${DISCOVERY_URL}
自签名证书不会对身份进行验证,因此 crul 将返回错误:
curl: (60) SSL certificate problem: Invalid certificate chain
要禁用证书链检查,请使用 -k
标志调用curl:
$ curl -k https://127.0.0.1:2379/v2/keys/foo -Xput -d value=bar -v
1.6. etcd proxy 注意事项
如果连接是安全的,etcd proxy 从其客户端终止TLS,并且使用 `--peer-key-file' 和 '--peer-cert-file' 中指定的代理自己的密钥/证书与 etcd 成员进行通信。
proxy 通过给定成员的 --advertise-client-urls
和 --advertise-peer-urls
与 etcd 成员进行通信。它将客户端请求转发到 etcd 成员的 advertised client url,并通过 etcd 成员的 advertised peer url 同步初始集群配置。
当 etcd 成员启用客户端身份验证时,管理员必须确保代理的 --peer-cert-file
选项中指定的对等证书对于该验证是有效的。如果启用对等身份验证,proxy 的对等证书也必须对对等身份验证有效。
1.7. FAQ
1.7.1. 使用TLS客户端身份验证时,我看到 SSLv3 警报握手失败?
golang
的 crypto / tls
包在使用它之前检查证书公钥的 key usage
。
要使用证书公钥进行客户端认证,我们需要在创建证书公钥时将 clientAuth
添加到 Extended Key Usage
。
这是怎么做的:
将以下部分添加到 openssl.cnf:
[ ssl_client ] ... extendedKeyUsage = clientAuth ...
- 创建证书时,确保在
-extensions
标志中引用它:
$ openssl ca -config openssl.cnf -policy policy_anything -extensions ssl_client -out certs/machine.crt -infiles machine.csr
- 创建证书时,确保在
1.7.2. 使用对等证书认证,我收到"证书对127.0.0.1有效,而不是$MY_IP"
确保使用成员的公共IP地址为 Subject 名称来签署证书。例如 etcd-ca
工具为它的 new-cert
命令提供 --ip=
选项。
证书需要在其 Subject 名称中为成员的 FQDN 签名,使用 Subject Alternative Names(短IP SAN)来添加IP地址。etcd-ca
工具为它的 new-cert
命令提供 --domain=
选项,而且 openssl 也可以这样实现。