Kafka 中 SASL ACL SSL 分别代表什么意思
auth: huangyichun
date: 2023-5-11
序
看各类帖子都没能指出这些到底是什么意思，他们是冲突的，还是互相作用的，还是隔离的？本文讲解 kafka 中 SASL、ACL、SSL 他们分别的作用以及含义。
SASL 身份认证
SASL 是用来认证 C/S 模式也就是服务器与客户端的一种认证机制，全称 Simple Authentication and Security Layer。通俗的话来讲就是让服务器知道连接进来的客户端的身份是谁。
比如凭借阅证到图书馆借书，而每个借阅证都有独立的 ID，通过 ID 定位谁是谁，而不是特别关心谁拿到了借阅证，只需要正确的借阅证即可。
这就是一种凭据认证方式。
再比如 登陆QQ，只需要账号密码即可，就可以用该 QQ 和朋友聊天等等。
这种是我们常见的账号密码认证方式。
所以 SASL 就是服务器存储了客户端的身份证书和如何校验密码是否正确，而且仅在于身份认证过程，认证完毕后即可进行相关的服务操作。
而 SASL 只是一种模式，需要依赖于具体的连接媒介，比如 JAAS客户端、GSSAPI(Kerberos)、PLAIN、SCRAM-SHA-256、SCRAM-SHA-512、OAuthBearer 等等。这里分别讲解一下他们的具体含义：
JAAS 客户端
全名 Java Authentication Authorization Service，Java 的认证和授权服务。这种方式可以插入式将认证和授权逻辑与应用程序分离开。
JAAS 使得客户端通过配置 sasl.jaas.config 或者指定静态 jaas 文件来进行配置，完成配置后即可连接服务器，如：
System.setProperty("java.security.auth.login.config", "kafka_client_kafka.js");或者：
# kerberos 认证模板
sasl.jaas.config=com.sun.security.auth.module.Krb5LoginModule required \
useKeyTab=true \
storeKey=true \
keyTab="/etc/security/keytabs/kafka_client.keytab" \
principal="kafka-client-1@EXAMPLE.COM";所以 JAAS 能够使得客户端 JAVA程序 快速以某种认证方式连接服务器。
SASL/GSSAPI(Kerberos)
在使用 SASL 时采用的具体认证方式为 Kerberos GSSAPI，大多数大数据集群在认证时采用的也都是这种方法。通过 Kerberos 的认证拿到 TGT 后访问 Kafka 集群，此时 Kafka 集群验证身份是否正确让其访问服务。
这种方式是在环境中已经拥有Kerberos 认证时的最优解。
SASL/PLAIN 明文账号密码
当大数据集群中，没有类似于 Kerberos 相关的认证服务时，最简单的就是 SASL/PALIN 这样的账号密码登录了。这个就是在 Kafka 集群中添加一个身份认证文件 kafka_server_jaas.conf，如：
KafkaServer {
org.apache.kafka.common.security.plain.PlainLoginModule required
username="admin"
password="admin-secret"
user_admin="admin-secret"
user_alice="alice-secret";
};比如上述文件就是定义了两个用户 admin 和 alice，并且密码分别为 admin-secret 和 alice-secret。这样的定义简单却不方便，因为在添加或者删除用户时需要重启集群，所以在生产中基本不能使用。当然可以二次开发，但也不推荐。
SASL/SCRAM 对 PLAIN 进行升级，将账号数据存储在 ZK 中
SCARM 其实也是账号密码认证机制，但是数据存储在 zookeeper 中，这样使得可以动态增加删除用户。生产环境中可以使用这种方式，但记住最好开启 zookeeper 的认证，如果 zookeeper 没开启认证那也是不行的。
分别有两种加密方法：SCRAM-SHA-256 和 SCRAM-SHA-512，长度不同。
一般通过如下命令进行管控：
bin/kafka-configs.sh --zookeeper localhost:2182 --zk-tls-config-file zk_tls_config.properties --alter --add-config 'SCRAM-SHA-256=[password=admin-secret],SCRAM-SHA-512=[password=admin-secret]' --entity-type users --entity-name admin
bin/kafka-configs.sh --zookeeper localhost:2182 --zk-tls-config-file zk_tls_config.properties --describe --entity-type users --entity-name alice
bin/kafka-configs.sh --zookeeper localhost:2182 --zk-tls-config-file zk_tls_config.properties --alter --delete-config 'SCRAM-SHA-512' --entity-type users --entity-name alice上面创建了 admin 和 alice 用户，并且设定了对应的密码，最后一条命令删除了 alice 用户。
SASL/OAUTHBEARER
基于 OAUTH2.0 的认证框架，这里需要 OATH2 框架进行认证。
相关认证还有
LDAP，SSO，CAS，OIDC，SAML2等等。
具体流程一般为：
- 访问服务时将跳转到
Authing进行认证。 - 认证完毕后服务会获取到
Authing发来的授权码，这里再次和Authing进行交互获取AccessToken。 - 这样服务端获取到用户身份，并且可以使用
AccessToken获取其他服务。
小节
所以当前客户端都是使用 JAAS 进行认证，但根据不同的 SASL 设置具体的 jaas 文件。
ACL 授权
在 Kafka 中，有一个插入式的授权框架，只需要在 server.properties 中设置：
authorizer.class.name=kafka.security.authorizer.AclAuthorizer
# KRaft 使用如下配置
authorizer.class.name=org.apache.kafka.metadata.authorizer.StandardAuthorizer这个功能需要 SASL 作为前提，也就是 SASL 认证后知道连接集群的是谁，然后再在 ACL 中查找其是否有对应的权限。
这个功能说简单的话也挺简单，当使用 GSSAPI 时，直接针对每个 principal 主体进行配置即可。
当然当服务架构特别复杂时，也可以通过 RULE 进行设置：
RULE:^CN=(.*?),OU=ServiceUsers.*$/$1/,
RULE:^CN=(.*?),OU=(.*?),O=(.*?),L=(.*?),ST=(.*?),C=(.*?)$/$1@$2/L,
RULE:^.*[Cc][Nn]=([a-zA-Z0-9.]*).*$/$1/L,
DEFAULT当设置权限时，可以直接使用如下命令：
bin/kafka-acls.sh --bootstrap-server localhost:9092 --add --allow-principal User:Bob --allow-principal User:Alice --allow-host 198.51.100.0 --allow-host 198.51.100.1 --operation Read --operation Write --topic Test-topic
bin/kafka-acls.sh --bootstrap-server localhost:9092 --add --allow-principal User:'*' --allow-host '*' --deny-principal User:BadBob --deny-host 198.51.100.3 --operation Read --topic Test-topic
bin/kafka-acls.sh --bootstrap-server localhost:9092 --list --topic Test-topic第一条命令允许了 Bob 和 Alice 通过 198.51.100.[0-1] 访问 Test-topic，并拥有读写权限。
第二条命令允许所有用户和所有 ip 有读 Test-topic 的权限，但除了 BadBob 和 ip=198.51.100.3 的读权限。
第三条命令查看了当前所有关于 Test-topic 的认证配置。
所以 ACL 是基于 SASL 之上的授权框架，为 Kafka 自带。
SSL 连接协议
可能大多数朋友有从 http 过渡到 https 的感受，而这个 s 其实就是 SSL。
SSL 其实就是一种安全套接层协议 Secure Socket Layer，处于应用层之下，TCP 连接之上。这里我们并不研究 SSL 的详细解析，只需要了解 SSL 证书有一组 公钥 和 私钥，通过他们俩的加密解密配合，可以保证在数据传输过程中不被偷窥修改。
那么 Kafka 中为什么要使用他，就是因为 SASL 只解决了认证问题，ACL 解决授权问题，而数据在传输过程中没有更好的加密手段（虽然传输数据过程中不一定是明文，看序列化手段）。所以为了解决数据在传输中就算被恶意抓包监听，达到更高的安全性。
所以 SSL 解决了数据传输过程中的安全性问题。与 SASL、ACL 并无关联性。
Kafka security protocols
在 Kafka 中，一共有四种连接方式，分别是：PLAINTEXT、SSL、SASL_PLAINTEXT、SASL_SSL。
名字中带有 SSL 说明打开了 SSL，而带有 SASL 的说明打开了 SASL，而 PLAINTEXT 说明数据未加密传输，所以可以整理为以下表格：
ACL 授权在此没有体现，而是通过 authorizer.class.name 进行指定。
总结
一般来说，处于公网上的 Kafka 都需要打开 SASL_SSL 认证服务；SASL 和 SSL 并没有特定关联，一个是身份认证，一个是证书加密传输，可以分开配置，然后在客户端的 JAAS 文件中统一配置。
中文网上没有讲 Kafka 认证此类基础概念，看到很多人这方面基础薄弱，所以特此描述一下，如果解决了你心中的疑虑请点个赞。如果发现文章错误，请评论找博主进行修改，谢谢。
