极客时间已完结课程限时免费阅读

34 | 云环境下的授权该怎么做？

34 | 云环境下的授权该怎么做？-极客时间

34 | 云环境下的授权该怎么做？

2019-08-20 胡夕 来自北京
《Kafka核心技术与实战》
课程介绍

讲述：胡夕

时长12:39大小11.58M

你好，我是胡夕。今天我要分享的主题是：Kafka 的授权机制。

什么是授权机制？

我们在上一讲中花了不少时间讨论 Kafka 的认证机制，今天我们来看看 Kafka 的授权机制（Authorization）。所谓授权，一般是指对与信息安全或计算机安全相关的资源授予访问权限，特别是存取控制。
具体到权限模型，常见的有四种。
ACL：Access-Control List，访问控制列表。
RBAC：Role-Based Access Control，基于角色的权限控制。
ABAC：Attribute-Based Access Control，基于属性的权限控制。
PBAC：Policy-Based Access Control，基于策略的权限控制。
在典型的互联网场景中，前两种模型应用得多，后面这两种则比较少用。
ACL 模型很简单，它表征的是用户与权限的直接映射关系，如下图所示：
而 RBAC 模型则加入了角色的概念，支持对用户进行分组，如下图所示：
Kafka 没有使用 RBAC 模型，它用的是 ACL 模型。简单来说，这种模型就是规定了什么用户对什么资源有什么样的访问权限。我们可以借用官网的一句话来统一表示这种模型：“Principal P is [Allowed/Denied] Operation O From Host H On Resource R.” 这句话中出现了很多个主体，我来分别解释下它们的含义。
Principal：表示访问 Kafka 集群的用户。
Operation：表示一个具体的访问类型，如读写消息或创建主题等。
Host：表示连接 Kafka 集群的客户端应用程序 IP 地址。Host 支持星号占位符，表示所有 IP 地址。
Resource：表示 Kafka 资源类型。如果以最新的 2.3 版本为例，Resource 共有 5 种，分别是 TOPIC、CLUSTER、GROUP、TRANSACTIONALID 和 DELEGATION TOKEN。
当前，Kafka 提供了一个可插拔的授权实现机制。该机制会将你配置的所有 ACL 项保存在 ZooKeeper 下的 /kafka-acl 节点中。你可以通过 Kafka 自带的 kafka-acls 脚本动态地对 ACL 项进行增删改查，并让它立即生效。

如何开启 ACL？

在 Kafka 中，开启 ACL 的方法特别简单，你只需要在 Broker 端的配置文件中增加一行设置即可，也就是在 server.properties 文件中配置下面这个参数值：
authorizer.class.name=kafka.security.auth.SimpleAclAuthorizer
authorizer.class.name 参数指定了 ACL 授权机制的实现类。当前 Kafka 提供了 Authorizer 接口，允许你实现你自己的授权机制，但更常见的做法，还是直接使用 Kafka 自带的 SimpleAclAuthorizer 实现类。一旦设置好这个参数的值，并且启动 Broker 后，该 Broker 就默认开启了 ACL 授权验证。在实际生产环境中，你需要为集群中的每台 Broker 都做此设置。

超级用户（Super User）

在开启了 ACL 授权之后，你还必须显式地为不同用户设置访问某项资源的权限，否则，在默认情况下，没有配置任何 ACL 的资源是不能被访问的。不过，这里也有一个例外：超级用户能够访问所有的资源，即使你没有为它们设置任何 ACL 项。
那么，我们如何在一个 Kafka 集群中设置超级用户呢？方法很简单，只需要在 Broker 端的配置文件 server.properties 中，设置 super.users 参数即可，比如：
super.users=User:superuser1;User:superuser2
注意，如果你要一次性指定多个超级用户，那么分隔符是分号而不是逗号，这是为了避免出现用户名中包含逗号从而无法分割的问题。
除了设置 super.users 参数，Kafka 还支持将所有用户都配置成超级用户的用法。如果我们在 server.properties 文件中设置 allow.everyone.if.no.acl.found=true，那么所有用户都可以访问没有设置任何 ACL 的资源。不过，我个人不太建议进行这样的设置。毕竟，在生产环境中，特别是在那些对安全有较高要求的环境中，采用白名单机制要比黑名单机制更加令人放心。

kafka-acls 脚本

在了解了 Kafka 的 ACL 概念之后，我们来看一下如何设置它们。当前在 Kafka 中，配置授权的方法是通过 kafka-acls 脚本。举个例子，如果我们要为用户 Alice 增加了集群级别的所有权限，那么我们可以使用下面这段命令。
$ kafka-acls --authorizer-properties zookeeper.connect=localhost:2181 --add --allow-principal User:Alice --operation All --topic '*' --cluster
在这个命令中，All 表示所有操作，topic 中的星号则表示所有主题，指定 --cluster 则说明我们要为 Alice 设置的是集群权限。
这个脚本的参数有很多，我们再来看看它的另一个常见用法。
$ bin/kafka-acls --authorizer-properties zookeeper.connect=localhost:2181 --add --allow-principal User:'*' --allow-host '*' --deny-principal User:BadUser --deny-host 10.205.96.119 --operation Read --topic test-topic
User 后面的星号表示所有用户，allow-host 后面的星号则表示所有 IP 地址。这个命令的意思是，允许所有的用户使用任意的 IP 地址读取名为 test-topic 的主题数据，同时也禁止 BadUser 用户和 10.205.96.119 的 IP 地址访问 test-topic 下的消息。
kafka-acls 脚本还有其他的功能，比如删除 ACL、查询已有 ACL 等。它们的实际用法与上面这条命令类似，我在这里就不一一列举了，你可以使用 kafka-acls.sh 来查询它的所有用法。

ACL 权限列表

刚才的这两条命令，分别涉及了主题的集群权限和读权限。你可能会问，Kafka 到底提供了多少种 ACL 权限呢？我们一起来看看下面这张表格，它完整地展示了 Kafka 所有的 ACL 权限。
看到这么大一张表格，你是不是很惊讶？其实，这恰好证明 Kafka 当前提供的授权机制是非常细粒度的。现在，我来跟你分享一下这个表格的使用方法。
举个例子，假如你要为你的生产者程序赋予写权限，那么首先，你要在 Resource 列找到 Topic 类型的权限，然后在 Operation 列寻找 WRITE 操作权限。这个 WRITE 权限是限制 Producer 程序能否向对应主题发送消息的关键。通常情况下，Producer 程序还可能有创建主题、获取主题数据的权限，所以 Kafka 为 Producer 需要的这些常见权限创建了快捷方式，即 --producer。也就是说，在执行 kafka-acls 命令时，直接指定 --producer 就能同时获得这三个权限了。 --consumer 也是类似的，指定 --consumer 可以同时获得 Consumer 端应用所需的权限。

授权机制能否单独使用？

关于授权，有一个很常见的问题是，Kafka 授权机制能不配置认证机制而单独使用吗？其实，这是可以的，只是你只能为 IP 地址设置权限。比如，下面这个命令会禁止运行在 127.0.0.1IP 地址上的 Producer 应用向 test 主题发送数据：
$ bin/kafka-acls.sh --authorizer-properties zookeeper.connect=localhost:2181 --add --deny-principal User:* --deny-host 127.0.0.1 --operation Write --topic test
$ bin/kafka-console-producer.sh --broker-list localhost:9092 --topic test
>hello
[2019-07-16 10:10:57,283] WARN [Producer clientId=console-producer] Error while fetching metadata with correlation id 3 : {test=TOPIC_AUTHORIZATION_FAILED} (org.apache.kafka.clients.NetworkClient)
[2019-07-16 10:10:57,284] ERROR [Producer clientId=console-producer] Topic authorization failed for topics [test] (org.apache.kafka.clients.Metadata)
[2019-07-16 10:10:57,284] ERROR Error when sending message to topic test with key: null, value: 5 bytes with error: (org.apache.kafka.clients.producer.internals.ErrorLoggingCallback)
org.apache.kafka.common.errors.TopicAuthorizationException: <span class="orange">Not authorized to access topics: [test]
</span class="orange">
请注意一下输出中的橙色字体部分。虽然没有设置任何认证机制，但是通过设置 IP 地址的 ACL 授权，我们依然可以禁止这些 IP 地址上的客户端访问 Kafka 资源。不过，尽管授权机制能够有限度地单独使用，但我更推荐的做法是，和我们在专栏上一讲提到的认证机制搭配使用。
接下来，我来给出一个 SSL + ACL 配置的实例，来演示一下云环境下的 ACL 授权应该怎么做。

配置实例

在演示 ACL 之前，我先简单说一下 SSL 的配置。我给出一个 SHELL 脚本，它可以方便你设置 SSL，代码如下：
#!/bin/bash
#设置环境变量
BASE_DIR=/Users/huxi/testenv #你需要修改此处
CERT_OUTPUT_PATH="$BASE_DIR/certificates"
PASSWORD=test1234
KEY_STORE="$CERT_OUTPUT_PATH/server.keystore.jks"
TRUST_STORE="$CERT_OUTPUT_PATH/server.truststore.jks"
CLIENT_KEY_STORE="$CERT_OUTPUT_PATH/client.keystore.jks"
CLIENT_TRUST_STORE="$CERT_OUTPUT_PATH/client.truststore.jks"
KEY_PASSWORD=$PASSWORD
STORE_PASSWORD=$PASSWORD
TRUST_KEY_PASSWORD=$PASSWORD
TRUST_STORE_PASSWORD=$PASSWORD
CERT_AUTH_FILE="$CERT_OUTPUT_PATH/ca-cert"
DAYS_VALID=365
DNAME="CN=Xi Hu, OU=YourDept, O=YourCompany, L=Beijing, ST=Beijing, C=CN"
mkdir -p $CERT_OUTPUT_PATH
echo "1. 产生key和证书......"
keytool -keystore $KEY_STORE -alias kafka-server -validity $DAYS_VALID -genkey -keyalg RSA \
-storepass $STORE_PASSWORD -keypass $KEY_PASSWORD -dname "$DNAME"
keytool -keystore $CLIENT_KEY_STORE -alias kafka-client -validity $DAYS_VALID -genkey -keyalg RSA \
-storepass $STORE_PASSWORD -keypass $KEY_PASSWORD -dname "$DNAME"
echo "2. 创建CA......"
openssl req -new -x509 -keyout $CERT_OUTPUT_PATH/ca-key -out "$CERT_AUTH_FILE" -days "$DAYS_VALID" \
-passin pass:"$PASSWORD" -passout pass:"$PASSWORD" \
-subj "/C=CN/ST=Beijing/L=Beijing/O=YourCompany/OU=YourDept,CN=Xi Hu"
echo "3. 添加CA文件到broker truststore......"
keytool -keystore "$TRUST_STORE" -alias CARoot \
-importcert -file "$CERT_AUTH_FILE" -storepass "$TRUST_STORE_PASSWORD" -keypass "$TRUST_KEY_PASS" -noprompt
echo "4. 添加CA文件到client truststore......"
keytool -keystore "$CLIENT_TRUST_STORE" -alias CARoot \
-importcert -file "$CERT_AUTH_FILE" -storepass "$TRUST_STORE_PASSWORD" -keypass "$TRUST_KEY_PASS" -noprompt
echo "5. 从keystore中导出集群证书......"
keytool -keystore "$KEY_STORE" -alias kafka-server -certreq -file "$CERT_OUTPUT_PATH/server-cert-file" \
-storepass "$STORE_PASSWORD" -keypass "$KEY_PASSWORD" -noprompt
keytool -keystore "$CLIENT_KEY_STORE" -alias kafka-client -certreq -file "$CERT_OUTPUT_PATH/client-cert-file" \
-storepass "$STORE_PASSWORD" -keypass "$KEY_PASSWORD" -noprompt
echo "6. 使用CA签发证书......"
openssl x509 -req -CA "$CERT_AUTH_FILE" -CAkey $CERT_OUTPUT_PATH/ca-key -in "$CERT_OUTPUT_PATH/server-cert-file" \
-out "$CERT_OUTPUT_PATH/server-cert-signed" -days "$DAYS_VALID" -CAcreateserial -passin pass:"$PASSWORD"
openssl x509 -req -CA "$CERT_AUTH_FILE" -CAkey $CERT_OUTPUT_PATH/ca-key -in "$CERT_OUTPUT_PATH/client-cert-file" \
-out "$CERT_OUTPUT_PATH/client-cert-signed" -days "$DAYS_VALID" -CAcreateserial -passin pass:"$PASSWORD"
echo "7. 导入CA文件到keystore......"
keytool -keystore "$KEY_STORE" -alias CARoot -import -file "$CERT_AUTH_FILE" -storepass "$STORE_PASSWORD" \
-keypass "$KEY_PASSWORD" -noprompt
keytool -keystore "$CLIENT_KEY_STORE" -alias CARoot -import -file "$CERT_AUTH_FILE" -storepass "$STORE_PASSWORD" \
-keypass "$KEY_PASSWORD" -noprompt
echo "8. 导入已签发证书到keystore......"
keytool -keystore "$KEY_STORE" -alias kafka-server -import -file "$CERT_OUTPUT_PATH/server-cert-signed" \
-storepass "$STORE_PASSWORD" -keypass "$KEY_PASSWORD" -noprompt
keytool -keystore "$CLIENT_KEY_STORE" -alias kafka-client -import -file "$CERT_OUTPUT_PATH/client-cert-signed" \
-storepass "$STORE_PASSWORD" -keypass "$KEY_PASSWORD" -noprompt
echo "9. 删除临时文件......"
rm "$CERT_OUTPUT_PATH/ca-cert.srl"
rm "$CERT_OUTPUT_PATH/server-cert-signed"
rm "$CERT_OUTPUT_PATH/client-cert-signed"
rm "$CERT_OUTPUT_PATH/server-cert-file"
rm "$CERT_OUTPUT_PATH/client-cert-file"
你可以把上面的代码保存成一个 SHELL 脚本，然后在一台 Broker 上运行。该脚本主要的产出是 4 个文件，分别是：server.keystore.jks、server.truststore.jks、client.keystore.jks 和 client.truststore.jks。
你需要把以 server 开头的两个文件，拷贝到集群中的所有 Broker 机器上，把以 client 开头的两个文件，拷贝到所有要连接 Kafka 集群的客户端应用程序机器上。
接着，你要配置每个 Broker 的 server.properties 文件，增加以下内容：
listeners=SSL://localhost:9093
ssl.truststore.location=/Users/huxi/testenv/certificates/server.truststore.jks
ssl.truststore.password=test1234
ssl.keystore.location=/Users/huxi/testenv/certificates/server.keystore.jks
ssl.keystore.password=test1234
security.inter.broker.protocol=SSL
ssl.client.auth=required
ssl.key.password=test1234
现在我们启动 Broker 进程。倘若你发现无法启动或启动失败，那么你需要检查一下报错信息，看看和上面的哪些配置有关，然后有针对性地进行调整。接下来，我们来配置客户端的 SSL。
首先，我们要创建一个名为 client-ssl.config 的文件，内容如下：
security.protocol=SSL
ssl.truststore.location=/Users/huxi/testenv/certificates/client.truststore.jks
ssl.truststore.password=test1234
ssl.keystore.location=/Users/huxi/testenv/certificates/server.keystore.jks
ssl.keystore.password=test1234
ssl.key.password=test1234
ssl.endpoint.identification.algorithm=
注意，一定要加上最后一行。因为自 Kafka 2.0 版本开始，它默认会验证服务器端的主机名是否匹配 Broker 端证书里的主机名。如果你要禁掉此功能的话，一定要将该参数设置为空字符串。
配置好这些，你可以使用 ConsoleConsumer 和 ConsoleProducer 来测试一下 Producer 和 Consumer 是否能够正常工作。比如，下列命令指定 producer-config 指向刚才我们创建的 client-ssl 配置文件。
$ bin/kafka-console-producer.sh --broker-list localhost:9093 --topic test --producer.config client-ssl.config
好了，现在我们来说说 ACL 的配置。
如果你在运营一个云上的 Kafka 集群，那么势必会面临多租户的问题。除了设置合理的认证机制外，为每个连接 Kafka 集群的客户端授予恰当的权限，也是非常关键的。现在我来给出一些最佳实践。
第一，就像前面说的，要开启 ACL，你需要设置 authorizer.class.name=kafka.security.auth.SimpleAclAuthorizer。
第二，我建议你采用白名单机制，这样的话，没有显式设置权限的用户就无权访问任何资源。也就是说，在 Kafka 的 server.properties 文件中，不要设置 allow.everyone.if.no.acl.found=true。
第三，你可以使用 kafka-acls 脚本为 SSL 用户授予集群的权限。我们以前面的例子来进行一下说明。
在配置 SSL 时，我们指定用户的 Distinguished Name 为“CN=Xi Hu, OU=YourDept, O=YourCompany, L=Beijing, ST=Beijing, C=CN”。之前在设置 Broker 端参数时，我们指定了 security.inter.broker.protocol=SSL，即强制指定 Broker 间的通讯也采用 SSL 加密。
如果不为指定的 Distinguished Name 授予集群操作的权限，你是无法成功启动 Broker 的。因此，你需要在启动 Broker 之前执行下面的命令：
$ bin/kafka-acls.sh --authorizer-properties zookeeper.connect=localhost:2181 --add --allow-principal User:"CN=Xi Hu,OU=YourDept,O=YourCompany,L=Beijing,ST=Beijing,C=CN" --operation All --cluster
第四，你要为客户端程序授予相应的权限，比如为生产者授予 producer 权限，为消费者授予 consumer 权限。假设客户端要访问的主题名字是 test，那么命令如下：
$ bin/kafka-acls.sh --authorizer-properties zookeeper.connect=localhost:2181 --add --allow-principal User:"CN=Xi Hu,OU=YourDept,O=YourCompany,L=Beijing,ST=Beijing,C=CN" --producer --topic 'test'
$ bin/kafka-acls.sh --authorizer-properties zookeeper.connect=localhost:2181 --add --allow-principal User:"CN=Xi Hu,OU=YourDept,O=YourCompany,L=Beijing,ST=Beijing,C=CN" --consumer --topic 'test' --group '*'
注意这两条命令中的 --producer 和 --consumer，它们类似于一个快捷方式，直接将 Producer 和 Consumer 常用的权限进行了一次性的授予。
作为云环境 PaaS 管理员，除了以上这些必要的权限，你最好不要把其他权限授予客户端，比如创建主题的权限。总之，你授予的权限越少，你的 Kafka 集群就越安全。

小结

讲到这里，我们就完整地把 Kafka 授权机制梳理了一遍。除此之外，我还附赠了 SSL 端配置方法。希望你能将这两讲关于安全配置的内容结合起来学习，打造一个超级安全的 Kafka 集群。

开放讨论

Kafka 提供的权限有很多种，我们今天讨论的内容只覆盖了其中最重要的几个权限。如果要让一个客户端能够查询消费者组的提交位移数据，你觉得应该授予它什么权限？
欢迎写下你的思考和答案，我们一起讨论。如果你觉得有所收获，也欢迎把文章分享给你的朋友。
分享给需要的人，Ta购买本课程，你将得20元
生成海报并分享

赞 7

提建议

© 版权归极客邦科技所有，未经许可不得传播售卖。 页面已增加防盗追踪，如有侵权极客邦将依法追究其法律责任。
上一篇
33 | Kafka认证机制用哪家？
下一篇
35 | 跨集群备份解决方案MirrorMaker
unpreview
 写留言

精选留言(20)

  • J.Smile
    2020-06-20
    思考题：应该是消费者端的TOPIC的WRITE权限

    作者回复: 👍

    5
  • James
    2020-07-04
    为啥是消费者端的TOPIC的WRITE权限

    作者回复: 源码规定的

    4
  • 拈花微笑
    2019-08-20
    老师,我今天在idea下搭建kafka源码,准备研究一下,gradle编译过了,但在idea里编译不过,在client对应的项目报这个错:Error:(19, 39) java: 程序包org.apache.kafka.common.message不存在. kafka源码版本是V2.3.0, scala的版本是2.12.7,源码缺失了mesage,怎么解决? 我试了V2.2.1版本,仍然是一样的问题.

    作者回复: 嗯嗯，新版kafka将request和response的格式类改成自动生成了。你可以运行在Kafka源码目录下运行./gradlew重新生成一遍，然后再导入到IDEA

    共 3 条评论
    3
  • 老陈的空酒桶
    2020-03-30
    你好，胡夕老师，kafka_version=2.12.2.3.0，使用的授权方式是SASL_PLAINTEXT，在config/server.properties配置allow.everyone.if.no.acl.found=true，使用未设置权限的topic，发送消息，会有授权失败的日志。 日志如下： SocketServer brokerId=0] Failed authentication with /10.192.0.1 (Unexpected Kafka request of type METADATA during SASL handshake.) (org.apache.kafka.common.network.Selector) 针对此问题，老师回答需要赋值METADATA请求的权限，能问一下具体是配置什么呢？
    展开

    作者回复: 试试TOPIC的DESCRIBE权限

    2
  • 咸淡一首诗
    2020-03-14
    胡老师，ACL 权限列表中的三列 Operation，Resource，API没有明白具体什么意思，比如： READ Topic Fetch READ Topic OffsetCommit READ Topic TxnOffsetCommit 这三个READ 只有API 列不同，有什么区别，他们怎么与命令行参数匹配和使用的？
    展开

    作者回复: 这表示Fetch、OffsetCommit和TnxOffsetCommit请求需要Topic的READ权限

    2
  • 花开漫夏
    2020-02-19
    胡老师您好，上文 SASL 和本文的 SSL + ACL 方案如何选择？

    作者回复: SASL是做认证的，本文的SSL+ACL主要是授权。它们是两回事，不矛盾的。当然你可以选择SASL+ACL

    2
  • 13761642169
    2019-08-26
    你好，胡夕老师，kafka_version=2.12.2.3.0，使用的授权方式是SASL_PLAINTEXT，在config/server.properties配置allow.everyone.if.no.acl.found=true，使用未设置权限的topic，发送消息，会有授权失败的日志。 日志如下： SocketServer brokerId=0] Failed authentication with /10.192.0.1 (Unexpected Kafka request of type METADATA during SASL handshake.) (org.apache.kafka.common.network.Selector)
    展开

    作者回复: 需要赋值METADATA请求的权限

    共 5 条评论
    2
  • Mick
    2019-10-09
    让一个客户端能够查询消费者组的提交位移数据: kafka-acls --authorizer-properties zookeeper.connect=localhost:2181 --add --allow-principal User:"CN=Xi Hu,OU=YourDept,O=YourCompany,L=Beijing,ST=Beijing,C=CN" --OffsetCommit --operation Read --group "group_id" 老师不知道这么写对不对？

    作者回复: 需要赋予Group的READ权限，因为READ权限自动包含OffsetCommit：）

    1
  • Geek_edc612
    2019-08-20
    不太懂最后这块的授权： bin/kafka-acls.sh --authorizer-properties zookeeper.connect=localhost:2181 --add --allow-principal User:"CN=Xi Hu,OU=YourDept,O=YourCompany,L=Beijing,ST=Beijing,C=CN" --consumer --topic 'test' --group '*' 为啥这个用户名这么长，这是授权的ssl的用户名吗？
    展开

    作者回复: 是的。这个是我用来演示的SSL用户

    1
  • 韦宁顺
    2021-08-18
    1.client-ssl.config 文件设置的是server，是不是错了？ ssl.keystore.location=/Users/huxi/testenv/certificates/server.keystore.jks 2.DNAME 是干嘛用的？ 是ssl用户？ 3.ssl 的用户从哪里来？比如想新增一个 writer用户？
    展开

    作者回复: 没有错。如果你要配置双向SSL，也就是客户端的认证，那么要加上

  • Richard123m
    2021-05-24
    Broker间用SSL或sasl，与不用相比，通信的速率会是多少，特别是多副本情况

    作者回复: 通常情况下认为性能会下降30~40￥

    共 2 条评论
  • 胡小禾
    2021-03-05
    bin/kafka-acls.sh --authorizer-properties zookeeper.connect=localhost:2181 --add --allow-principal User:Bob --producer --topic Test-topic 假如我不做认证，只使用这个命令来设置授权，起不到效果的吗？

    作者回复: 因为没有用户的概念，只能针对ip级别进行设置

  • lzh
    2020-11-28
    老师，请问keystore和truststore有没有什么区别啊，既生瑜何生亮？

    作者回复: 简单来说keystore用于保存你自己的身份验证信息，而truststore用于保存其他人的身份验证信息

  • Geek_02ab73
    2020-11-24
    老师，一直有个疑问？ openssl 生成的证书和Let's Encrypt 颁发给我们的有什么区别 1. Let's Encrypt 是每三个月到期，用来服务器公开HTTPS服务， 2. keystore + openssl 弄出来的SSL是用来做内部服务沟通的 不知道我理解的对不？

    作者回复: Let's Encrypt是一个免费的CA吧，它使用openssl生成证书并利用它自己的服务进行签发。

  • timmy21
    2020-10-01
    老师我们使用SASL+ACL做认证和权限，可是遇到“the client is not authorized to access this group”报错。奇怪的是python客户端（1.4.7以上）可以正常消费，可是Golang的sarama却报上面那个错，另外低版本的python客户端也报那个错。请问老师这可能是什么原因？

    作者回复: 是“the client is not authorized to access this group”还是“Not authorized to access group”？前者应该是客户端自己抛出来的，后面才是Kafka抛出来的。如果是前者的异常，那么多半是因为低版本的客户端不兼容当前Kafka版本

  • 张洋
    2020-07-08
    老师 按照这两节的配置 启动kafka 一直提示这个Error Connection to node 0 failed authentication due to :SSL handshake falied WaRN SSL handshake failed SSLHandshakeException: General SSLEngine problem

    作者回复: 可能的原因是ssl.endpoint.identification.algorithm设置成了https，开启了主机名验证。设置为空试试。

    1
  • 咸淡一首诗
    2020-03-14
    胡老师，“Kafka 授权机制能不配置认证机制而单独使用吗？其实，这是可以的，只是你只能为 IP 地址设置权限。”这句话不是很理解，为什么只能为IP 设置权限？除了ip权限不能设置其他权限吗？比如我开启了授权，没开启认证，我不能用kafka-acl 脚本设置--allow-principal User:'*' --allow-host '*' --operation All --topic '*' --cluster 吗？

    作者回复: 如果只有授权没有认证，那么你给谁授权呢？？

  • 钱
    2019-09-23
    打卡，记住：你授予的权限越少，你的 Kafka 集群就越安全。
    共 1 条评论
  • 许童童
    2019-08-20
    老师的小结很不错，跟着老师一起精进。
    共 1 条评论
  • Geek_edc612
    2019-08-20
    我看之前sasl-plain就是user Wrter这样授权用户，ssl的咋这么复杂。。。
    共 1 条评论