在版本0.9.0.0中,kafka社区添加了一些单独或一起使用的功能,可以提高kafka集群的安全性。Kafka 目前支持SSL、SASL/Kerberos、SASL/PLAIN三种认证机制。目前支持以下安全措施:
Keytool 是一个Java 数据证书的管理工具 ,Keytool 将密钥(key)和证书(certificates)存在一个称为keystore的文件中 在keystore里,包含两种数据:
密钥实体(Key entity)——密钥(secret key)又或者是私钥和配对公钥(采用非对称加密)可信任的证书实体(trusted certificate entries)——只包含公钥
Kerberos 是一种网络认证协议,其设计目标是通过密钥系统为客户机 / 服务器应用程序提供强大的认证服务。
openssl 是目前最流行的 SSL 密码库工具,其提供了一个通用、健壮、功能完备的工具套件,用以支持SSL/TLS 协议的实现。
apache kafka允许客户端通过ssl进行连接。默认情况下,ssl被禁用,但可以根据需要启用。
部署HTTPS,第一步是为集群的每台机器生成密钥和证书,可以使用java的keytool来生产。我们将生成密钥到一个临时的密钥库,之后我们可以导出并用CA签名它。
keytool -keystore server.keystore.jks -alias localhost -validity {validity} -genkey
你需要用上面命令来指定两个参数。
注意:默认情况下,不会定义ssl.endpoint.identification.algorithm,所以不会执行主机名验证。 要启用主机名验证,请设置以下属性:
ssl.endpoint.identification.algorithm=HTTPS
一旦启用,客户端将根据以下两个字段之一验证服务器的完全限定域名(FQDN):
两个字段都有效,但RFC-2818建议使用SAN。 SAN更灵活,允许声明多个DNS条目。 另一个优点是,CN可以设置为更有意义的值用于授权。 要添加SAN字段,可用以下参数 -ext SAN = DNS:{FQDN}:
keytool -keystore server.keystore.jks -alias localhost -validity {validity} -genkey -ext SAN=DNS:{FQDN}
之后可以运行以下命令来验证生成的证书的内容:
keytool -list -v -keystore server.keystore.jks
通过第一步,集群中的每台机器都生成一对公私钥
,和一个证书
来识别机器。但是,证书是未签名的,这意味着攻击者可以创建一个这样的证书来假装成任何机器。
因此,通过对集群中的每台机器进行签名来防止伪造的证书。证书颁发机构(CA)负责签名证书。CA的工作机制像一个颁发护照的政府。政府印章(标志)每本护照,这样护照很难伪造。其他政府核实护照的印章,以确保护照是真实的。同样,CA签名的证书和加密保证签名证书很难伪造。因此,只要CA是一个真正和值得信赖的权威,client就能有较高的保障连接的是真正的机器。
openssl req -new -x509 -keyout ca-key -out ca-cert -days 365
生成的CA是一个简单的公私钥对
和证书
,用于签名其他的证书。
下一步是将生成的CA添加到**clients' truststore(客户的信任库)**
,以便client可以信任这个CA:
keytool -keystore client.truststore.jks -alias CARoot -import -file ca-cert
注意,还需设置ssl.client.auth
(”requested" 或 "required”),来要求broker对客户端连接进行验证,当然,你必须为broker提供信任库以及所有客户端签名了密钥的CA证书,通过下面的命令:
keytool -keystore server.truststore.jks -alias CARoot -import -file ca-cert
相反,在步骤1中,密钥库存储了每个机器自己的身份。客户端的信任库存储所有客户端信任的证书,将证书导入到一个信任仓库也意味着信任由该证书签名的所有证书,正如上面的比喻,信任政府(CA)也意味着信任它颁发的所有护照(证书),此特性称为信任链,在大型的kafka集群上部署SSL时特别有用的。可以用单个CA签名集群中的所有证书,并且所有的机器共享相同的信任仓库,这样所有的机器也可以验证其他的机器了。
用步骤2生成的CA来签名所有步骤1生成的证书,首先,你需要从密钥仓库导出证书:
keytool -keystore server.keystore.jks -alias localhost -certreq -file cert-file
然后用CA签名:
openssl x509 -req -CA ca-cert -CAkey ca-key -in cert-file -out cert-signed -days {validity} -CAcreateserial -passin pass:{ca-password}
最后,你需要导入CA的证书和已签名的证书到密钥仓库:
keytool -keystore server.keystore.jks -alias CARoot -import -file ca-cert
keytool -keystore server.keystore.jks -alias localhost -import -file cert-signed
参数的定义如下:
这是上面所有步骤的一个bash脚本例子。注意,这里假设密码“test1234”
#!/bin/bash #Step 1 keytool -keystore server.keystore.jks -alias localhost -validity 365 -keyalg RSA -genkey #Step 2 openssl req -new -x509 -keyout ca-key -out ca-cert -days 365 keytool -keystore server.truststore.jks -alias CARoot -import -file ca-cert keytool -keystore client.truststore.jks -alias CARoot -import -file ca-cert #Step 3 keytool -keystore server.keystore.jks -alias localhost -certreq -file cert-file openssl x509 -req -CA ca-cert -CAkey ca-key -in cert-file -out cert-signed -days 365 -CAcreateserial -passin pass:test1234 keytool -keystore server.keystore.jks -alias CARoot -import -file ca-cert keytool -keystore server.keystore.jks -alias localhost -import -file cert-signed
Kafka Broker支持监听多个端口上的连接,通过server.properteis
配置,最少监听1个端口,用逗号分隔。
listeners
如果broker之间通讯未启用SSL(参照下面,启动它),PLAINTEXT和SSL端口是必须要配置。
listeners=PLAINTEXT://host.name:port,SSL://host.name:port
下面是broker端需要的SSL配置,
ssl.keystore.location=/var/private/ssl/kafka.server.keystore.jks
ssl.keystore.password=test1234
ssl.key.password=test1234
ssl.truststore.location=/var/private/ssl/kafka.server.truststore.jks
ssl.truststore.password=test1234
下面是可选的配置:
如果你想启用SSL用于broker内部通讯,将以下内容添加到broker配置文件(默认是PLAINTEXT)
security.inter.broker.protocol=SSL
由于一些国家的进口规定,oracle的实现限制了默认的加密算法的强度。如果需要更强的算法(例如AES 256位密钥),该JCE Unlimited Strength Jurisdiction Policy Files必须获得并安装JDK和JRE。更多信息参见JCA文档。
JRE/JDK有一个默认伪随机数生成者(PRNG),用于加密操作。因此,不需要用
ssl.secure.random.implementation
实现。 然而,有些实现存在性能问题(尤其是在Linux系统选择的默认值
NativePRNG
,使用全局锁)。 在SSL连接的性能出现问题的情况下,请考虑明确设置要使用的实现。 如
SHA1PRNG
实现是非阻塞的,并且在高负载(50MB/秒的生成消息,以及每个代理的复制流量)下显示出非常好的性能特征。
一旦你启动broker,你应该就能在server.log看到
with addresses: PLAINTEXT -> EndPoint(192.168.64.1,9092,PLAINTEXT),SSL -> EndPoint(192.168.64.1,9093,SSL)
用以下命令,快速验证服务器的keystore和truststore设置是否正确:
openssl s_client -debug -connect localhost:9093 -tls1
(注意: TLSv1 应列出 ssl.enabled.protocols)
在命令的输出中,你应该能看到服务器的证书:
-----BEGIN CERTIFICATE-----
{variable sized random bytes}
-----END CERTIFICATE-----
subject=/C=US/ST=CA/L=Santa Clara/O=org/OU=org/CN=Sriharsha Chintalapani
issuer=/C=US/ST=CA/L=Santa Clara/O=org/OU=org/CN=kafka/[email protected]
如果证书没有出现或者有任何其他错误信息,那么你的keystore设置不正确。
SSL仅支持新的Producer和Consumer,不支持老的API,Producer和Consumer的SSL的配置是相同的。
如果broker中不需要client(客户端)验证,那么下面是最小的配置示例:
security.protocol=SSL
ssl.truststore.location=/var/private/ssl/kafka.client.truststore.jks
ssl.truststore.password=test1234
注意:ssl.truststore.password在技术上是可选的,但强烈推荐。 如果未设置密码,对信任库的访问仍然可用,就不属于完整性检查。 如果需要客户端认证,则必须像步骤1一样创建密钥库,并且还必须配置以下内容:
ssl.keystore.location=/var/private/ssl/kafka.client.keystore.jks
ssl.keystore.password=test1234
ssl.key.password=test1234
也可以根据我的需求在broker上设置其他的配置:
举个例子,使用 console-producer 和 console-consumer :
kafka-console-producer.sh --broker-list localhost:9093 --topic test --producer.config client-ssl.properties
kafka-console-consumer.sh --bootstrap-server localhost:9093 --topic test --consumer.config client-ssl.propert