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 或者指定靜態(tài) 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 集群驗證身份是否正確讓其訪問服務。

這種方式是在環(huán)境中已經擁有Kerberos 認證時的最優(yōu)解。

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。這樣的定義簡單卻不方便，因為在添加或者刪除用戶時需要重啟集群，所以在生產中基本不能使用。當然可以二次開發(fā)，但也不推薦。

SASL/SCRAM 對 PLAIN 進行升級，將賬號數據存儲在 ZK 中

SCARM 其實也是賬號密碼認證機制，但是數據存儲在 zookeeper 中，這樣使得可以動態(tài)增加刪除用戶。生產環(huán)境中可以使用這種方式，但記住最好開啟 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

上面創(chuàng)建了 admin 和 alice 用戶，并且設定了對應的密碼，最后一條命令刪除了 alice 用戶。

SASL/OAUTHBEARER

基于 OAUTH2.0 的認證框架，這里需要 OATH2 框架進行認證。

相關認證還有 LDAP，SSO，CAS，OIDC，SAML2 等等。

具體流程一般為：

1. 訪問服務時將跳轉到 Authing 進行認證。
2. 認證完畢后服務會獲取到 Authing 發(fā)來的授權碼，這里再次和 Authing 進行交互獲取 AccessToken。
3. 這樣服務端獲取到用戶身份，并且可以使用 AccessToken 獲取其他服務。

小節(jié)

所以當前客戶端都是使用 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 連接協(xié)議

可能大多數朋友有從 http 過渡到 https 的感受，而這個 s 其實就是 SSL。

SSL 其實就是一種安全套接層協(xié)議 Secure Socket Layer，處于應用層之下，TCP 連接之上。這里我們并不研究 SSL 的詳細解析，只需要了解 SSL 證書有一組 公鑰 和 私鑰，通過他們倆的加密解密配合，可以保證在數據傳輸過程中不被偷窺修改。

那么 Kafka 中為什么要使用他，就是因為 SASL 只解決了認證問題，ACL 解決授權問題，而數據在傳輸過程中沒有更好的加密手段（雖然傳輸數據過程中不一定是明文，看序列化手段）。所以為了解決數據在傳輸中就算被惡意抓包監(jiān)聽，達到更高的安全性。

所以 SSL 解決了數據傳輸過程中的安全性問題。與 SASL、ACL 并無關聯(lián)性。

Kafka security protocols

在 Kafka 中，一共有四種連接方式，分別是：PLAINTEXT、SSL、SASL_PLAINTEXT、SASL_SSL。

名字中帶有 SSL 說明打開了 SSL，而帶有 SASL 的說明打開了 SASL，而 PLAINTEXT 說明數據未加密傳輸，所以可以整理為以下表格：

ACL 授權在此沒有體現(xiàn)，而是通過 authorizer.class.name 進行指定。

總結

一般來說，處于公網上的 Kafka 都需要打開 SASL_SSL 認證服務；SASL 和 SSL 并沒有特定關聯(lián)，一個是身份認證，一個是證書加密傳輸，可以分開配置，然后在客戶端的 JAAS 文件中統(tǒng)一配置。

中文網上沒有講 Kafka 認證此類基礎概念，看到很多人這方面基礎薄弱，所以特此描述一下，如果解決了你心中的疑慮請點個贊。如果發(fā)現(xiàn)文章錯誤，請評論找博主進行修改，謝謝。

推

如果覺得還行，需要嘗試進行部署，請?zhí)D到：
Kafka3.4 SASL/kerberos/ACL 證以及 SSL 加密連接文章來源地址http://www.zghlxwxcb.cn/news/detail-618216.html

到了這里，關于Kafka 中 SASL ACL SSL 到底分別代表什么意思的文章就介紹完了。如果您還想了解更多內容，請在右上角搜索TOY模板網以前的文章或繼續(xù)瀏覽下面的相關文章，希望大家以后多多支持TOY模板網！