Kubernetes 1.30：結構化身分驗證配置移至 Beta 階段

作者：Anish Ramasekar (微軟) | 週四，2024 年 4 月 25 日

在 Kubernetes 1.30 中，我們 (SIG Auth) 正在將結構化身分驗證配置移至 Beta 版。

今天的文章是有關身分驗證：找出是誰在執行任務，並確認他們的確是他們所聲稱的身分。請明天回來查看 Kubernetes v1.30 中關於授權（決定某人可以和不能存取什麼）的新功能。

動機

Kubernetes 長期以來一直需要更彈性且可擴展的身分驗證系統。目前的系統雖然強大，但仍有一些限制，使其在某些情況下難以使用。例如，無法使用相同類型的多個身分驗證器（例如，多個 JWT 身分驗證器），或者在不重新啟動 API 伺服器的情況下變更配置。結構化身分驗證配置功能是朝著解決這些限制邁出的第一步，並提供更彈性且可擴展的方式來配置 Kubernetes 中的身分驗證。

什麼是結構化身分驗證配置？

Kubernetes v1.30 建構在 Kubernetes v1.30 中以 Alpha 版新增的基於檔案配置身分驗證的實驗性支援之上。在此 Beta 階段，Kubernetes 僅支援配置 JWT 身分驗證器，這是現有 OIDC 身分驗證器的下一個迭代版本。JWT 身分驗證器是一種使用符合 JWT 規範的權杖來驗證 Kubernetes 使用者的身分驗證器。此身分驗證器將嘗試解析原始 ID 權杖，並驗證它是否已由配置的發行者簽署。

Kubernetes 專案新增了從檔案進行配置的功能，使其可以提供比使用命令列選項（這些選項繼續運作，並且仍然受到支援）更大的彈性。支援配置檔案也使在即將發布的版本中輕鬆交付更多改進成為可能。

結構化身分驗證配置的優點

以下是為何使用配置檔案來配置集群身分驗證是一項優勢的原因

多個 JWT 身分驗證器：您可以同時配置多個 JWT 身分驗證器。這讓您可以使用多個身分提供者（例如，Okta、Keycloak、GitLab），而無需使用像 Dex 這樣的仲介來處理多個身分提供者之間的複合。
動態配置：您可以在不重新啟動 API 伺服器的情況下變更配置。這讓您可以在不中斷 API 伺服器的情況下新增、移除或修改身分驗證器。
任何符合 JWT 規範的權杖：您可以使用任何符合 JWT 規範的權杖進行身分驗證。這讓您可以使用來自任何支援 JWT 的身分提供者的權杖。有效的 JWT 酬載必須包含結構化身分驗證配置頁面中 Kubernetes 文件中記錄的宣告。
CEL (通用運算式語言) 支援：您可以使用 CEL 來判斷權杖的宣告是否與 Kubernetes 中使用者的屬性（例如，使用者名稱、群組）相符。這讓您可以使用複雜的邏輯來判斷權杖是否有效。
多個受眾：您可以為單一身分驗證器配置多個受眾。這讓您可以將相同的身分驗證器用於多個受眾，例如為 kubectl 和儀表板使用不同的 OAuth 用戶端。
使用不支援 OpenID Connect 探索的身分提供者：您可以使用不支援 OpenID Connect 探索的身分提供者。唯一的要求是在與發行者不同的位置（例如，在集群本地）託管探索文件，並在配置檔案中指定 issuer.discoveryURL。

如何使用結構化身分驗證配置

若要使用結構化身分驗證配置，您可以使用 API 伺服器中的 --authentication-config 命令列引數來指定身分驗證配置的路徑。配置檔案是一個 YAML 檔案，用於指定身分驗證器及其配置。以下是一個範例配置檔案，用於配置兩個 JWT 身分驗證器

apiVersion: apiserver.config.k8s.io/v1beta1
kind: AuthenticationConfiguration
# Someone with a valid token from either of these issuers could authenticate
# against this cluster.
jwt:
- issuer:
    url: https://issuer1.example.com
    audiences:
    - audience1
    - audience2
    audienceMatchPolicy: MatchAny
  claimValidationRules:
    expression: 'claims.hd == "example.com"'
    message: "the hosted domain name must be example.com"
  claimMappings:
    username:
      expression: 'claims.username'
    groups:
      expression: 'claims.groups'
    uid:
      expression: 'claims.uid'
    extra:
    - key: 'example.com/tenant'
      expression: 'claims.tenant'
  userValidationRules:
  - expression: "!user.username.startsWith('system:')"
    message: "username cannot use reserved system: prefix"
# second authenticator that exposes the discovery document at a different location
# than the issuer
- issuer:
    url: https://issuer2.example.com
    discoveryURL: https://discovery.example.com/.well-known/openid-configuration
    audiences:
    - audience3
    - audience4
    audienceMatchPolicy: MatchAny
  claimValidationRules:
    expression: 'claims.hd == "example.com"'
    message: "the hosted domain name must be example.com"
  claimMappings:
    username:
      expression: 'claims.username'
    groups:
      expression: 'claims.groups'
    uid:
      expression: 'claims.uid'
    extra:
    - key: 'example.com/tenant'
      expression: 'claims.tenant'
  userValidationRules:
  - expression: "!user.username.startsWith('system:')"
    message: "username cannot use reserved system: prefix"

從命令列引數遷移到配置檔案

結構化身分驗證配置功能旨在與現有的方法（基於命令列選項）向後相容，以用於配置 JWT 身分驗證器。這表示您可以繼續使用現有的命令列選項來配置 JWT 身分驗證器。但是，我們 (Kubernetes SIG Auth) 建議遷移到新的基於配置檔案的方法，因為它提供了更大的彈性和可擴展性。

注意

如果您同時指定 --authentication-config 和任何 --oidc-* 命令列引數，則這是一個錯誤配置。在這種情況下，API 伺服器會報告錯誤，然後立即退出。

如果您想要切換到使用結構化身分驗證配置，則必須移除 --oidc-* 命令列引數，並改用配置檔案。

以下是如何從命令列標記遷移到配置檔案的範例

命令列引數

--oidc-issuer-url=https://issuer.example.com
--oidc-client-id=example-client-id
--oidc-username-claim=username
--oidc-groups-claim=groups
--oidc-username-prefix=oidc:
--oidc-groups-prefix=oidc:
--oidc-required-claim="hd=example.com"
--oidc-required-claim="admin=true"
--oidc-ca-file=/path/to/ca.pem

在配置檔案中沒有與 --oidc-signing-algs 對應的項目。對於 Kubernetes v1.30，身分驗證器支援 oidc.go 中列出的所有非對稱演算法。

配置檔案

apiVersion: apiserver.config.k8s.io/v1beta1
kind: AuthenticationConfiguration
jwt:
- issuer:
    url: https://issuer.example.com
    audiences:
    - example-client-id
    certificateAuthority: <value is the content of file /path/to/ca.pem>
  claimMappings:
    username:
      claim: username
      prefix: "oidc:"
    groups:
      claim: groups
      prefix: "oidc:"
  claimValidationRules:
  - claim: hd
    requiredValue: "example.com"
  - claim: admin
    requiredValue: "true"

下一步？

對於 Kubernetes v1.31，我們預期此功能將保持在 Beta 版，同時我們將獲得更多回饋。在即將發布的版本中，我們想要研究

透過 CEL 運算式使分散式宣告能夠運作。
對 issuer.url 和 issuer.discoveryURL 的呼叫的出口選擇器配置支援。

您可以在 Kubernetes 文件中的結構化身分驗證配置頁面上了解有關此功能的更多資訊。您也可以在 KEP-3331 上追蹤即將發布的 Kubernetes 版本中的進度。

試用看看

在這篇文章中，我介紹了結構化身分驗證配置功能在 Kubernetes v1.30 中帶來的優點。若要使用此功能，您必須使用 --authentication-config 命令列引數來指定身分驗證配置的路徑。從 Kubernetes v1.30 開始，此功能處於 Beta 版，並且預設為啟用。如果您想要繼續使用命令列引數而不是配置檔案，這些引數將繼續按原樣運作。

我們很樂意聽取您對此功能的意見回饋。請透過 Kubernetes Slack 上的 #sig-auth-authenticators-dev 頻道與我們聯繫（如需邀請，請造訪 https://slack.k8s.io/）。

如何參與

如果您有興趣參與此功能的開發、分享意見回饋或參與任何其他正在進行的 SIG Auth 專案，請透過 Kubernetes Slack 上的 #sig-auth 頻道與我們聯繫。

也歡迎您加入每隔週三舉行的雙週 SIG Auth 會議。