強化指南 - 身份驗證機制
選擇適當的身份驗證機制是保護叢集的關鍵方面。Kubernetes 提供了幾種內建機制，每種機制都有其自身的優點和缺點，在為您的叢集選擇最佳身份驗證機制時應仔細考慮。
一般而言，建議啟用盡可能少的身份驗證機制，以簡化使用者管理並防止使用者在不再需要時仍保留叢集存取權的情況。
重要的是要注意，Kubernetes 在叢集中沒有內建的使用者資料庫。相反地，它從已設定的身份驗證系統中取得使用者資訊，並使用該資訊來做出授權決策。因此，要稽核使用者存取權，您需要審查每個已設定身份驗證來源的憑證。
對於多個使用者直接存取 Kubernetes API 的生產叢集，建議使用外部身份驗證來源，例如 OIDC。如下所述的內部身份驗證機制，例如用戶端憑證和服務帳戶權杖，不適用於此使用案例。
X.509 用戶端憑證身份驗證
Kubernetes 利用 X.509 用戶端憑證 身份驗證用於系統元件，例如 kubelet 向 API 伺服器進行身份驗證時。雖然此機制也可以用於使用者身份驗證，但由於以下幾個限制，它可能不適用於生產用途
- 用戶端憑證無法個別撤銷。一旦洩露，攻擊者可以使用憑證直到憑證過期。為了降低此風險，建議為使用用戶端憑證建立的使用者身份驗證憑證設定較短的生命週期。
- 如果需要使憑證失效，則必須重新金鑰憑證授權單位，這可能會對叢集造成可用性風險。
- 叢集中沒有建立用戶端憑證的永久記錄。因此，如果您需要追蹤已發行的所有憑證，則必須記錄它們。
- 用於用戶端憑證身份驗證的私鑰不能受到密碼保護。任何可以讀取包含金鑰檔案的人都可以使用它。
- 使用用戶端憑證身份驗證需要從用戶端到 API 伺服器的直接連線，而沒有任何介入的 TLS 終止點，這可能會使網路架構複雜化。
- 群組資料嵌入在用戶端憑證的
O值中，這表示使用者的群組成員資格在憑證的生命週期內無法變更。
靜態權杖檔案
雖然 Kubernetes 允許您從位於控制平面節點磁碟上的 靜態權杖檔案 載入憑證，但由於以下幾個原因，不建議生產伺服器使用此方法
- 憑證以明文形式儲存在控制平面節點磁碟上，這可能是一個安全性風險。
- 變更任何憑證都需要重新啟動 API 伺服器程序才能生效，這可能會影響可用性。
- 沒有可用的機制允許使用者輪換其憑證。要輪換憑證，叢集管理員必須修改磁碟上的權杖並將其分發給使用者。
- 沒有可用的鎖定機制來防止暴力破解攻擊。
Bootstrap Tokens
Bootstrap Tokens 用於將節點加入叢集，由於以下幾個原因，不建議用於使用者身份驗證
- 它們具有硬式編碼的群組成員資格，不適合一般用途，使其不適合用於身份驗證目的。
- 手動產生 Bootstrap Tokens 可能會導致弱權杖，攻擊者可以猜測到這些權杖，這可能是一個安全性風險。
- 沒有可用的鎖定機制來防止暴力破解攻擊，這使得攻擊者更容易猜測或破解權杖。
ServiceAccount 密鑰權杖
服務帳戶密鑰 可作為一個選項，允許在叢集中執行的工作負載向 API 伺服器進行身份驗證。在 Kubernetes < 1.23 中，這些是預設選項，但是，它們正在被 TokenRequest API 權杖取代。雖然這些密鑰可用於使用者身份驗證，但由於許多原因，它們通常不適合
- 它們無法設定到期時間，並且在關聯的服務帳戶被刪除之前將保持有效。
- 任何可以讀取定義它們的命名空間中密鑰的叢集使用者都可以看到身份驗證權杖。
- 服務帳戶無法新增到任意群組，這使得使用它們的 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 無法使用此功能。 此外，叢集中安裝用於支援此存取的任何軟體都應與一般工作負載隔離，因為它將以高權限執行。
驗證 Proxy
將外部驗證系統整合至 Kubernetes 的另一個選項是使用驗證 Proxy。 透過此機制，Kubernetes 預期從 Proxy 接收請求，其中設定了特定的標頭值，指示要為授權目的指派的的使用者名稱和群組成員資格。 重要的是要注意，使用此機制時，有一些特定的考量因素需要納入考量。
首先，Proxy 和 Kubernetes API 伺服器之間必須使用安全設定的 TLS，以降低流量攔截或嗅探攻擊的風險。 這可確保 Proxy 和 Kubernetes API 伺服器之間的通訊安全無虞。
其次，務必注意，能夠修改請求標頭的攻擊者可能會取得 Kubernetes 資源的未經授權存取權。 因此，務必確保標頭已正確保護且無法被竄改。