在集群配置身份验证和授权时,Cloudera Manager Server会通过网络将敏感信息发送到集群主机,例如Kerberos keytabs和包含密码的配置文件。要确保传输安全,必须在Cloudera Manager Server和所有群集主机之间配置TLS加密。
TLS加密还用于使用HTTPS保护与Cloudera Manager管理界面的客户端连接。
Cloudera Manager还支持TLS身份验证。如果没有证书身份验证,恶意用户可以通过安装Cloudera Manager Agent软件并将其配置为与Cloudera Manager Server进行通信,将主机添加到Cloudera Manager。要防止这种情况,您必须在每个代理主机上安装证书,并将Cloudera Manager Server配置为信任这些证书。
本本介绍如何为Cloudera Manager配置和启用TLS加密和证书身份验证。提供的示例是使用内部证书颁发机构(CA)对所有TLS证书进行签名,因此本指南还向您展示了如何与CA建立信任。(对于由受信任的公共CA签名的证书,不需要建立信任,因为Java Development Kit(JDK)已经信任它们。)
证书可以使用表下面三种方式进行签名:
类型 | 说明 |
---|---|
公共CA签名证书 | 推荐。此类证书由公共证书颁发机构(CA)(如Symantec或Comodo)签名。公共CA是受信任的第三方,其证书可通过可公开访问的信任链进行验证。使用此类型的证书可以简化部署,因为安全基础结构(例如根CA)已包含在Java JDK及其默认信任库中。有关详细信息,请参阅生成TLS证书 |
内部CA签名证书 | 此类证书由您组织的内部CA签名。使用OpenSSL证书颁发机构,Microsoft Active Directory证书服务或其他内部CA系统的组织可以使用此类型的证书。有关使用内部CA签名证书进行配置的详细信息,请参阅如何为Cloudera Manager配置TLS加密。 |
自签名证书 | 不建议用于生产部署。自签名证书可用于非生产部署,例如概念验证设置。有关详细信息,请参阅使用TLS的自签名证书。 |
下面过程是使用内部证书颁发机构(CA),并说明如何为该内部CA建立信任。如果您使用受信任的公共A(例如Symantec,GeoTrust,Comodo和其他),则无需为已颁发的证书明确建立信任,除非您使用的是较旧的DK和较新的公共CA。默认情况下,较旧的JDK可能不信任较新的公共CA。
集群中的每台主机(包括Cloudera Manager Server主机)完成以下配置:
配置环境变量JAVA_HOME
export JAVA_HOME=/usr/java/jdk1.8.0_162
source /etc/profile
创建 /opt/cloudera/security/pki 目录
sudo mkdir -p /opt/cloudera/security/pki
如果选择使用其他目录,请确保在所有群集主机上使用相同的目录以简化管理和维护。
生成证书
使用keytool生成Java密钥库和签名证书请求(CSR)。修改下面OU(部门), O(公司名), L(城市), ST(省)、C (国家)的值。
切记使用相同的keystore password 和 key password。Cloudera Manager不支持为密钥和密钥库使用不同的密码。
$JAVA_HOME/bin/keytool -genkeypair -alias $(hostname -f) -keyalg RSA -keystore /opt/cloudera/security/pki/$(hostname -f).jks -keysize 2048 -dname "CN=$(hostname -f),OU=data,O=Hinabian,L=ShenZhen,ST=GuangDong,C=CN" -ext san=dns:$(hostname -f)
$JAVA_HOME/bin/keytool -certreq -alias $(hostname -f) -keystore /opt/cloudera/security/pki/$(hostname -f).jks -file /opt/cloudera/security/pki/$(hostname -f).csr -ext san=dns:$(hostname -f)
示例:
[root@node00 pki]# $JAVA_HOME/bin/keytool -genkeypair -alias $(hostname -f) -keyalg RSA -keystore /opt/cloudera/security/pki/$(hostname -f).jks -keysize 2048 -dname "CN=$(hostname -f),OU=Engineering,O=Cloudera,L=Palo Alto,ST=California,C=US" -ext san=dns:$(hostname -f)
Enter keystore password:
Re-enter new password:
Enter key password for <node00>
(RETURN if same as keystore password):
Re-enter new password:
Warning:
The JKS keystore uses a proprietary format. It is recommended to migrate to PKCS12 which is an industry standard format using "keytool -importkeystore -srckeystore /opt/cloudera/security/pki/node00.jks - destkeystore /opt/cloudera/security/pki/node00.jks -deststoretype pkcs12".
[root@node00 pki]#
[root@node00 pki]# $JAVA_HOME/bin/keytool -certreq -alias $(hostname -f) -keystore /opt/cloudera/security/pki/$(hostname -f).jks -file /opt/cloudera/security/pki/$(hostname -f).csr -ext san=dns:$(hostname -f)
Enter keystore password:
Warning:
The JKS keystore uses a proprietary format. It is recommended to migrate to PKCS12 which is an industry standard format using "keytool -importkeystore -srckeystore /opt/cloudera/security/pki/node00.jks - destkeystore /opt/cloudera/security/pki/node00.jks -deststoretype pkcs12".
[root@node00 pki]#
提交CSR文件
提交CSR文件(例如: cm01.example.com.csr)到您的证书颁发机构获取服务器证书,建议使用PEM(Base64 ASCII)格式证书。
生成并创建自签名证书
见博文:OpenSSL生成并使用CA根证书签名Keytool生成的证书请求
在node00上生成证书后,将 ca.crt,ca.csr,ca.key 拷贝到其他机器上
[root@node00 security]# scp ca.crt ca.csr ca.key root@node01:$PWD
ca.crt 100% 1200 59.7KB/s 00:00
ca.csr 100% 1005 189.7KB/s 00:00
ca.key 100% 1743 151.8KB/s 00:00
[root@node00 security]#
然后再其他机器上执行用CA根证书来签名服务器端的证书请求文件
,生成$(hostname -f).pem
将签名证书复制到/opt/cloudera/security/pki/$(hostname -f).pem
[root@node01 security]# cp node00.pem /opt/cloudera/security/pki/$(hostname -f).pem
检查签名证书
验证是否存在服务器和客户端身份验证选项
openssl x509 -in /opt/cloudera/security/pki/$(hostname -f).pem -noout -text
示例:
[root@node02 pki]# openssl x509 -in /opt/cloudera/security/pki/$(hostname -f).pem -noout -text
Certificate:
Data:
Version: 3 (0x2)
Serial Number: 1 (0x1)
Signature Algorithm: sha256WithRSAEncryption
Issuer: C=CN, ST=GuangDong, L=ShenZhen, O=Hinabian, OU=data, CN=node02
Validity
Not Before: Oct 24 08:54:57 2018 GMT
Not After : Oct 21 08:54:57 2028 GMT
Subject: C=CN, ST=GuangDong, O=Hinabian, OU=data, CN=node02
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
Public-Key: (2048 bit)
Modulus:
00:a4:9c:be:6f:ac:4c:d6:59:e9:37:da:e2:55:25:
6c:7b:b7:84:2f:f7:70:33:ba:a4:f4:98:9f:e5:6c:
f8:70:76:1e:97:02:b7:73:be:60:48:ee:2c:80:fb:
bf:60:9e:75:1f:7f:e1:1a:f9:9d:34:14:cc:17:d2:
79:5b:06:a7:c2:29:20:9a:3e:78:ef:ba:2a:43:7a:
cb:d5:d7:d7:3c:50:ae:57:97:65:21:f3:e3:98:f5:
b0:ad:1b:ed:3d:41:d0:8c:45:49:a2:de:8f:8d:11:
63:0a:d9:47:55:dc:36:13:4e:c5:11:4d:e6:f2:59:
48:73:20:9a:e0:07:d5:29:7f:72:fb:cd:a1:e8:6e:
1e:d2:5e:af:8a:f0:30:6c:58:29:bc:02:62:53:50:
a1:80:ef:21:c2:de:1b:14:d3:43:50:c5:6d:90:16:
b0:70:2d:5c:8f:74:47:aa:b2:e0:45:fd:f0:d7:a8:
f5:28:2b:dc:99:f1:42:c4:a3:8e:39:c2:2f:10:39:
5f:7e:f1:58:61:d2:b8:d4:1c:95:ec:59:2c:02:7a:
4a:79:7c:fb:75:ce:6c:48:56:c4:00:c2:a0:ad:1e:
b1:bb:36:d7:cb:5d:62:0a:ce:31:bd:4e:82:9b:6e:
1f:7a:8d:76:c6:42:f7:c6:24:3a:62:b1:70:7d:8d:
84:01
Exponent: 65537 (0x10001)
X509v3 extensions:
X509v3 Basic Constraints:
CA:FALSE
Netscape Comment:
OpenSSL Generated Certificate
X509v3 Subject Key Identifier:
58:30:7D:B3:7E:85:D4:39:22:2F:B3:96:55:A3:38:68:FE:7F:03:88
X509v3 Authority Key Identifier:
DirName:/C=CN/ST=GuangDong/L=ShenZhen/O=Hinabian/OU=data/CN=node02
serial:E1:40:B9:DB:A9:83:F9:C3
Signature Algorithm: sha256WithRSAEncryption
2b:68:77:99:f4:ff:68:df:de:6d:22:d9:db:b0:b8:c6:ce:90:
c5:ce:e4:f4:27:53:f1:34:35:00:75:83:0a:8f:5f:21:27:36:
41:ab:6a:22:e5:6e:a1:0a:98:02:9e:16:b4:c6:6c:d9:f3:32:
29:24:8b:46:15:0d:1d:56:51:d8:8e:91:16:99:56:9c:ee:8b:
41:cb:b3:29:96:78:9e:a3:5a:5a:60:5c:81:cd:09:ba:ef:dc:
c2:1b:f2:98:57:c8:9b:3a:ea:91:a5:09:3b:f8:81:ba:3f:17:
b8:ea:d4:ad:2a:aa:5d:6b:0e:9c:91:46:02:c9:d5:04:a5:3c:
b9:45:ea:dc:f8:0b:e3:56:ae:8e:fb:c0:f0:ed:3d:9e:36:95:
c7:43:2f:b8:4e:77:95:7f:ab:e3:48:50:eb:fa:1d:93:50:41:
a5:e8:25:7e:29:6e:d3:d5:ae:64:4b:65:c5:99:28:00:03:d1:
a5:a0:1c:4f:03:fa:e7:5b:55:c4:89:98:6c:11:d0:2c:6e:88:
6a:c2:dd:50:37:cc:3a:25:d6:6e:82:25:dc:56:09:54:0d:77:
d0:88:ab:0e:5f:25:50:b4:b5:af:6d:74:4a:81:bf:43:9d:04:
e5:55:6a:60:c3:a0:c8:03:45:d8:ad:7f:ec:59:79:aa:1f:dc:
0f:6f:3b:fc
[root@node02 pki]#
CA证书复制
注意:如果您有包含根CA和中间CA证书的连锁文件,请沿着文件拆分文件END CERTIFICATE/BEGIN CERTIFICATE边界到单个文件。如果有多个中间CA证书,请使用唯一的文件名,例如 intca-1.pem, intca-2.pem等等。
[root@node01 security]# cp ca.crt /opt/cloudera/security/pki/rootca.pem
[root@node01 security]# cp intca.crt /opt/cloudera/security/pki/intca.pem
复制JDK cacerts中 归档到 jssecacerts
sudo cp $JAVA_HOME/jre/lib/security/cacerts $JAVA_HOME/jre/lib/security/jssecacerts
注意:cacerts的默认密码是 changeit , 如需修改,Cloudera 建议使用以下命令来更改密码。
$JAVA_HOME/bin/keytool -storepasswd -keystore $JAVA_HOME/jre/lib/security/cacerts
$JAVA_HOME/bin/keytool -storepasswd -keystore $JAVA_HOME/jre/lib/security/jssecacerts
将根CA证书导入JDK信任库
sudo $JAVA_HOME/bin/keytool -importcert -alias rootca -keystore $JAVA_HOME/jre/lib/security/jssecacerts -file /opt/cloudera/security/pki/rootca.pem
示例:
[root@node00 security]# sudo $JAVA_HOME/bin/keytool -importcert -alias rootca -keystore $JAVA_HOME/jre/lib/security/jssecacerts -file /opt/cloudera/security/pki/rootca.pem
Enter keystore password:
Owner: CN=node00, OU=data, O=Hinabian, L=ShenZhen, ST=GuangDong, C=CN
Issuer: CN=node00, OU=data, O=Hinabian, L=ShenZhen, ST=GuangDong, C=CN
Serial number: 9471ac2f95693bf8
Valid from: Wed Oct 24 14:37:41 CST 2018 until: Thu Oct 24 14:37:41 CST 2019
Certificate fingerprints:
MD5: 82:93:CE:E0:29:BC:58:13:D8:54:2D:50:94:CB:FD:D6
SHA1: 1B:74:63:E1:5D:21:38:01:E0:7B:4F:EE:18:7B:0D:1D:5B:85:B7:D2
SHA256: 04:D8:1C:BA:4F:D8:9C:ED:E7:A5:9A:49:6A:B8:D6:9E:D9:76:71:4A:AB:9B:30:06:41:CD:A7:0E:74:4F:1F:1E
Signature algorithm name: SHA256withRSA
Subject Public Key Algorithm: 2048-bit RSA key
Version: 1
Trust this certificate? [no]: yes
Certificate was added to keystore
[root@node00 security]#
将中间CA证书附加到签名的主机证书,然后将其导入密钥库。
注意:使用追加运算符(>>)而不是覆盖操作符(>)。
sudo cat /opt/cloudera/security/pki/intca.pem >> /opt/cloudera/security/pki/$(hostname -f).pem
sudo $JAVA_HOME/bin/keytool -importcert -alias $(hostname -f) -file /opt/cloudera/security/pki/$(hostname -f).pem -keystore /opt/cloudera/security/pki/$(hostname -f).jks
为证书和密钥库文件创建符号链接
sudo ln -s /opt/cloudera/security/pki/$(hostname -f).pem /opt/cloudera/security/pki/agent.pem
这样可以使所有agent节点使用相同的 /etc/cloudera-scm-agent/config.ini 配置,而不需要维护每个agent节点。
在Cloudera Manager Server节点上,创建密钥库文件符号链接
sudo ln -s /opt/cloudera/security/pki/$(hostname -f).jks /opt/cloudera/security/pki/server.jks
Cloudera Manager Admin Console启用HTTPS
Cloudera Management Services指定SSL Truststore属性
在Cloudera Manager Server管理界面启用TLS时,必须在Cloudera Management Services配置中设置Java信任库位置和密码。否则,Host Monitor和Service Monitor等角色无法连接到Cloudera Manager Server,导致无法启动。
配置信任库的路径$JAVA_HOME/jre/lib/security/jssecacerts
和密码changeit
。确保集群中所有节点(包括Cloudera Management Service节点)上创建了此文件。
打开Cloudera Manager管理控制台并转到Cloudera Management Service服务,单击“ 配置”选项卡。选择Scope > Cloudera Management Service(服务范围) >类别 > 安全性
根据集群配置编辑以下TLS / SSL属性后,保存提交。
重新启动Cloudera Manager和Cloudera Management Service服务
重启Cloudera Manager
$ /opt/cm-5.11.0/etc/init.d/cloudera-scm-server restart
重启Cloudera Management Service服务
Cloudera Management Service > 操作 > 重新启动
在Cloudera Manager中为代理启用TLS加密,配置Cloudera Manager Agents的TLS属性。
登录Cloudera Manager Admin Console > 管理 > 设置 > 安全性
勾选“ 为代理使用 TLS 加密”选项。
单击“ 保存更改”以提交更改。
在Cloudera Manager Agent节点上启用TLS
要在Cloudera Manager Agent和Cloudera Manager之间启用TLS,必须在TLS属性中指定TLS属性的值。 修改所有agent节点上的配置文件/opt/cm-5.11.0/etc/cloudera-scm-agent/config.ini 。
[Security]
# Use TLS and certificate validation when connecting to the CM server.
use_tls=1 (默认为0)
重新启动Cloudera Manager Server和Cloudera Manager Agent
$ /opt/cm-5.11.0/etc/init.d/cloudera-scm-server restart
$ /opt/cm-5.11.0/etc/init.d/cloudera-scm-agent restart (每个agent节点均要执行)
验证Cloudera Manager Server 和Cloudera Manager Agent是否正常通信
如果在重新启动代理后在Last Heartbeat列中看到成功检测到心跳,则TLS加密正常。
登录Cloudera Manager Admin Console > 主机 > 所有主机 > 上一检测信号
如果已完成上述步骤,则Cloudera Manager Server与Cloudera Manager Agent之间的通信将被加密,但并不验证证书的真实性。为了保持完全安全,Agent 必须配置 验证Cloudera Manager Server证书。如果使用由内部证书颁发机构(CA)签名的服务器证书,则Agent必须配置信任该CA。
verify_cert_file=/opt/cloudera/security/pki/rootca.pem
$ /opt/cm-5.11.0/etc/init.d/cloudera-scm-server restart
$ /opt/cm-5.11.0/etc/init.d/cloudera-scm-agent restart (每个agent节点均要执行)
如果没有证书身份验证,恶意用户可以通过安装Cloudera Manager Agent软件并将其配置为与Cloudera Manager Server进行通信,将该节点添加到Cloudera Manager。为了防止这种情况,Cloudera Manager必须配置信任Agent证书。
要点:在每个Agent节点上执行此过程,包括也具有Agent的Cloudera Manager Server节点
。
将私钥导出到文件
在每个Cloudera Manager Agent节点上,使用keytool
将私钥和证书导出到PKCS12
文件中,然后可以使用。分成单独的密钥和证书文件 OpenSSL
的 命令:
$ sudo $JAVA_HOME/bin/keytool -importkeystore -srckeystore /opt/cloudera/security/pki/$(hostname -f).jks -destkeystore /opt/cloudera/security/pki/$(hostname -f)-key.p12 -deststoretype PKCS12 -srcalias $(hostname -f)
sudo openssl pkcs12 -in /opt/cloudera/security/pki/$(hostname -f)-key.p12 -nocerts -out /opt/cloudera/security/pki/$(hostname -f).key
sudo ln -s /opt/cloudera/security/pki/$(hostname -f).key /opt/cloudera/security/pki/agent.key
所有Agent节点使用相同的配置文件( /etc/cloudera-scm-agent/config.ini
),而不需要为每个节点单独维护配置文件。
创建密码文件
Cloudera Manager Agent 从文本文件获取密码,而不是从命令行参数或环境变量获取密码。改变密码文件的文件权限来保护密码。
在每个Cloudera Manager Agent节点上运行以下命令,或在一个节点上运行它们然后将文件复制到其他主机:
使用文本编辑器创建一个名为/etc/cloudera-scm-agent/agentkey.pw
的文件,包含密码。
将文件的所有权更改为 root:
sudo chown root:root /etc/cloudera-scm-agent/agentkey.pw
更改文件的权限:
sudo chmod 440 /etc/cloudera-scm-agent/agentkey.pw
配置代理以使用私钥和证书
在Cloudera Manager Agent上,编辑 配置文件(/etc/cloudera-scm-agent/config.ini
)。
取消注释并编辑以下属性:
属性 | 示例值 | 描述 |
---|---|---|
lient_key_file | /opt/cloudera/security/pki/agent.key | 私钥文件的路径。 |
lient_keypw_file | /etc/cloudera-scm-agent/agentkey.pw | 私钥密码文件的路径。 |
lient_cert_file | /opt/cloudera/security/pki/agent.pem | 客户端证书文件的路径。 |
将文件复制到所有其他节点。如果您修改了 在 config.ini文件的属性listening_hostname 或listening_ip地址,必须在每台主机上单独编辑文件。
启用代理证书身份验证
登录Cloudera Manager Admin Console > 管理 > 设置 > 安全性
配置以下TLS设置:
设置 | 描述 |
---|---|
使用代理的TLS身份验证到服务器 | 选择此选项可启用代理到服务器的TLS身份验证。 |
Cloudera Manager TLS / SSL证书信任存储文件 | 指定的完整文件系统路径 jssecacerts文件位 于Cloudera Manager Server主机上。对于此示例,请将值设置为: 将 |
Cloudera Manager TLS / SSL证书信任存储密码 | jssecacerts 信任库的密码 。 |
单击“ 保存更改”以提交更改。
重新启动Cloudera Manager Server和Cloudera Manager Agent
$ /opt/cm-5.11.0/etc/init.d/cloudera-scm-server restart
$ /opt/cm-5.11.0/etc/init.d/cloudera-scm-agent restart (每个agent节点均要执行)
验证Cloudera Manager Server和代理是否正在通信
登录Cloudera Manager Admin Console > 主机 > 所有主机 > 上一检测信号
如果在重新启动代理后在Last Heartbeat列中看到成功检测到心跳,则TLS加密验证正常。
如果没有,请检查Agent错误日志(/var/log/cloudera-scm-agent/cloudera-scm-agent.log)。
如果遇到以下错误:
WrongHost: Peer certificate commonName does not match host, expected 192.0.2.155, got cdh-1.example.com
[02/May/2018 15:04:15 +0000] 4655 MainThread agent ERROR Heartbeating to 192.0.2.155:7182 failed
/etc/cloudera-scm-agent/config.ini
的SERVER_HOST参数使用Cloudera Manager Server主机名,而不是IP地址。