Knox 接入 Trino web-ui 解决方案
# 一、问题背景：Kerberos 开启后 Trino Web UI 发生了什么变化
在 未开启 Kerberos 的情况下，Trino Web UI 使用的是传统的 Form 登录模式，浏览器直接访问即可完成认证并进入 UI 页面。
笔记
但在 开启 Kerberos 之后，Trino 的 Web UI 行为会发生本质变化：
认证方式由 FORM → KERBEROS
Web UI 强制依赖 SPNEGO
通信协议通常同时升级为 HTTPS
此时，浏览器如果直接访问 Trino Web UI，会发现页面无法正常展示，或者直接返回空白页面。
# 二、关于浏览器直连 Kerberos Web UI 的现实限制
理论上，浏览器并非完全无法访问 Kerberos Web UI。 只要在客户端安装 MIT Kerberos，并对浏览器进行 SPNEGO 相关配置，访问是可行的。
但在实际环境中，这条路径存在明显限制：
# 一）主机名的硬性要求
- Ambari / Trino 的主机名必须是 FQDN 形式（a.b.c）
- 类似
dev1 / dev2 / dev3这样的短主机名，即使浏览器配置齐全，访问成功率也极低
# 二）客户端维护成本过高
- 每个用户都需要安装 Kerberos 客户端
- 浏览器需要单独配置 SPNEGO 白名单
- HTTPS 证书信任、跨域、Cookie 策略问题频繁出现
实际结论
浏览器直连 Kerberos Web UI 不适合作为统一访问方案，尤其是在多用户、生产集群环境中。
# 三、统一思路：通过 Knox 代理 Trino Web UI
在已经部署 Knox 作为统一安全入口的前提下，引入 Knox 代理 Trino Web UI，是一条更可控的路径。
整体访问模型如下：
Browser → Knox → Trino (Kerberos + HTTPS)
- 浏览器仅访问 Knox
- Kerberos 认证逻辑由 Knox 承担
- Trino 仍保持 Kerberos + HTTPS 的安全形态
# 四、Trino 当前端口与访问现状分析
从 Trino 的服务配置中可以看到，其同时暴露了 HTTP 与 HTTPS 两个端口：
可以明确：
- HTTP 端口：
8380 - HTTPS 端口：
8443
当直接访问：
https://dev1:8443
页面呈现为空白，这并不是端口不可达，而是 当前访问主体未通过 Kerberos 认证。
# 五、Trino 侧配置调整（Kerberos + HTTPS）
# 一）PEM 证书准备
开启 Trino HTTPS 后，必须准备完整的证书文件：
trino.crttrino.keytrino.pem
其中 trino.pem 用作 Trino HTTPS 的 keystore。
# 二）config.properties 核心配置
coordinator=true
discovery.uri=http://dev1:8380
http-server.http.port=8380
http-server.https.enabled=true
http-server.https.port=8443
http-server.https.keystore.path=/etc/trino/conf/trino.pem
http-server.https.keystore.key=changeit
http-server.authentication.type=KERBEROS
http-server.authentication.krb5.service-name=HTTP
http-server.authentication.krb5.keytab=/etc/security/keytabs/spnego.service.keytab
http.authentication.krb5.config=/etc/krb5.conf
http-server.process-forwarded=true
http-server.log.path=/var/log/trino/http-request.log
internal-communication.https.required=false
internal-communication.shared-secret=trino
node-scheduler.include-coordinator=true
query.max-memory=2GB
query.max-memory-per-node=1GB
spill-enabled=false
spiller-spill-path=/data/trino/spill
plugin.dir=/usr/bigtop/current/trino/plugins
web-ui.authentication.type=KERBEROS
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
说明
http-server.process-forwarded=true 在 Knox 场景下非常关键，用于正确处理反向代理带来的 Header 信息。
# 六、Knox 侧配置：信任 Trino HTTPS
# 一）gateway-site.xml
gateway.httpclient.truststore.password.alias=trino-httpclient-truststore-pwd
gateway.httpclient.truststore.path=/usr/bigtop/current/knox-server/data/security/keystores/trino-trust.jks
gateway.httpclient.truststore.type=JKS
2
3
# 二）Topology 中新增 Trino UI Service
<service>
<role>TRINOUI</role>
<url>http://dev1:8380</url>
</service>
2
3
4
5
# 七、【关键步骤】构建 truststore 与 Credential Store
# 一）导入 Trino 证书
MASTER=$(sudo -u knox cat /usr/bigtop/current/knox-server/data/security/master)
sudo keytool -importcert -alias trino-dev1 \
-file /etc/trino/conf/trino.crt \
-keystore /usr/bigtop/current/knox-server/data/security/keystores/trino-trust.jks \
-storepass "$MASTER" \
-noprompt
2
3
4
5
6
7
# 二）创建 alias
sudo -u knox /usr/bigtop/current/knox-server/bin/knoxcli.sh create-alias \
trino-httpclient-truststore-pwd --cluster __gateway --value "$MASTER"
2
查看：
sudo -u knox /usr/bigtop/current/knox-server/bin/knoxcli.sh list-alias \
--cluster __gateway
2
温馨提示
完成所有操作后，需要 重启 knox服务
# 八、通过 Knox 访问 Trino Web UI
点击 Knox 页面中的 Trino 入口后，即可进入 Trino Web UI：
# 九、Trino 474 与 Knox 2.1.0 的适配说明
当前使用的 Trino 版本为 474，而 Knox 2.1.0 默认并未内置 Trino 的 UI 资源与定义。
因此需要额外进行适配，包括：
- 增加 Trino UI 图标
- 补充 Service 定义
- 调整前端资源路径
适配细节可参考： Knox 2.1.0 适配 Trino 474