Hi, I’m Hsien-Te Hsieh 🧑🏻‍💻

前言 最近在調整 Kong Data Plane 的回應標頭時，遇到一個讓我有點困惑的現象： 同樣修改 kong.conf，restart 後符合預期，reload 卻像是沒有吃到設定。 一開始以為是 reload 沒有成功，後來才發現，問題不是「新設定沒有讀到」，而是「我沒有明確提供新值」。 發現問題：註解掉 off，卻沒有恢復 我的環境是安裝在 VM 上的 Kong Data Plane。 當時為了關閉 Kong 回應標頭，在 kong.conf 加入： headers = off 需要恢復時，我的操作很直覺：把這行註解掉。 # headers = off 我原本的理解是： 不再指定 off，應該就會恢復預設值。 但執行 reload 後，透過 Postman 呼叫 API，仍然沒有看到預期恢復的 Via 標頭；改用 restart，結果才符合預期。 排查：明確指定值，reload 就生效了 排查過程中，我也嘗試在 Postman 請求加入 Connection: close，但沒有改變測試結果。 真正的轉折，是不再透過註解切換，而是明確寫入： headers = server_tokens, latency_tokens, X-Kong-Request-Id 再次 reload，Via 就恢復了。 這讓問題變得更明確： reload 可以套用明確指定的新值，但將設定註解掉，並沒有清除先前的值。 原始碼線索：舊設定加上新設定 接著查看 Kong 官方 reload.lua 原始碼，其中有一段合併設定的邏輯： local kong_env = assert(pl_file.read(args.conf)) if pl_path.exists(new_config.kong_env) then kong_env = assert(pl_file.read(new_config.kong_env)) .. "\n" .. kong_env end 這段程式不是先逐項比較設定，而是把兩份檔案的文字接起來： ...

前言 最近在 Kong 3.12 上做一個 PoC，想把公司內部的 RESTful API 透過 ai-mcp-proxy plugin 包成 MCP server，讓 Microsoft Copilot Studio 可以呼叫。同時為了讓呼叫者帶身分過來，在同一個 route 上掛了 openid-connect plugin，搭配 Microsoft Entra ID（原 Azure AD）做驗證。 理論上很單純：Copilot Studio 帶 token，Kong 驗證，通過後轉成對後端 REST API 的呼叫。實際做下去踩了一些雷，趁還沒忘掉趕快記下來。 架構概觀 Copilot Studio │ (Bearer token from Entra ID) ▼ F5 (load balancer) │ ▼ Kong Data Plane (Route /My-MCP) │ ┌─ openid-connect plugin (驗證 Entra ID token) │ └─ ai-mcp-proxy plugin (mode: conversion-listener) ▼ Backend RESTful API (Azure App Service) 401 Invalid Token OpenID Connect plugin 一掛上去，設定大致是這樣： ...

前言 最近工作上在研究 API 認證方案，整理了一個 Kong HMAC Demo 來驗證 HMAC-SHA256 作為 Kong API Gateway 認證機制的可行性。趁還沒忘掉，記錄一下核心觀念與適用場景。 什麼是 HMAC HMAC（Hash-based Message Authentication Code）是一種利用雜湊函數（如 SHA-256）與共享金鑰（shared secret）產生訊息鑑別碼（MAC）的機制。 實際在 HTTP 請求中，client 會選取特定 header（例如 Date），以金鑰對其進行 HMAC 運算，產生 signature，再附在 Authorization header 中送出。 Authorization: hmac username="demo-user", algorithm="hmac-sha256", headers="date", signature="<base64-encoded-signature>" 為什麼 HMAC 可以作為身份驗證 HMAC 能作為身份驗證的核心原因在於：只有持有正確金鑰的人，才能產生出合法的 signature。 驗證流程如下： Client 計算簽章： Client 使用共享金鑰對指定 headers 計算 HMAC 簽章，附在請求中送出。 Server 重算比對： Server（這裡是 Kong）收到請求後，根據 username 找到對應的 consumer 及其 secret，對相同的 headers 重新計算一次 HMAC。 比對結果： 若兩端計算出的 signature 一致，代表請求方持有正確金鑰，身份即可確認。 防重放攻擊： Kong 的 HMAC plugin 要求簽章必須包含 Date header，並設定允許的時間偏移（clock skew）。若請求的時間戳記超出允許範圍（預設 ±300 秒），Kong 會直接拒絕請求，防止攻擊者截取請求後重放。 ...

前言 這個部落格跑了一段時間，但我一直沒有好好整理它是怎麼運作的。趁現在記錄一下：本地怎麼新增文章、推上 GitHub 後又發生了什麼事，讓網站自動更新。 專案結構 整個 GitHub repository（arieshsieh0402.github.io）的結構如下： arieshsieh0402.github.io/ ← git repo 根目錄 ├── .github/ │ └── workflows/ │ └── hugo.yaml ← GitHub Actions 部署設定 ├── AriesHsieh/ ← Hugo 專案目錄 │ ├── archetypes/ │ │ └── posts.md ← 新文章的預設模板 │ ├── content/ │ │ └── posts/ ← 所有文章放這裡 │ ├── themes/ │ │ └── PaperMod/ ← 使用的 Hugo 主題 │ ├── public/ ← hugo build 產生的靜態檔案（不進 git） │ └── hugo.yaml ← Hugo 網站設定 Hugo 專案本身放在 repo 根目錄下的 AriesHsieh/ 子目錄，而非 repo 根目錄。這個結構在 GitHub Actions 設定中需要特別注意 working directory。 ...

Kong 與 Nginx 設定關係筆記 工作上遇到一些狀況，需要處理 HTTPS 加解密演算法，剛好趁這個機會記錄一下 Kong 跟 Nginx 的關係。 這邊以 SSL Ciphers 為例，整理 Kong 設定如何流向至 Nginx 實際生效的過程。 概念架構 Kong 的設定與 Nginx 的設定之間存在著三層結構： 層級 檔案位置 用途 源頭 kong.conf Kong 的主設定檔，定義所有運行參數 入口 nginx.conf Nginx 的起點，僅做全域/事件設定，在 http {} 內 include 真正的設定檔 生效 nginx-kong.conf 實際生效的設定，包含 ssl_ciphers、ssl_protocols、各個 listen 等 TLS/Server 設定 簡單來說：kong.conf 是來源、nginx.conf 是入口、nginx-kong.conf 是實際生效結果。 設定流向 - 以 SSL Ciphers 為例 Step 1: 源設定 在 kong.conf 設定 ssl_cipher_suite 和 ssl_ciphers： ssl_cipher_suite = custom ssl_ciphers = ECDHE-RSA-AES256-GCM-SHA384:... Step 2: Kong 翻譯 當你執行 kong start 或 kong restart 時，Kong 會根據 kong.conf 生成 Nginx 的實際設定。 ...