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

认证此类基础概念，看到很多人这方面基础薄弱，所以特此描述一下，如果解决了你心中的疑虑请点个赞。如果发现文章错误，请评论找博主进行修改，谢谢。