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

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

auth: huangyichun

date: 2023-5-11

看各类帖子都没能指出这些到底是什么意思,他们是冲突的,还是互相作用的,还是隔离的?本文讲解 kafkaSASLACLSSL 他们分别的作用以及含义。

SASL 身份认证

SASL 是用来认证 C/S 模式也就是服务器与客户端的一种认证机制,全称 Simple Authentication and Security Layer。通俗的话来讲就是让服务器知道连接进来的客户端的身份是谁。

比如凭借阅证到图书馆借书,而每个借阅证都有独立的 ID,通过 ID 定位谁是谁,而不是特别关心谁拿到了借阅证,只需要正确的借阅证即可。

这就是一种凭据认证方式。


再比如 登陆QQ,只需要账号密码即可,就可以用该 QQ 和朋友聊天等等。

这种是我们常见的账号密码认证方式。

所以 SASL 就是服务器存储了客户端的身份证书和如何校验密码是否正确,而且仅在于身份认证过程,认证完毕后即可进行相关的服务操作。

SASL 只是一种模式,需要依赖于具体的连接媒介,比如 JAAS客户端GSSAPI(Kerberos)PLAINSCRAM-SHA-256SCRAM-SHA-512OAuthBearer 等等。这里分别讲解一下他们的具体含义:

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";
};

比如上述文件就是定义了两个用户 adminalice,并且密码分别为 admin-secretalice-secret。这样的定义简单却不方便,因为在添加或者删除用户时需要重启集群,所以在生产中基本不能使用。当然可以二次开发,但也不推荐。

SASL/SCRAM 对 PLAIN 进行升级,将账号数据存储在 ZK 中

SCARM 其实也是账号密码认证机制,但是数据存储在 zookeeper 中,这样使得可以动态增加删除用户。生产环境中可以使用这种方式,但记住最好开启 zookeeper 的认证,如果 zookeeper 没开启认证那也是不行的。

分别有两种加密方法:SCRAM-SHA-256SCRAM-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

上面创建了 adminalice 用户,并且设定了对应的密码,最后一条命令删除了 alice 用户。

SASL/OAUTHBEARER

基于 OAUTH2.0 的认证框架,这里需要 OATH2 框架进行认证。

相关认证还有 LDAPSSOCASOIDCSAML2 等等。

具体流程一般为:

  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

第一条命令允许了 BobAlice 通过 198.51.100.[0-1] 访问 Test-topic,并拥有读写权限。

第二条命令允许所有用户和所有 ip 有读 Test-topic 的权限,但除了 BadBobip=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 解决了数据传输过程中的安全性问题。与 SASLACL 并无关联性。

Kafka security protocols

Kafka 中,一共有四种连接方式,分别是:PLAINTEXTSSLSASL_PLAINTEXTSASL_SSL

名字中带有 SSL 说明打开了 SSL,而带有 SASL 的说明打开了 SASL,而 PLAINTEXT 说明数据未加密传输,所以可以整理为以下表格:

ACL 授权在此没有体现,而是通过 authorizer.class.name 进行指定。

总结

一般来说,处于公网上的 Kafka 都需要打开 SASL_SSL 认证服务;SASLSSL 并没有特定关联,一个是身份认证,一个是证书加密传输,可以分开配置,然后在客户端的 JAAS 文件中统一配置。

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

你可能感兴趣的:(kafka,kafka,ssl,java,SASL,ACL)