Kafka 中 SASL ACL SSL 到底分别代表什么意思

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="[email protected]";

所以 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 等等。

具体流程一般为：

1. 访问服务时将跳转到 Authing 进行认证。
2. 认证完毕后服务会获取到 Authing 发来的授权码，这里再次和 Authing 进行交互获取 AccessToken。
3. 这样服务端获取到用户身份，并且可以使用 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 认证此类基础概念，看到很多人这方面基础薄弱，所以特此描述一下，如果解决了你心中的疑虑请点个赞。如果发现文章错误，请评论找博主进行修改，谢谢。