一、問題背景：Kerberos 開啓後 Trino Web UI 發生了什麼變化

代碼已經提交到github：Ttbigdata

在 未開啓 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.crt
• trino.key
• trino.pem

其中 trino.pem 用作 Trino HTTPS 的 keystore。

PEM 生成過程可參考： Trino啓動-缺失PEM證書處理

二）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

説明 http-server.process-forwarded=true 在 Knox 場景下非常關鍵，用於正確處理反向代理帶來的 Header 信息。

Ambari啓動服務時，會自動渲染配置文件，生產環境下我們如何修改呢？可以參考閲讀 適用於生產—— Trino啓動-配置模板

六、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

二）Topology 中新增 Trino UI Service

<service>
    <role>TRINOUI</role>
    <url>http://dev1:8380</url>
</service>

七、【關鍵步驟】構建 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

二）創建 alias

sudo -u knox /usr/bigtop/current/knox-server/bin/knoxcli.sh create-alias \
  trino-httpclient-truststore-pwd --cluster __gateway --value "$MASTER"

查看：

sudo -u knox /usr/bigtop/current/knox-server/bin/knoxcli.sh list-alias \
  --cluster __gateway

温馨提示 完成所有操作後，需要 重啓 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