Kubernetes認證不需要那麼複雜
每當我處理Kubernetes專案時，認證機制總是讓我感到焦慮。雖然我理解RBAC的運作原理，知道它是與API伺服器通訊的必要元素，但我的理解就止步於此。設定API伺服器使用認證外掛、取得權杖或憑證、設定外掛程式，這些任務讓我覺得是項艱鉅的挑戰。就連為自己設定正確的環境都是一場惡夢。
然而，當我為kty實作OAuth支援時，我被迫深入瞭解這整套機制的實際運作方式。驚訝的是，這一切遠比我想像的簡單許多。
簡單說
使用OpenID並在叢集中為群組或使用者授予適當許可權，就是全部要做的事。你的組織很可能已經有OpenID提供者了。Google、GitHub、Okta（以及更多其他服務）都可以使用。不必費心於IAM、服務帳號或其他複雜機制 - 那些適合機器使用，而非人類使用者。
如果你想了解如何自己實作這點，可以直接跳到本文後半部的實作指引。不過，我建議先閱讀完整篇文章，理解背後運作的機制，這有助於你瞭解各個元件如何協同工作。
身分驗證 vs. 授權
首先，讓我們將「認證」（auth）拆分為兩個部分：身分驗證（authentication）和授權（authorization）。
身分驗證是你證明自己身分的方式。身分驗證過程的結果是一個身分識別，用來判斷你可以或不可以執行哪些操作。如果我們不在乎驗證你的身分，身分驗證可以簡單到只是向API伺服器傳送明文使用者名稱。顯然，我們需要一個比這更安全的解決方案。
Kubernetes有多種方式進行身分驗證。由於靜態權杖檔案是最容易理解的，讓我們從這裡開始。這相當於擁有一個密碼。你將權杖（即「密碼」）放入檔案中，然後將其與使用者名稱關聯。這聽起來很基礎，因為它確實如此！傳送到API伺服器的每個請求都包含你的權杖作為標頭。API伺服器在其檔案中查詢權杖，並將其對映到使用者或一組群組。這與向API伺服器傳送使用者名稱非常相似，但現在我們有了一個分享資料（權杖）來驗證身分。
OpenID Connect（OIDC）則摒棄了預先分享的金鑰，而是使用密碼學魔法來達成相同目的。這允許身分在中央位置（提供者）建立，並隨後由任何人驗證。當你與OIDC提供者進行身分驗證時，過程的最終結果是一個ID權杖。
JWT與身分宣告
ID權杖是一個JSON Web權杖（JWT），包含有關你身分的大量資訊。這個權杖中的資訊實際上是稱為「宣告」（claims）的鍵值對。每個宣告都是提供者已驗證的一條資料。
權杖使用提供者的私鑰簽名，任何擁有公鑰的人都可以驗證。最重要的是，OIDC提供者會公開他們的設定，以便任何人都可以驗證權杖。如果你對這些設定內容感興趣，可以檢視kty中的預設提供者設定。
有了ID權杖和驗證方法，API伺服器可以從權杖中提取身分，並將其作為RBAC的一部分，來瞭解你被允許執行哪些操作。權杖與群組或使用者之間的關聯是透過宣告實作的。如果你有JWT，可以前往jwt.io並貼上權杖來檢視其中的宣告。
以我從kty獲得的權杖為例，我們可以設定API伺服器將宣告對映到使用者。這就像上面提到的權杖檔案一樣！我們不是使用預先分享的金鑰作為對映，而是使用OIDC提供者的公鑰。
從身分到授權
現在我們有了已驗證的身分，接下來就可以進行授權。系統會檢查一系列規則（或角色），並測試該身分是否可以執行請求的操作。Kubernetes的根據角色的存取控制系統不關心你如何進行身分驗證。如果API說你是某個使用者，那麼你就是那個使用者。它只關心你的身分以及該身分繫結的角色。
讓我們看一個簡單的角色定義：
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
name: pod-reader
rules:
- apiGroups: [""]
resources: ["pods"]
verbs: ["get", "list", "watch"]
任何繫結到此角色的身分都可以在任何名稱空間中取得、列出或監視Pod。那麼身分如何與角色關聯呢？這就是ClusterRoleBinding的作用。
實作OpenID認證的簡單步驟
設定OpenID認證比你想像的要簡單得多。以下是基本步驟：
- 選擇OpenID提供者：使用你組織已有的提供者（Google、GitHub、Okta等）
- 設定API伺服器：設定必要的OIDC引數
- 定義角色與繫結：根據你的安全需求建立角色和角色繫結
- 使用者登入：透過提供者進行身分驗證，取得JWT權杖
- 設定kubeconfig：將權杖資訊加入你的設定檔
透過這種方式，你可以輕鬆地讓團隊成員使用他們已有的帳號登入Kubernetes，同時保持嚴格的存取控制。
使用kty簡化整個流程
我們開發的kty工具進一步簡化了這個過程。kty是一個Kubernetes終端工具，它整合了OpenID認證流程，讓你不必手動處理JWT權杖和設定檔。只需一個命令，kty就能處理身分驗證並提供安全的叢集存取。
對於管理多個叢集的團隊來說，kty提供了一致與安全的認證方式，消除了每次切換環境時重新設定認證的麻煩。
結語
Kubernetes認證不需要是一個複雜與令人生畏的任務。透過OpenID Connect，你可以建立一個既安全又簡單的認證系統。不要讓認證機制阻礙你充分利用Kubernetes的強大功能。
在我的實踐中，轉向OpenID解決方案後，不僅減少了維護負擔，還提高了整體安全性。團隊成員不再需要管理多個憑證或權杖，管理員也可以集中控制存取許可權。
如果你還在與Kubernetes認證搏鬥，試OpenID方案吧。你會驚訝於它的簡單有效。
提升Kubernetes身份管理：群組與角色繫結的實戰應用
在Kubernetes環境中建立強大與靈活的身份驗證系統一直是我關注的核心議題。過去幾年間，我見過太多團隊仍在使用複雜與不安全的存取控制方案，而OIDC（OpenID Connect）提供了一個更優雅的解決方案。在這篇文章中，我將分享如何將OIDC身份驗證提升到新層次，特別是利用群組角色繫結來實作更精細的許可權控制。
群組角色繫結：超越基本身份驗證
OIDC身份驗證的真正威力在於其靈活性。除了基本的使用者識別外，我們還可以將JWT令牌中的特定宣告（claim）對映為Kubernetes群組。這種方法為許可權管理開闢了全新的可能性。
想像一下，不再需要為每個使用者單獨設定許可權，而是根據他們所屬的團隊自動賦予適當的存取許可權。例如，你可以設定這樣的規則：
- 開發團隊成員可以存取開發名稱空間
- SRE團隊成員擁有更廣泛的叢集監控許可權
- 資安團隊可以檢視但不能修改關鍵資源
實際上，你幾乎可以將使用者GitHub個人資料的任何資訊直接對映到Kubernetes群組。這種方式下，群組的角色繫結會有些不同：
kind: ClusterRoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
name: github-dev-team-binding
subjects:
- kind: Group
name: github:org:my-company:team:developers
apiGroup: rbac.authorization.k8s.io
roleRef:
kind: ClusterRole
name: developer-permissions
apiGroup: rbac.authorization.k8s.io
這種設計的美妙之處在於，你只需在Kubernetes中設定一次許可權，之後完全透過OIDC提供者（如GitHub）來管理成員資格。當有新成員加入開發團隊時，他們立即獲得相應的Kubernetes許可權，而不需要任何額外的叢集設定。
自己動手實作OIDC身份驗證
在我嘗試過各種Kubernetes身份驗證方案後，發現有幾種工具特別實用。如果你想親自實作這套系統，以下是我的建議：
使用kty直接整合
我最近在一個專案中使用了kty，它直接內建OIDC支援，這意味著你可以完全不用管理SSH金鑰就能登入叢集。使用者會看到一個登入畫面，透過OIDC驗證身份後，系統會使用預設的宣告（通常是電子郵件）將外部身份對映到你角色繫結中定義的使用者。
透過kubelogin與kubectl整合
若你偏好直接使用kubectl，kubelogin是一個絕佳選擇。這個外掛會為你處理OIDC認證流程。只需將外掛和叢集連線資訊新增到kubectl設定中，就能開始使用：
apiVersion: v1
kind: Config
contexts:
- context:
cluster: my-cluster
user: oidc-user
name: my-context
users:
- name: oidc-user
user:
exec:
apiVersion: client.authentication.k8s.io/v1beta1
command: kubectl
args:
- oidc-login
- get-token
- --oidc-issuer-url=https://accounts.google.com
- --oidc-client-id=YOUR_CLIENT_ID
- --oidc-client-secret=YOUR_CLIENT_SECRET
需要注意的是，如果你無法對API伺服器進行必要的修改，可以考慮使用oidc-proxy。不過，現在大多數Kubernetes服務如EKS或GKE都已原生支援OIDC，這使得整合過程變得相當順暢。
整合方案：集中化的存取管理
實施OIDC身份驗證後，你會發現整個存取管理變得更加清晰和集中。這個方案帶來的好處包括：
集中式成員管理
使用群組功能後，許可權分配變得極為靈活。當令牌生成時，使用者的群組成員資格會被對映到相應的角色繫結，確保每個人只獲得必要的許可權。
提高可讀性與易維護性
身份識別可以採用友善的格式，使YAML設定更易於理解。團隊成員可以輕鬆檢視並理解誰被允許執行哪些操作。
簡化使用者經驗
若使用kty，甚至不需要任何外掛或額外設定！使用者可以直接使用既有工具，立即獲得叢集存取權。這大降低了新成員加入團隊時的設定門檻。
在我多年管理Kubernetes叢集的經驗中，發現許多團隊仍在使用複雜的身份驗證系統，包含多個外掛、Webhook、各種令牌和憑證。這些方案不僅難以設定，還容易出錯。
我的建議是：不要懼怕身份驗證！放棄那些需要極高許可權的服務，比如Kubernetes儀錶板。採用OIDC，確保使用者只擁有他們所需的精確許可權。畢竟，最好的安全性是每個人都能理解並遵循的安全性。
在實施OIDC的過程中，我發現一個關鍵點是取得團隊的支援。向團隊展示OIDC如何簡化他們的日常工作，而不只是強調安全性，這樣能大提高採用率。當開發者發現他們不再需要管理複雜的憑證或SSH金鑰，而只需透過熟悉的身份提供者登入，他們通常會成為這個方案的支援者。
Kubernetes身份管理不必是一場噩夢。透過OIDC和適當的群組角色繫結，我們可以建立一個既安全又易用的系統，讓團隊專注於創造價值，而不是與存取問題搏鬥。
