Atlas Hook 消费 Kafka 报错：GroupAuthorizationException

一、问题现象 Kafka Consumer Group

Atlas 启动后，NotificationHookConsumer 线程持续报错，典型信息是：

• GroupAuthorizationException: Not authorized to access group: atlas
• 日志刷屏式重试，说明消费者在 加入/描述消费组阶段就被拒绝（还没进入稳定消费流程）

2026-01-24 18:12:22,523 [index-health-monitor] INFO [AtlasJanusGraphIndexClient.java:98] indexBackEnd=solr; isHealthy=true
2026-01-24 18:12:29,138 [NotificationHookConsumer thread-0] WARN [NotificationHookConsumer.java:635] Exception in NotificationHookConsumer
org.apache.kafka.common.errors.GroupAuthorizationException: Not authorized to access group: atlas
2026-01-24 18:12:40,642 [NotificationHookConsumer thread-0] WARN [NotificationHookConsumer.java:635] Exception in NotificationHookConsumer
org.apache.kafka.common.errors.GroupAuthorizationException: Not authorized to access group: atlas
2026-01-24 18:12:52,527 [index-health-monitor] INFO [AtlasJanusGraphIndexClient.java:98] indexBackEnd=solr; isHealthy=true
2026-01-24 18:12:52,646 [NotificationHookConsumer thread-0] WARN [NotificationHookConsumer.java:635] Exception in NotificationHookConsumer
org.apache.kafka.common.errors.GroupAuthorizationException: Not authorized to access group: atlas
2026-01-24 18:13:05,150 [NotificationHookConsumer thread-0] WARN [NotificationHookConsumer.java:635] Exception in NotificationHookConsumer
org.apache.kafka.common.errors.GroupAuthorizationException: Not authorized to access group: atlas
2026-01-24 18:13:18,153 [NotificationHookConsumer thread-0] WARN [NotificationHookConsumer.java:635] Exception in NotificationHookConsumer
org.apache.kafka.common.errors.GroupAuthorizationException: Not authorized to access group: atlas
2026-01-24 18:13:22,532 [index-health-monitor] INFO [AtlasJanusGraphIndexClient.java:98] indexBackEnd=solr; isHealthy=true
2026-01-24 18:13:31,656 [NotificationHookConsumer thread-0] WARN [NotificationHookConsumer.java:635] Exception in NotificationHookConsumer
org.apache.kafka.common.errors.GroupAuthorizationException: Not authorized to access group: atlas
2026-01-24 18:13:45,659 [NotificationHookConsumer thread-0] WARN [NotificationHookConsumer.java:635] Exception in NotificationHookConsumer
org.apache.kafka.common.errors.GroupAuthorizationException: Not authorized to access group: atlas
2026-01-24 18:13:52,536 [index-health-monitor] INFO [AtlasJanusGraphIndexClient.java:98] indexBackEnd=solr; isHealthy=true
2026-01-24 18:14:00,162 [NotificationHookConsumer thread-0] WARN [NotificationHookConsumer.java:635] Exception in Notifi

现象要点

• 报错资源是 GROUP（consumer group），不是 TOPIC。
• 只要 group 被拒绝，客户端会在 JoinGroup/DescribeGroup 等阶段失败，表现为线程持续重试、告警持续出现。
• 这类错误在 Atlas 侧常见伴随现象是：Hook 侧“看似在跑”，但事件消费链路不稳定或长期无有效消费。

二、先确认 Atlas 的 Kafka 配置入口 atlas-application.properties

Atlas 的 Kafka 客户端配置统一在：

/etc/atlas/conf/atlas-application.properties

核对思路

这里不去“猜策略”，先把基础事实确认清楚，后面每一步才不会跑偏：

1. Kafka 访问路径：Atlas 连接 Kafka 的入口（broker/zk）是否与当前集群一致。
2. 鉴权方式：是否启用 Kerberos（SASL/GSSAPI）以及 Atlas 客户端走的机制。
3. 客户端身份：Atlas 进程实际使用的 principal 必须与授权主体一致，否则策略配得再全也不会命中。

常见偏差点

• Atlas 服务配置里写的是 atlas/_HOST@REALM，但实际运行时落地到某台机器（例如 dev2）后，真实身份会变成 atlas/dev2@REALM。
• Ranger 里选用户时，如果授权给的是短名 atlas，但插件侧按 Kerberos principal 解析出来的主体不一致，也会造成“策略看着对，实际不生效”。

三、第一步尝试：用 kafka-acls.sh 直接补 Group ACL 原生 ACL

当日志直接提示 Not authorized to access group: atlas，优先补齐 consumer group=atlas 的 ACL，用来验证 Kafka 原生鉴权维度本身是否缺失。

这里给 atlas/dev2@TTBIGDATA.COM 添加 group=atlas 的 READ 与 DESCRIBE：

/usr/bigtop/current/kafka-broker/bin/kafka-acls.sh \
  --authorizer-properties zookeeper.connect=dev1:2181,dev2:2181,dev3:2181 \
  --add \
  --allow-principal "User:atlas/dev2@TTBIGDATA.COM" \
  --group atlas \
  --operation Read \
  --operation Describe
  
  
  
  ##  结果是
  [root@dev1 bin]# /usr/bigtop/current/kafka-broker/bin/kafka-acls.sh \
>   --authorizer-properties zookeeper.connect=dev1:2181,dev2:2181,dev3:2181 \
>   --add \
>   --allow-principal "User:atlas/dev2@TTBIGDATA.COM" \
>   --group atlas \
>   --operation Read \
>   --operation Describe
Adding ACLs for resource `ResourcePattern(resourceType=GROUP, name=atlas, patternType=LITERAL)`: 
        (principal=User:atlas/dev2@TTBIGDATA.COM, host=*, operation=READ, permissionType=ALLOW)
        (principal=User:atlas/dev2@TTBIGDATA.COM, host=*, operation=DESCRIBE, permissionType=ALLOW) 

Current ACLs for resource `ResourcePattern(resourceType=GROUP, name=atlas, patternType=LITERAL)`: 
        (principal=User:atlas/dev2@TTBIGDATA.COM, host=*, operation=READ, permissionType=ALLOW)
        (principal=User:atlas/dev2@TTBIGDATA.COM, host=*, operation=DESCRIBE, permissionType=ALLOW) 

关键现象

原生 ACL 显示已经成功添加且能查询到，但 Atlas 仍旧报 GroupAuthorizationException。 这说明问题已经不再是“Kafka 原生 ACL 没配”，而更像是被上层策略（Ranger）拦截导致的拒绝。

为什么这里仍然要走一遍 kafka-acls.sh

这一步的价值不在“最终靠它修复”，而在于把问题边界缩小到两类：

• 如果加完 ACL 就好了：说明 Kafka 的 authorizer 仍以原生 ACL 为主，后续只需要把 group 权限补齐即可。
• 如果 ACL 正确但仍拒绝：说明决策点不在原生 ACL（或原生 ACL 优先级不够），需要去 Ranger 侧找 deny 命中与策略缺口。

四、根因定位：Ranger 拒绝命中（Deny）策略拦截

进一步查看 Ranger 的审计/访问结果，发现拒绝命中很多（deny），并且与 Atlas 这条 consumer group 请求链路对得上。

根因结论

Kafka 权限由 Ranger 接管时，是否允许消费者加入/消费某个 consumer group，最终由 Ranger Kafka Service 的策略命中结果裁决。 因此即使 kafka-acls.sh 已经给 group=atlas 加了 READ/DESCRIBE，只要 Ranger 侧没有允许策略（或存在优先 deny），Atlas 仍会被拒绝。

这里的“拒绝”通常意味着什么

• 在 Ranger Kafka Service 中，缺少对 Consumer Group=atlas 的 allow 授权（最常见）
• 或者有更高优先级的 deny 覆盖了 allow（审计里会更直观）
• 或者授权对象不匹配（比如授权给 atlas 短名，但客户端主体实际是 atlas/dev2@REALM）

五、修复方案：新增 atlas 消费组授权策略 Ranger Policy

既然拒绝发生在 Ranger 侧，那么修复点也必须落在 Ranger 策略中：补齐 consumer group 维度的 allow 授权。

这里新增策略：atlas_consumergroup_atlas。

策略内容按下图填写：

1、策略填写要点

• 选择 atlas 用户
• Consumer Group 填 atlas
• Allow 条件选择：consume、describe

为什么是 consume + describe

• describe：消费者需要读取/描述消费组元数据（协调器、组成员、组状态），否则在 Join/Sync 阶段会失败。
• consume：允许实际消费行为与消费链路推进（包含持续拉取与位点推进的必要动作）。

2、策略生效与现象回归

修改完策略后，重启 atlas-server，报错消失；同时 Ranger 拒绝记录不再出现。

结果确认

• Atlas 侧 NotificationHookConsumer 不再刷 GroupAuthorizationException
• Ranger 审计中与 consumer group=atlas 相关的 deny 记录停止新增
• Hook 消费链路恢复后，Atlas 的 Kafka 消费线程进入稳定状态