OAuth

Most teams meet Kubernetes for the first time through a single “superuser” kubeconfig — a file with credentials that can wipe out the entire cluster. It then starts bouncing around Slack, email, and laptops, and nobody can say for sure who still has a copy, or whether the kubeconfig belonging to a former employee is still usable.

This post shows how to use kubelogin together with AuthGate to stand up an OIDC login flow on k3s: the moment a user runs kubectl get pods, the browser pops open AuthGate’s login page, the tokens land back in the kubeconfig, and the entire cluster no longer needs that shared admin.kubeconfig.

大部分團隊第一次裝 Kubernetes 時，拿到的都是一個「超級使用者」的 kubeconfig，裡面就躺著一組可以幹掉整個叢集的憑證。於是這份檔案開始在 Slack、Email、筆電之間被複製來複製去，沒有人知道目前誰還留著副本、哪個離職員工的 kubeconfig 還能用。

這篇文章要示範如何用 kubelogin 搭配 AuthGate，在 k3s 上建立一條 OIDC 登入流程：使用者打 kubectl get pods 的瞬間，瀏覽器自動跳出 AuthGate 的登入頁面，登入完成 token 寫回 kubeconfig，整個叢集不再需要共用那份 admin.kubeconfig。

In 2025, I introduced MCP (Model Context Protocol) at the iThome Taiwan Cloud Summit. At that time, I mentioned that the official team has been continuously revising the authentication protocol to address complex authentication flows. The previous design involved DCR (Dynamic Client Registration), so as expected, on 2025/11/25, a new Authorization mechanism was released. This authentication mechanism is called “Client ID Metadata Documents, abbreviated as CIMD”.

When installing a Model Context Protocol (MCP) server, the most challenging part is often not the protocol itself, but how to establish trust between the client and server. If you’ve ever tried to connect an MCP client to an MCP server it has never encountered before, you’ve probably run into what’s known as the “registration wall”.

Pre-registering with every possible authorization server is simply not scalable, and while Dynamic Client Registration (DCR) helps, it lacks reliable mechanisms to verify client identity, making it vulnerable to phishing attacks. Beyond security concerns, DCR also creates operational overhead by generating an ever-growing number of duplicate client identities that need to be managed.

2025 年在 iThome 臺灣雲端大會介紹過 MCP (Model Context Protocol)，那時候就有提到在認證協議部分，官方其實一直都在改版解決複雜的認證流程，之前設計的 DCR (Dynamic Client Registration)，所以沒意外去年 2025/11/25 又推出一版 Authorization 機制，此認證機制取名叫『Client ID Metadata Documents 簡稱 CIMD』。

安裝 Model Context Protocol（MCP）伺服器時，最棘手的部分往往不是協議本身，而是如何讓客戶端與伺服器彼此建立信任。如果你曾嘗試讓一個 MCP 客戶端連線到一個從未接觸過的 MCP 伺服器，你大概遇過所謂的「註冊高牆（registration wall）」。

要預先在每一個可能的授權伺服器完成註冊根本無法擴展，而 Dynamic Client Registration（DCR）雖然有所幫助，但因為缺乏可靠的機制來驗證客戶端身份，所以容易遭受網路釣魚攻擊。除了安全性問題之外，DCR 還會造成營運負擔，因為它會產生越來越多需要管理的重複客戶端身份。