[Step5] 对齐 Ranger HA 的凭证处理不改报错
# 一、为什么必须写这一章
在完成 Ranger Admin 高可用 与 External URL 指向 Haproxy 之后，如果不继续处理 Kerberos 凭证问题，Ranger 相关访问 一定会出现异常。
必须说明
这一章不是“优化项”，而是必选项。 如果跳过，将直接导致 Ranger Admin 的 Kerberos / SPNEGO 认证失败。
# 二、默认 SPNEGO 配置的限制
# 2.1 Ambari 中的默认配置现状
在 Ranger 的 Kerberos 配置中，可以看到如下参数：
其中存在两个关键问题：
| 配置项 | 现状 | 说明 |
|---|---|---|
| ranger.spnego.kerberos.keytab | 不可修改 | Ambari UI 中被锁定 |
| ranger.spnego.kerberos.principal | * | 不符合 HA + 域名访问场景 |
注意
在 HA 场景下，Ranger Admin 是通过
http://ranger-ha.hadoop.com:16080
对外提供服务的，而默认生成的 xxxxx/主机名@REALM 凭证无法匹配该访问方式。
# 2.2 直接修改为什么不可行
- keytab 路径无法在 UI 中直接替换
- principal 使用通配符在 Kerberos 认证中不可控
- 强行修改配置文件，下一次 Ambari 刷新配置会被覆盖
因此，不能走“常规改配置”的思路。
# 三、回到源码层面的可用配置项
# 3.1 源码行为确认
回到 Ranger Admin 的源码层，可以看到对 HA 场景做了专门支持：
从源码逻辑可以确认：
关键结论
只要配置了：
ranger.ha.spnego.kerberos.keytab
Ranger Admin 在 HA 场景下，就会优先使用该 keytab，
从而绕过默认 ranger.spnego.kerberos.keytab 的限制。
# 四、确认 HA 使用的 HTTP Keytab
在前面步骤中，我们已经准备好了 HA 使用的 HTTP keytab 文件：
/etc/security/keytabs/rangerhttpha.service.keytab
1
# 4.1 查看 keytab 中的 principal
klist -kte /etc/security/keytabs/rangerhttpha.service.keytab
1
结果如下：
可以确认 keytab 中包含的 principal 为：
HTTP/[email protected]
1
该 principal 与 External URL 完全一致，符合 HA 场景预期。
# 五、配置 Ranger Admin 使用 HA SPNEGO 凭证
# 5.1 设置 HA 专用 keytab
在 Ambari → Ranger → Configs 中，新增或修改参数：
ranger.ha.spnego.kerberos.keytab
1
值设置为：
/etc/security/keytabs/rangerhttpha.service.keytab
1
如下图所示：
# 5.2 修正 SPNEGO principal
将原有的：
ranger.spnego.kerberos.principal = *
1
修改为：
HTTP/[email protected]
1
如下图所示：
# 5.3 保存并重启
保存配置后，Ambari 会提示有 2 个参数发生变更，直接点击重启即可。
# 六、配置生效验证
# 6.1 配置文件确认
重启完成后，可以在 Ranger Admin 节点上确认配置文件已生效：
/etc/ranger/admin/conf/ranger-admin-site.xml
1
可以看到：
- HA keytab 路径已写入
- SPNEGO principal 已指向 HA 域名
# 6.2 服务与访问状态
此时：
- Ranger Admin 可正常启动
- Ambari 可正常获取 Ranger Service
- 插件侧（如 HDFS）不再出现 Kerberos 认证异常
登录访问：
