Kafka安全认证机制详解之SASL_PLAIN_kafka sasl认证，7年老网络安全一次操蛋的面试经历

• SASL/GSSAPI (Kerberos) ：使用kerberos认证，密码是加密的，也是当前企业中使用最多的，最小支持版本0.9
• SASL/PLAIN ：使用简单用户名和密码形式，生产环境中一般不使用，主要用于测试，最小支持版本0.10
• SASL/SCRAM：主要解决PLAIN动态更新问题以及安全机制，最小支持版本0.10.2
• SASL/OAUTHBEARER：基于OAuth2认证框架，最小支持版本2.0

几种认证方式的详细比较

• SASL/GSSAPI 主要是给 Kerberos 使用的。GSSAPI 适用于本身已经做了 Kerberos 认证的场景，这样的话，SASL/GSSAPI 可以实现无缝集成。
• SASL/PLAIN 是一个简单的用户名 / 密码认证机制，通常与 SSL 加密搭配使用。对于一些小公司而言，搭建公司级的 Kerberos 可能并没有什么必要，他们的用户系统也不复杂，特别是访问 Kafka 集群的用户可能不是很多。对于 SASL/PLAIN 而言，这就是一个非常合适的应用场景。总体来说，SASL/PLAIN 的配置和运维成本相对较小，适合于小型公司中的 Kafka 集群。SASL/PLAIN 有这样一个弊端：它不能动态地增减认证用户，必须重启 Kafka 集群才能令变更生效。因为所有认证用户信息全部保存在静态文件中，所以只能重启 Broker，才能重新加载变更后的静态文件。
• SASL/SCRAM 通过将认证用户信息保存在 ZooKeeper 的方式，避免了动态修改需要重启 Broker 的弊端。在实际使用过程中，可以使用 Kafka 提供的命令动态地创建和删除用户，无需重启整个集群。因此，如果打算使用 SASL/PLAIN，不妨改用 SASL/SCRAM 试试。不过要注意的是，后者是 0.10.2 版本引入的。
• SASL/OAUTHBEARER 是 2.0 版本引入的新认证机制，主要是为了实现与 OAuth 2 框架的集成。 Kafka 不提倡单纯使用 OAUTHBEARER，因为它生成的不安全的 JSON Web Token，必须配以 SSL 加密才能用在生产环境中。
• Delegation Token 是在 1.1 版本引入的，它是一种轻量级的认证机制，主要目的是补充现有的 SASL 或 SSL 认证。 如果要使用 Delegation Token，需要先配置好 SASL 认证，然后再利用 Kafka 提供的 API 去获取对应的 Delegation Token。这样，Broker 和客户端在做认证的时候，可以直接使用这个 token，不用每次都去 KDC 获取对应的 ticket（Kerberos 认证）或传输 Keystore 文件（SSL 认证）。

二、SASL/PLAIN

SASL/PLAIN是基于用户名密码的认证方式，是比较