TGI 网关模式下透传 Authorization 鉴权头实现多租户隔离的配置指南

TGI 网关模式下，多租户隔离通常依赖请求中携带的 Authorization 鉴权头识别客户端身份。本指南给出两种可落地的透传配置路径：网关完全透传、网关解析后注入租户标识，并说明各自适用场景与验证方法。

透传的核心是网关不修改、不剥离、不重写 Authorization 头。若网关只是反向代理，显式设置 proxy_set_header Authorization $http_authorization 即可；若网关自身要校验 token，建议把解析出的租户 ID 放入 X-Tenant-ID 头，同时保留原头给后端。验证以 curl -v 和后端日志为准，并注意避免在日志中泄露 token 内容。

适用场景与隔离目标

当多个业务方通过不同 API Key 或 JWT 调用同一个 TGI 端点，且后端需要按租户做模型路由、配额限制或计费区分时，网关必须把客户端身份信息完整送到 TGI 服务。这里的隔离目标不是让网关决定能调用哪个模型，而是让 TGI 或认证中间件能根据 Authorization 头内携带的租户信息进行判断。

网关透传 Authorization 配置（Nginx 示例）

以 Nginx 作为网关为例，关键是在 location 中显式设置透传头，避免被上层配置或插件覆盖：

location /v1/text-generation/ {
    proxy_pass http://tgi_service:8080;
    proxy_set_header Authorization $http_authorization;
    proxy_set_header X-Real-IP $remote_addr;
}

如果使用 Kubernetes Ingress 或云负载均衡，需要对应的重写注解允许“Authorization”头通过。有的网关默认会剥掉该头，因此透传动作需要明确写出来。

TGI 网关模式下透传 Authorization 鉴权头实现多租户隔离的配置指南

透传后如何落到多租户隔离

透传 Authorization 头只是第一步，后续有两种常见做法：

方案	适用场景	配置要点	风险
后端直接解析 Authorization	TGI 前已有统一认证服务，能根据 token 返回租户信息	网关原样转发，后端自行解密 token	token 若过期需要后端处理，网关无法感知
网关解析后注入 X-Tenant-ID	网关已经做了登录校验，想快速传递租户标识	网关用 JWT 等解析出租户 ID，写入新头传给 TGI	容易误用网关自身身份调用后端，或覆盖已有头

如果后端需要完整 JWT 做签名校验，建议保留原 Authorization 头，再额外注入 X-Tenant-ID；如果后端只关心租户 ID，可以只传租户头，但此时需要在网关层保证 token 已校验。

验证方式

使用 curl 带两个不同 token 请求，确认网关确实把 Authorization 头透传到了后端：

curl -v https://tgi.example.com/v1/text-generation \
  -H "Authorization: Bearer $TOKEN_A"

然后检查 TGI 后端日志，看收到的 Authorization 头是否与发送时一致。若采用网关注入方案，还需要检查 X-Tenant-ID 是否被设置，且不同租户的请求会得到不同响应（例如模型路由不同）。

风险与边界

不要在网关日志中输出 Authorization 头，否则会泄露长期有效的 token。如果网关在认证后自行向后端发起调用，切勿用网关自己的 service account 替代客户端身份，否则后端的租户隔离会全部失效。

多租户隔离是否真正生效，不完全取决于透传配置。后端必须读到了正确的身份，并根据该身份执行路由、限流或配额策略，透传只是前提条件。生产中建议先确认 TGI 侧是否已有租户解析能力，再决定网关需要透传还是注入，避免重复实现。