kafka的安全机制基础概念

kafka的安全性包括三个组成部分：

1. 数据加密(SSL)
   SSL解决的是数据安全的问题，使得kafka客户端和kafka服务端之间传输的数据是加密的，传输过程中的数据不能被截取。
   当然SSL证书也能解决身份问题，但这不是必须的。

2. 用户认证(SSL或者SASL)
   SASL: Simple Authorization Service Layer
   用户认证解决的是身份问题，即表明谁是谁。这有两种方式：

   • SSL证书本身来表明身份；这就是SSL证书的另一个功能，身份标识。
   • SASL使用(类似用户名+密码)来表明自己的身份。

   有了用户认证功能，就可以验证这是不是一个有效的用户啊，这样就可以为访问的安全性，以及后面的授权提供基础。

3. 用户授权
   用户授权解决的的是用户有什么权限的问题。 但是用户授权必须依赖前面的用户认证，因为只有完成了身份认证，确定了谁是谁的问题，才能对用户授权。

所以组合起来有如下几种组合：

认证授权组合类型

1. SSL + ACL
   使用SSL的证书信息完成用户认证(依靠证书内的身份信息)，使用ACL对证书用户授权；另外数据传输是SSL加密安全的。
2. SASL + ACL
   使用SASL提供给的信息完成用户认证(用户名+密码)，使用ACL对SASL用户授权；但是数据传输是明文的，不安全。
3. SSL + SASL + ACL
   使用SASL提供给的信息完成用户认证(用户名+密码)，使用ACL对SASL用户授权；另外数据传输是SSL加密安全的。

这里有一个问题：

• 问：既然SSL+ACL已经完全解决了认证和授权以及传输安全的问题，为什么还需要SSL+SASL+ACL呢？
• 猜：我猜因为是用户名账号的格式问题。SASL提供的是原生的用户账号信息，这些账户可能存在系统账号里面例如LDAP，这样SSL和SASL账号之间能够打通；而SSL证书提供的账号信息是SUBJ域的CN字段，这个CN域可能不能直接反应现场用户；另外证书可能是共享的域证书，不是单用户证书。而且SSL证书可以只用来传输加密，不用来做身份认证，例如我们没有CA根证书来验证SSL证书的身份，这样就无法识别用户身份，但是不妨碍继续使用这种证书来为数据传输做加密；因为证书认证需要CA根证书，而用在数据加密传输则不需要CA根证书。

SASL支持的模式

1. SASL PLAINTEXT:
   • 传统用户名/密码验证。
   • 用户名/密码以明文在网上传输。(建议开启SSL)
   • 用户名密码需要事先存储在kafka，所以更改用户信息需要重启kafka。

1. SASL SCRAM

   • 在用户名/密码的基础上，增加了一个challenge salt
   • 用户名/密码以明文在网上传输。(建议开启SSL)
   • 用户名/密码hash值存在在zookeeper上，这样更改用户信息可以不用重启kafka

2. SASL GSSAPI (Kerberos):

   • 没有弄过
   • 基于Kerberos

3. SASL OAUTHBEARER

   • kafka 2.0之后新增的

本页内容由塔灯网络科技有限公司通过网络收集编辑所得，所有资料仅供用户学习参考，本站不拥有所有权，如您认为本网页中由涉嫌抄袭的内容，请及时与我们联系，并提供相关证据，工作人员会在5工作日内联系您，一经查实，本站立刻删除侵权内容。本文链接:https://dengtar.com/20454.html