HttpFS 负载均衡器 (Kerberos)

使用 HTTP SPNEGO（Negotiate 认证）的客户端会为其连接所用的主机名获取 Kerberos 服务票据。如果 HttpFS 只能通过负载均衡器访问，那么该主机名就是负载均衡器的 DNS 名称，而非各个 HttpFS 网关主机。除非每个 HttpFS 实例都配置为使用与客户端为负载均衡器所期望的同一个 HTTP 服务主体，否则请求都会以 401 Authentication required 失败。

直接访问单个 HttpFS 主机通常可以成功，因为默认主体与该主机匹配（例如 HTTP/<httpfs-hostname>@REALM）。而通过负载均衡器发起的相同 WebHDFS 调用则会失败，直到面向客户端的主体与 keytab 与负载均衡器的名称保持一致为止。

::: caution
在负载均衡器后运行 HttpFS 并配合 Kerberos 是一种有效的模式（类似于 HDFS HttpFS），但贵组织应在自身环境中验证整个链路——客户端、TLS、负载均衡器转发以及委托令牌。请将本页视为运维指导，而非产品认证清单。
:::

前提条件

负载均衡器有一个客户端在 URL 中使用的稳定 DNS 名称：<load-balancer-host>。
集群 Kerberos realm：<CLUSTER_REALM>（例如 EXAMPLE.COM）。
运行 HttpFS 进程的操作系统用户（通常是 hdfs）必须能够读取你所部署的 keytab 文件。

Kerberos 主体与 keytab

创建（或使用）一个采用标准 HTTP SPNEGO 形式的服务主体：

HTTP/<load-balancer-host>@<CLUSTER_REALM>
导出包含该主体的 keytab，并分发到每一台运行 Ozone HttpFS Gateway 的主机。在所有主机上使用相同的文件系统路径，这样同一段配置即可适用于全部主机。示例路径（你的环境可能不同）：

/var/lib/hadoop-ozone/keytabs/httpfs.keytab
导出 keytab 时，避免意外创建新的随机密钥版本（例如在 MIT Kerberos 中，向 keytab 添加已有密钥时使用 kadmin 的 ktadd 并加上 -norandkey，以使 KDC 的密钥版本与其他主机及客户端所预期的一致，请遵循你们的运维流程）。

配置（`httpfs-site.xml`）

将面向客户端的 HTTP Kerberos 主体与 keytab 设置为负载均衡器主体和已部署的 keytab。建议使用 Hadoop 的规范属性名称：

属性	值
`hadoop.http.authentication.kerberos.principal`	`HTTP/<load-balancer-host>@<CLUSTER_REALM>`
`hadoop.http.authentication.kerberos.keytab`	主机上 keytab 的路径（例如 `/var/lib/hadoop-ozone/keytabs/httpfs.keytab`）

示例片段：

<property>
  <name>hadoop.http.authentication.kerberos.principal</name>
  <value>HTTP/<load-balancer-host>@<CLUSTER_REALM></value>
</property>
<property>
  <name>hadoop.http.authentication.kerberos.keytab</name>
  <value>/var/lib/hadoop-ozone/keytabs/httpfs.keytab</value>
</property>

旧名称 httpfs.authentication.kerberos.principal 和 httpfs.authentication.kerberos.keytab 是相同设置的已弃用别名；新配置请优先使用 hadoop.http.authentication.kerberos.*。参考请见配置附录。

请在每一台 HttpFS Gateway 主机的 httpfs-site.xml 中应用这些设置，在每台主机的相同路径下部署 keytab，然后重启 HttpFS。

内部的 HttpFS 到 Ozone Manager 的认证（httpfs.hadoop.authentication.*）是独立的；本页只涉及客户端访问负载均衡器前的 HTTP 端点时所使用的认证。

单个负载均衡器后面的多个 HttpFS 实例

如果同一个 VIP 后面有多个 HttpFS 网关，它们在 HTTP 认证 Cookie 上的行为应当保持一致。请配置一个共享的签名密钥，使 hadoop-auth Cookie 能在任意实例上通过校验。参见配置附录中的 hadoop.http.authentication.signature.secret.file：配置附录。

TLS 与客户端

使用 Kerberos/SPNEGO 时，客户端与负载均衡器之间优先使用 HTTPS。当重定向从 HTTPS 转到 HTTP 时，某些客户端（包括 curl）无法正确执行认证握手，这可能会破坏 SPNEGO。
在负载均衡器上终止 TLS，然后到 HttpFS 后端使用 HTTP 或 HTTPS 是常见做法；请确保负载均衡器转发请求头和协议的方式与你的 HttpFS 和 TLS 设置兼容。

常见错误

主体（principal）错误：主体仍指向后端主机，而客户端使用的是负载均衡器的 DNS 名称。
Keytab 对运行 HttpFS 的用户不可读（例如权限或 SELinux 上下文问题）。
Realm 映射：负载均衡器主机名必须在 krb5.conf 中解析到正确的 realm（例如 [domain_realm]）。如果客户端无法获取 HTTP/<load-balancer-host>@<CLUSTER_REALM> 的服务票据，请启用跟踪日志（见下文），并在使用 SRV 记录时检查 KDC 和 DNS SRV 记录。
密钥版本不匹配：在未跨主机协调 kvno 的情况下重新导出 keytab。

调试

使用 export KRB5_TRACE=/dev/stdout 运行客户端，以跟踪票据请求和失败情况。
将直连 HttpFS 后端与通过负载均衡器的行为进行对比，以定位主机名和主体不匹配的问题。
检查 HttpFS 和负载均衡器的访问日志，查找反复出现的 401 响应和失败的 Negotiate 交换。

SPNEGO 如何看待负载均衡器

另请参阅

配置 Kerberos — HttpFS 相关的 Kerberos 属性概述
HttpFS Gateway — REST API 简介与示例