強化指南 - 認證機制
選擇適當的身份驗證機制是保護叢集安全的關鍵方面。Kubernetes 提供了幾種內建機制，每種機制都有其自身的優缺點，在選擇最適合您叢集的身份驗證機制時應仔細考慮。
通常建議儘可能少地啟用身份驗證機制，以簡化使用者管理並防止使用者保留對不再需要的叢集的訪問許可權。
值得注意的是，Kubernetes 在叢集內沒有內建的使用者資料庫。相反，它從配置的身份驗證系統中獲取使用者資訊，並使用該資訊做出授權決策。因此，要審計使用者訪問，您需要審查每個配置的身份驗證源的憑據。
對於多個使用者直接訪問 Kubernetes API 的生產叢集，建議使用 OIDC 等外部身份驗證源。下面描述的內部身份驗證機制（例如客戶端證書和服務帳戶令牌）不適用於此用例。
X.509 客戶端證書身份驗證
Kubernetes 利用 X.509 客戶端證書身份驗證用於系統元件，例如 kubelet 向 API 伺服器進行身份驗證。雖然此機制也可用於使用者身份驗證，但由於以下限制，它可能不適合生產使用：
- 客戶端證書無法單獨撤銷。一旦被洩露，攻擊者可以使用證書直到其過期。為了減輕此風險，建議為使用客戶端證書建立的使用者身份驗證憑據配置較短的生命週期。
- 如果需要使證書失效，則必須重新生成證書頒發機構的金鑰，這可能會給叢集帶來可用性風險。
- 叢集中沒有建立客戶端證書的永久記錄。因此，如果需要跟蹤所有已頒發的證書，則必須記錄它們。
- 用於客戶端證書身份驗證的私鑰不能受密碼保護。任何可以讀取包含金鑰的檔案的人都將能夠使用它。
- 使用客戶端證書身份驗證需要客戶端與 API 伺服器之間直接連線，而不能有任何中間 TLS 終止點，這會使網路架構複雜化。
- 組資料嵌入在客戶端證書的
O值中，這意味著使用者的組員資格在證書的生命週期內無法更改。
靜態令牌檔案
儘管 Kubernetes 允許您從位於控制平面節點磁碟上的靜態令牌檔案載入憑據，但由於以下幾個原因，不建議將此方法用於生產伺服器：
- 憑據以明文形式儲存在控制平面節點磁碟上，這可能存在安全風險。
- 更改任何憑據都需要重新啟動 API 伺服器程序才能生效，這可能會影響可用性。
- 沒有可用的機制允許使用者輪換其憑據。要輪換憑據，叢集管理員必須修改磁碟上的令牌並將其分發給使用者。
- 沒有可用的鎖定機制來防止暴力攻擊。
引導令牌
引導令牌用於將節點加入叢集，由於以下幾個原因，不建議將其用於使用者身份驗證：
- 它們具有不適合一般使用的硬編碼組成員資格，使其不適用於身份驗證目的。
- 手動生成引導令牌可能會導致弱令牌被攻擊者猜到，這可能存在安全風險。
- 沒有可用的鎖定機制來防止暴力攻擊，使得攻擊者更容易猜測或破解令牌。
ServiceAccount secret 令牌
Service Account 金鑰是允許叢集中執行的工作負載向 API 伺服器進行身份驗證的一個選項。在 Kubernetes < 1.23 中，這些是預設選項，但它們正在被 TokenRequest API 令牌取代。雖然這些金鑰可用於使用者身份驗證，但由於多種原因，它們通常不適合：
- 它們不能設定過期時間，並且在關聯的服務帳戶被刪除之前將一直有效。
- 身份驗證令牌對任何可以讀取它們所在名稱空間中的金鑰的叢集使用者都可見。
- Service Accounts 不能新增到任意組，這使得在使用它們時 RBAC 管理變得複雜。
TokenRequest API 令牌
TokenRequest API 是一個有用的工具，用於為服務向 API 伺服器或第三方系統進行身份驗證生成短期憑據。然而，通常不建議將其用於使用者身份驗證，因為沒有可用的撤銷方法，並且以安全的方式向用戶分發憑據可能具有挑戰性。
當使用 TokenRequest 令牌進行服務身份驗證時，建議實現較短的生命週期以減少洩露令牌的影響。
OpenID Connect 令牌身份驗證
Kubernetes 支援使用 OpenID Connect (OIDC) 將外部身份驗證服務與 Kubernetes API 整合。有各種各樣的軟體可用於將 Kubernetes 與身份提供者整合。然而，在 Kubernetes 中使用 OIDC 身份驗證時，重要的是要考慮以下強化措施：
- 叢集中為支援 OIDC 身份驗證而安裝的軟體應與一般工作負載隔離，因為它將以高許可權執行。
- 某些 Kubernetes 託管服務可使用的 OIDC 提供者有限制。
- 與 TokenRequest 令牌一樣，OIDC 令牌應具有較短的生命週期，以減少洩露令牌的影響。
Webhook 令牌身份驗證
Webhook 令牌身份驗證是另一個將外部身份驗證提供者整合到 Kubernetes 中的選項。此機制允許聯絡身份驗證服務（無論是執行在叢集內部還是外部）透過 Webhook 進行身份驗證決策。需要注意的是，此機制的適用性可能取決於用於身份驗證服務的軟體，並且需要考慮一些 Kubernetes 特定的注意事項。
要配置 Webhook 身份驗證，需要訪問控制平面伺服器檔案系統。這意味著託管 Kubernetes 將無法使用此功能，除非提供商專門提供。此外，叢集中為支援此訪問而安裝的任何軟體都應與一般工作負載隔離，因為它將以高許可權執行。
認證代理
將外部身份驗證系統整合到 Kubernetes 的另一個選項是使用認證代理。透過此機制，Kubernetes 期望從代理接收請求，其中設定了特定的頭部值，指示要分配的使用者名稱和組成員資格以用於授權目的。需要注意的是，在使用此機制時需要考慮特定的事項。
首先，代理與 Kubernetes API 伺服器之間必須使用安全配置的 TLS，以減輕流量攔截或嗅探攻擊的風險。這確保了代理與 Kubernetes API 伺服器之間的通訊是安全的。
其次，重要的是要意識到，能夠修改請求頭部的攻擊者可能會獲得對 Kubernetes 資源的未經授權的訪問。因此，確保頭部得到妥善保護且無法篡改至關重要。