本文發表於一年多前。舊文章可能包含過時內容。請檢查頁面中的資訊自發布以來是否已變得不正確。

Kubernetes 1.30：結構化身份驗證配置進入 Beta 階段

作者：Anish Ramasekar (Microsoft) |

在 Kubernetes 1.30 中，我們（SIG Auth）將結構化身份認證配置（Structured Authentication Configuration）推進到 Beta 階段。

今天的文章是關於**身份認證**（Authentication）：查明誰在執行任務，並核實他們是否是其聲稱的身份。明天再來了解 Kubernetes v1.30 在**授權**（Authorization）（決定某人可以和不可以訪問什麼）方面的新特性。

動機

Kubernetes 長期以來一直需要一個更靈活、可擴充套件的身份認證系統。當前的系統雖然強大，但存在一些限制，使其在某些場景下難以使用。例如，無法使用同一型別的多個身份認證器（例如，多個 JWT 認證器），也無法在不重啟 API 伺服器的情況下更改配置。結構化身份認證配置功能是解決這些限制、併為在 Kubernetes 中配置身份認證提供更靈活和可擴充套件方式的第一步。

什麼是結構化身份認證配置？

Kubernetes v1.30 建立在 Kubernetes v1.29 作為 Alpha 版本新增的、基於檔案配置身份認證的實驗性支援之上。在這個 Beta 階段，Kubernetes 僅支援配置 JWT 認證器，這是現有 OIDC 認證器的下一代版本。JWT 認證器是一種使用 JWT 相容令牌對 Kubernetes 使用者進行身份認證的認證器。該認證器將嘗試解析原始 ID 令牌，並驗證它是否由配置的簽發者簽名。

Kubernetes 專案增加了從檔案進行配置的功能，以便提供比使用命令列選項（這些選項仍然有效，並且繼續受到支援）更大的靈活性。支援配置檔案也使得在即將釋出的版本中更容易實現進一步的改進。

結構化身份認證配置的優勢

以下是為什麼使用配置檔案來配置叢集身份認證會帶來好處的原因：

  1. 多個 JWT 認證器：你可以同時配置多個 JWT 認證器。這使你可以使用多個身份提供程式（例如，Okta、Keycloak、GitLab），而無需使用像 Dex 這樣的中介軟體來處理多個身份提供程式之間的多路複用。
  2. 動態配置：你可以在不重啟 API 伺服器的情況下更改配置。這使你可以在不中斷 API 伺服器的情況下新增、刪除或修改認證器。
  3. 任何符合 JWT 規範的令牌：你可以使用任何符合 JWT 規範的令牌進行身份認證。這使你可以使用任何支援 JWT 的身份提供程式提供的令牌。最小有效 JWT 負載必須包含 Kubernetes 文件中結構化身份認證配置頁面記錄的宣告。
  4. CEL（通用表示式語言）支援：你可以使用 CEL 來判斷令牌的宣告是否與 Kubernetes 中的使用者屬性（例如，使用者名稱、使用者組）匹配。這使你可以使用複雜的邏輯來判斷令牌是否有效。
  5. 多個受眾（Audience）：你可以為單個認證器配置多個受眾。這使你可以為多個受眾使用相同的認證器，例如為 kubectl 和 Dashboard 使用不同的 OAuth 客戶端。
  6. 使用不支援 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）建議遷移到新的基於配置檔案的方法，因為它提供了更大的靈活性和可擴充套件性。

以下是一個如何從命令列標誌遷移到配置檔案的示例：

命令列引數

--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 表示式使分散式宣告（distributed claims）生效。
  • 為對 issuer.url 和 issuer.discoveryURL 的呼叫提供出口選擇器（egress selector）配置支援。

你可以在 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 雙週會議。