證書和證書籤名請求

Kubernetes 證書和信任包 API 透過提供一個程式設計介面，使 Kubernetes API 客戶端可以請求和獲取證書頒發機構 (CA) 的 X.509 證書，從而實現 X.509 憑證的自動化供應。

還提供了分發信任包的實驗性（Alpha）支援。

證書籤名請求

特性狀態： Kubernetes v1.19 [stable]

CertificateSigningRequest（CSR）資源用於請求由指定簽名者簽署證書，在此之前，請求可以被批准或拒絕，然後最終被簽署。

請求籤名過程

CertificateSigningRequest 資源型別允許客戶端請求頒發一個 X.509 證書，該證書基於簽名請求。CertificateSigningRequest 物件在 spec.request 欄位中包含一個 PEM 編碼的 PKCS#10 簽名請求。CertificateSigningRequest 使用 spec.signerName 欄位指定簽名者（請求的接收方）。請注意，在 API 版本 certificates.k8s.io/v1 之後，spec.signerName 是一個必需的鍵。在 Kubernetes v1.22 及更高版本中，客戶端可以選擇設定 spec.expirationSeconds 欄位來請求頒發證書的特定有效期。該欄位的最小有效值為 600，即十分鐘。

CertificateSigningRequest 建立後，必須先獲得批准才能進行簽名。根據選擇的簽名者，CertificateSigningRequest 可能會由控制器自動批准。否則，CertificateSigningRequest 必須透過 REST API（或 client-go）手動批准，或者透過執行 kubectl certificate approve 來批准。同樣，CertificateSigningRequest 也可以被拒絕，這會告訴配置的簽名者不得簽署該請求。

對於已獲批准的證書，下一步是簽名。相關的簽名控制器首先驗證是否滿足簽名條件，然後建立證書。簽名控制器然後更新 CertificateSigningRequest，將新證書儲存到現有 CertificateSigningRequest 物件的 status.certificate 欄位中。status.certificate 欄位為空或包含一個 X.509 證書，採用 PEM 格式編碼。在簽名者完成此操作之前，CertificateSigningRequest 的 status.certificate 欄位為空。

一旦填充了 status.certificate 欄位，請求就完成了，客戶端現在可以從 CertificateSigningRequest 資源中獲取已簽名的證書 PEM 資料。如果未滿足批准條件，簽名者可以拒絕證書籤名。

為了減少叢集中遺留的舊 CertificateSigningRequest 資源的數量，垃圾收集控制器會定期執行。垃圾收集器會刪除在一段時間內未更改狀態的 CertificateSigningRequest。

  • 已批准的請求：1 小時後自動刪除
  • 已拒絕的請求：1 小時後自動刪除
  • 失敗的請求：1 小時後自動刪除
  • 待處理的請求：24 小時後自動刪除
  • 所有請求：在頒發的證書過期後自動刪除

證書籤名授權

允許建立 CertificateSigningRequest 並檢索任何 CertificateSigningRequest。

  • 動詞：create、get、list、watch，組：certificates.k8s.io，資源：certificatesigningrequests

例如

access/certificate-signing-request/clusterrole-create.yaml 
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: csr-creator
rules:
- apiGroups:
  - certificates.k8s.io
  resources:
  - certificatesigningrequests
  verbs:
  - create
  - get
  - list
  - watch

允許批准 CertificateSigningRequest

  • 動詞：get、list、watch，組：certificates.k8s.io，資源：certificatesigningrequests
  • 動詞：update，組：certificates.k8s.io，資源：certificatesigningrequests/approval
  • 動詞：approve，組：certificates.k8s.io，資源：signers，資源名稱：<signerNameDomain>/<signerNamePath> 或 <signerNameDomain>/*

例如

access/certificate-signing-request/clusterrole-approve.yaml 
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: csr-approver
rules:
- apiGroups:
  - certificates.k8s.io
  resources:
  - certificatesigningrequests
  verbs:
  - get
  - list
  - watch
- apiGroups:
  - certificates.k8s.io
  resources:
  - certificatesigningrequests/approval
  verbs:
  - update
- apiGroups:
  - certificates.k8s.io
  resources:
  - signers
  resourceNames:
  - example.com/my-signer-name # example.com/* can be used to authorize for all signers in the 'example.com' domain
  verbs:
  - approve

允許簽署 CertificateSigningRequest

  • 動詞：get、list、watch，組：certificates.k8s.io，資源：certificatesigningrequests
  • 動詞：update，組：certificates.k8s.io，資源：certificatesigningrequests/status
  • 動詞：sign，組：certificates.k8s.io，資源：signers，資源名稱：<signerNameDomain>/<signerNamePath> 或 <signerNameDomain>/*
access/certificate-signing-request/clusterrole-sign.yaml 
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: csr-signer
rules:
- apiGroups:
  - certificates.k8s.io
  resources:
  - certificatesigningrequests
  verbs:
  - get
  - list
  - watch
- apiGroups:
  - certificates.k8s.io
  resources:
  - certificatesigningrequests/status
  verbs:
  - update
- apiGroups:
  - certificates.k8s.io
  resources:
  - signers
  resourceNames:
  - example.com/my-signer-name # example.com/* can be used to authorize for all signers in the 'example.com' domain
  verbs:
  - sign

簽名者

簽名者抽象地代表可能簽署或已簽署安全證書的一個或多個實體。

任何在特定叢集外部可用的簽名者都應提供有關簽名者工作方式的資訊，以便消費者瞭解這對 CertificateSigningRequest 和（如果啟用）ClusterTrustBundles 意味著什麼。這包括：

  1. 信任分發：信任錨（CA 證書或證書包）如何分發。
  2. 允許的主題：當請求不允許的主題時，是否有任何限制和行為。
  3. 允許的 X.509 擴充套件：包括 IP subjectAltNames、DNS subjectAltNames、Email subjectAltNames、URI subjectAltNames 等，以及當請求不允許的擴充套件時，簽名者的行為。
  4. 允許的金鑰用途/擴充套件金鑰用途：當 CSR 中指定了與簽名者確定的用途不同的用途時，是否有任何限制和行為。
  5. 過期/證書生命週期：是否由簽名者固定，管理員可配置，由 CSR 的 spec.expirationSeconds 欄位確定等，以及當簽名者確定的過期時間與 CSR 的 spec.expirationSeconds 欄位不同時的行為。
  6. 允許/禁止 CA 位：以及當簽名者不允許時，如果 CSR 包含 CA 證書請求時的行為。

通常，一旦 CSR 獲得批准並頒發證書，CertificateSigningRequest 的 status.certificate 欄位包含一個 PEM 編碼的 X.509 證書。一些簽名者將多個證書儲存到 status.certificate 欄位中。在這種情況下，簽名者的文件應指定附加證書的含義；例如，這可能是證書加上在 TLS 握手期間呈現的中間證書。

如果您想提供**信任錨**（根證書），這應該獨立於 CertificateSigningRequest 及其 status.certificate 欄位進行。例如，您可以使用 ClusterTrustBundle。

PKCS#10 簽名請求格式沒有指定證書過期或生命週期的標準機制。因此，過期或生命週期必須透過 CSR 物件的 spec.expirationSeconds 欄位進行設定。內建簽名者使用 ClusterSigningDuration 配置選項（預設為 1 年，即 kube-controller-manager 的 --cluster-signing-duration 命令列標誌）作為未指定 spec.expirationSeconds 時的預設值。當指定 spec.expirationSeconds 時，將使用 spec.expirationSeconds 和 ClusterSigningDuration 的最小值。

Kubernetes 簽名者

Kubernetes 提供了內建簽名者，每個簽名者都有一個眾所周知的 signerName。

  1. kubernetes.io/kube-apiserver-client：簽署將被 API 伺服器視為客戶端證書的證書。從不被 kube-controller-manager 自動批准。

    1. 信任分發：簽署的證書必須被 API 伺服器視為客戶端證書。CA 捆綁包不透過任何其他方式分發。
    2. 允許的主題 - 沒有主題限制，但批准者和簽名者可以選擇不批准或簽署。某些主題，如叢集管理員級別使用者或組，在不同分發和安裝之間有所不同，但在批准和簽署之前需要額外的審查。CertificateSubjectRestriction 准入外掛預設啟用以限制 system:masters，但這通常不是叢集中唯一的叢集管理員主題。
    3. 允許的 X.509 擴充套件 - 接受 subjectAltName 和金鑰用途擴充套件，並丟棄其他擴充套件。
    4. 允許的金鑰用途 - 必須包含 ["client auth"]。不得包含 ["digital signature", "key encipherment", "client auth"] 之外的金鑰用途。
    5. 過期/證書生命週期 - 對於此簽名者的 kube-controller-manager 實現，設定為 --cluster-signing-duration 選項的最小值，或者如果指定，則為 CSR 物件的 spec.expirationSeconds 欄位。
    6. 允許/禁止 CA 位 - 不允許。

  2. kubernetes.io/kube-apiserver-client-kubelet：簽署將被 API 伺服器視為客戶端證書的客戶端證書。可能被 kube-controller-manager 自動批准。

    1. 信任分發：簽署的證書必須被 API 伺服器視為客戶端證書。CA 捆綁包不透過任何其他方式分發。
    2. 允許的主題 - 組織必須精確為 ["system:nodes"]，通用名為 "system:node:${NODE_NAME}"。
    3. 允許的 X.509 擴充套件 - 接受金鑰用途擴充套件，禁止 subjectAltName 擴充套件並丟棄其他擴充套件。
    4. 允許的金鑰用途 - ["key encipherment", "digital signature", "client auth"] 或 ["digital signature", "client auth"]。
    5. 過期/證書生命週期 - 對於此簽名者的 kube-controller-manager 實現，設定為 --cluster-signing-duration 選項的最小值，或者如果指定，則為 CSR 物件的 spec.expirationSeconds 欄位。
    6. 允許/禁止 CA 位 - 不允許。

  3. kubernetes.io/kubelet-serving：簽署服務證書，這些證書被 API 伺服器視為有效的 kubelet 服務證書，但沒有其他保證。從不被 kube-controller-manager 自動批准。

    1. 信任分發：簽署的證書必須被 API 伺服器視為有效，以終止與 kubelet 的連線。CA 捆綁包不透過任何其他方式分發。
    2. 允許的主題 - 組織必須精確為 ["system:nodes"]，通用名為 "system:node:${NODE_NAME}"。
    3. 允許的 X.509 擴充套件 - 接受金鑰用途和 DNSName/IPAddress subjectAltName 擴充套件，禁止 EmailAddress 和 URI subjectAltName 擴充套件，丟棄其他擴充套件。必須至少存在一個 DNS 或 IP subjectAltName。
    4. 允許的金鑰用途 - ["key encipherment", "digital signature", "server auth"] 或 ["digital signature", "server auth"]。
    5. 過期/證書生命週期 - 對於此簽名者的 kube-controller-manager 實現，設定為 --cluster-signing-duration 選項的最小值，或者如果指定，則為 CSR 物件的 spec.expirationSeconds 欄位。
    6. 允許/禁止 CA 位 - 不允許。

  4. kubernetes.io/legacy-unknown：根本不提供信任保證。一些第三方 Kubernetes 發行版可能會將其簽名的客戶端證書視為有效。穩定的 CertificateSigningRequest API（版本 certificates.k8s.io/v1 及更高版本）不允許將 signerName 設定為 kubernetes.io/legacy-unknown。從不被 kube-controller-manager 自動批准。

    1. 信任分發：無。在 Kubernetes 叢集中，此簽名者沒有標準信任或分發。
    2. 允許的主題 - 任何
    3. 允許的 X.509 擴充套件 - 接受 subjectAltName 和金鑰用途擴充套件，並丟棄其他擴充套件。
    4. 允許的金鑰用途 - 任何
    5. 過期/證書生命週期 - 對於此簽名者的 kube-controller-manager 實現，設定為 --cluster-signing-duration 選項的最小值，或者如果指定，則為 CSR 物件的 spec.expirationSeconds 欄位。
    6. 允許/禁止 CA 位 - 不允許。

kube-controller-manager 為每個內建簽名者實現控制平面簽名。所有這些失敗僅在 kube-controller-manager 日誌中報告。

這些簽名者的信任分發是帶外的。除上述之外的任何信任純屬巧合。例如，某些分發可能會將 kubernetes.io/legacy-unknown 視為 kube-apiserver 的客戶端證書，但這並非標準。所有這些用途都與 ServiceAccount 令牌 secret 的 .data[ca.crt] 沒有任何關係。該 CA 捆綁包僅保證使用預設服務（kubernetes.default.svc）驗證與 API 伺服器的連線。

自定義簽名者

你還可以引入自己的自定義簽名者，它應該具有類似的帶字首名稱，但使用你自己的域名。例如，如果你代表一個使用域名 open-fictional.example 的開源專案，那麼你可能使用 issuer.open-fictional.example/service-mesh 作為簽名者名稱。

自定義簽名者使用 Kubernetes API 頒發證書。請參閱基於 API 的簽名者。

簽名

控制平面簽名者

Kubernetes 控制平面實現每個 Kubernetes 簽名者，作為 kube-controller-manager 的一部分。

基於 API 的簽名者

REST API 使用者可以透過向要簽名的 CSR 的 status 子資源提交 UPDATE 請求來簽署 CSR。

作為此請求的一部分，status.certificate 欄位應設定為包含已簽名的證書。此欄位包含一個或多個 PEM 編碼的證書。

所有 PEM 塊都必須具有 "CERTIFICATE" 標籤，不包含任何頭，並且編碼資料必須是如 RFC5280 第 4 節中所述的 BER 編碼的 ASN.1 證書結構。

示例證書內容

-----BEGIN CERTIFICATE-----
MIIDgjCCAmqgAwIBAgIUC1N1EJ4Qnsd322BhDPRwmg3b/oAwDQYJKoZIhvcNAQEL
BQAwXDELMAkGA1UEBhMCeHgxCjAIBgNVBAgMAXgxCjAIBgNVBAcMAXgxCjAIBgNV
BAoMAXgxCjAIBgNVBAsMAXgxCzAJBgNVBAMMAmNhMRAwDgYJKoZIhvcNAQkBFgF4
MB4XDTIwMDcwNjIyMDcwMFoXDTI1MDcwNTIyMDcwMFowNzEVMBMGA1UEChMMc3lz
dGVtOm5vZGVzMR4wHAYDVQQDExVzeXN0ZW06bm9kZToxMjcuMC4wLjEwggEiMA0G
CSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDne5X2eQ1JcLZkKvhzCR4Hxl9+ZmU3
+e1zfOywLdoQxrPi+o4hVsUH3q0y52BMa7u1yehHDRSaq9u62cmi5ekgXhXHzGmm
kmW5n0itRECv3SFsSm2DSghRKf0mm6iTYHWDHzUXKdm9lPPWoSOxoR5oqOsm3JEh
Q7Et13wrvTJqBMJo1GTwQuF+HYOku0NF/DLqbZIcpI08yQKyrBgYz2uO51/oNp8a
sTCsV4OUfyHhx2BBLUo4g4SptHFySTBwlpRWBnSjZPOhmN74JcpTLB4J5f4iEeA7
2QytZfADckG4wVkhH3C2EJUmRtFIBVirwDn39GXkSGlnvnMgF3uLZ6zNAgMBAAGj
YTBfMA4GA1UdDwEB/wQEAwIFoDATBgNVHSUEDDAKBggrBgEFBQcDAjAMBgNVHRMB
Af8EAjAAMB0GA1UdDgQWBBTREl2hW54lkQBDeVCcd2f2VSlB1DALBgNVHREEBDAC
ggAwDQYJKoZIhvcNAQELBQADggEBABpZjuIKTq8pCaX8dMEGPWtAykgLsTcD2jYr
L0/TCrqmuaaliUa42jQTt2OVsVP/L8ofFunj/KjpQU0bvKJPLMRKtmxbhXuQCQi1
qCRkp8o93mHvEz3mTUN+D1cfQ2fpsBENLnpS0F4G/JyY2Vrh19/X8+mImMEK5eOy
o0BMby7byUj98WmcUvNCiXbC6F45QTmkwEhMqWns0JZQY+/XeDhEcg+lJvz9Eyo2
aGgPsye1o3DpyXnyfJWAWMhOz7cikS5X2adesbgI86PhEHBXPIJ1v13ZdfCExmdd
M1fLPhLyR54fGaY+7/X8P9AZzPefAkwizeXwe9ii6/a08vWoiE4=
-----END CERTIFICATE-----

非 PEM 內容可以出現在 CERTIFICATE PEM 塊之前或之後，並且未經驗證，以允許如 RFC7468 第 5.2 節中所述的解釋性文字。

當以 JSON 或 YAML 編碼時，此欄位是 base-64 編碼的。包含上述示例證書的 CertificateSigningRequest 將如下所示：

apiVersion: certificates.k8s.io/v1
kind: CertificateSigningRequest
...
status:
  certificate: "LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0tCk1JS..."

批准或拒絕

在簽名者根據 CertificateSigningRequest 頒發證書之前，簽名者通常會檢查該 CSR 的頒發是否已**批准**。

控制平面自動批准

kube-controller-manager 附帶了一個內建的批准者，用於 kubernetes.io/kube-apiserver-client-kubelet 簽名名稱的證書，它將節點憑據的 CSR 的各種許可權委託給授權。kube-controller-manager 將 SubjectAccessReview 資源 POST 到 API 伺服器以檢查證書批准的授權。

使用 kubectl 批准或拒絕

Kubernetes 管理員（具有適當許可權）可以使用 kubectl certificate approve 和 kubectl certificate deny 命令手動批准（或拒絕）CertificateSigningRequest。

用 kubectl 批准 CSR

kubectl certificate approve <certificate-signing-request-name>

同樣，要拒絕 CSR

kubectl certificate deny <certificate-signing-request-name>

使用 Kubernetes API 批准或拒絕

REST API 的使用者可以透過向要批准的 CSR 的 approval 子資源提交 UPDATE 請求來批准 CSR。例如，你可以編寫一個Operator，它監視特定型別的 CSR，然後傳送 UPDATE 來批准它們。

當你提出批准或拒絕請求時，根據你確定的狀態設定 Approved 或 Denied 狀態條件：

對於 Approved 的 CSR

apiVersion: certificates.k8s.io/v1
kind: CertificateSigningRequest
...
status:
  conditions:
  - lastUpdateTime: "2020-02-08T11:37:35Z"
    lastTransitionTime: "2020-02-08T11:37:35Z"
    message: Approved by my custom approver controller
    reason: ApprovedByMyPolicy # You can set this to any string
    type: Approved

對於 Denied 的 CSR

apiVersion: certificates.k8s.io/v1
kind: CertificateSigningRequest
...
status:
  conditions:
  - lastUpdateTime: "2020-02-08T11:37:35Z"
    lastTransitionTime: "2020-02-08T11:37:35Z"
    message: Denied by my custom approver controller
    reason: DeniedByMyPolicy # You can set this to any string
    type: Denied

通常將 status.conditions.reason 設定為 TitleCase 的機器友好原因程式碼；這是一個約定，但你可以將其設定為任何你喜歡的內容。如果你想新增供人工閱讀的註釋，請使用 status.conditions.message 欄位。

Pod證書請求

功能狀態： Kubernetes v1.34 [alpha] (預設停用)

PodCertificateRequests 是 API 物件，專門用於為在叢集中作為 Pod 執行的工作負載提供證書。使用者通常不直接與 PodCertificateRequests 互動，而是使用podCertificate 投射卷源，這是一項 kubelet 功能，負責安全金鑰供應和自動證書重新整理。Pod 內的應用程式只需知道如何從檔案系統讀取證書。

PodCertificateRequests 類似於 CertificateSigningRequests，但由於其用途較窄，格式更簡單。

一個 PodCertificateRequest 具有以下 spec 欄位：

  • signerName：此請求指向的簽名者。
  • podName 和 podUID：Kubelet 正在為其請求證書的 Pod。
  • serviceAccountName 和 serviceAccountUID：與 Pod 對應的 ServiceAccount。
  • nodeName 和 nodeUID：與 Pod 對應的節點。
  • maxExpirationSeconds：工作負載作者將接受的此證書的最大生命週期。如果未指定，則預設為 24 小時。
  • pkixPublicKey：應為其頒發證書的公鑰。
  • proofOfPossession：證明請求者控制 pkixPublicKey 對應的私鑰的簽名。

節點自動獲得建立 PodCertificateRequest 和讀取與其相關的 PodCertificateRequest（由 spec.nodeName 欄位確定）的許可權。如果啟用，NodeRestriction 准入外掛可確保節點只能建立與當前正在節點上執行的真實 Pod 對應的 PodCertificateRequest。

建立後，PodCertificateRequest 的 spec 是不可變的。

與 CSR 不同，PodCertificateRequests 沒有批准階段。一旦建立了 PodCertificateRequest，簽名者的控制器將直接決定是頒發還是拒絕請求。如果遇到永久錯誤，它還可以選擇將請求標記為失敗。

要執行這些操作，簽名控制器需要擁有 PodCertificateRequest 型別以及簽名名稱的相應許可權：

  • 動詞：update，組：certificates.k8s.io，資源：podcertificaterequests/status
  • 動詞：sign，組：certificates.k8s.io，資源：signers，資源名稱：<signerNameDomain>/<signerNamePath> 或 <signerNameDomain>/*

簽名控制器可以自由考慮請求中包含的資訊之外的其他資訊，但它可以依賴請求中的資訊是準確的。例如，簽名控制器可能會載入 Pod 並讀取其上設定的註解，或者對 ServiceAccount 執行 SubjectAccessReview。

為了響應請求頒發證書，簽名控制器：

  • 向 status.conditions 新增 Issued 條件。
  • 將頒發的證書放入 status.certificateChain。
  • 將證書的 NotBefore 和 NotAfter 欄位放入 status.notBefore 和 status.notAfter 欄位 — 這些欄位被非規範化到 Kubernetes API 中，以幫助除錯。
  • 建議使用 status.beginRefreshAt 開始嘗試重新整理證書的時間。

要拒絕請求，簽名控制器會將 "Denied" 條件新增到 status.conditions[]。

要將請求標記為失敗，簽名控制器會將 "Failed" 條件新增到 status.conditions[]。

所有這些條件都是互斥的，並且必須具有“True”狀態。PodCertificateRequests 上不允許其他條件型別。此外，一旦設定了任何這些條件，status 欄位將變為不可變。

像所有條件一樣，status.conditions[].reason 欄位用於包含機器可讀的程式碼，以 TitleCase 描述條件。status.conditions[].message 欄位用於供人工閱讀的自由格式解釋。

為了確保終端 PodCertificateRequests 不會在叢集中堆積，kube-controller-manager 控制器會刪除所有超過 15 分鐘的 PodCertificateRequests。所有證書頒發流程都應在 15 分鐘的限制內完成。

叢集信任包

功能狀態： `Kubernetes v1.33 [beta]` (預設啟用：false)

ClusterTrustBundle 是一個叢集範圍的物件，用於將 X.509 信任錨（根證書）分發給叢集中的工作負載。它們旨在與 CertificateSigningRequest 中的簽名者概念很好地配合使用。

ClusterTrustBundle 可以以兩種模式使用：簽名者關聯和簽名者非關聯。

常見屬性和驗證

所有 ClusterTrustBundle 物件對其 trustBundle 欄位的內容都有嚴格的驗證。該欄位必須包含一個或多個 X.509 證書，DER 序列化，每個證書都封裝在 PEM CERTIFICATE 塊中。證書必須解析為有效的 X.509 證書。

像塊間資料和塊內頭這樣的深奧 PEM 特性要麼在物件驗證期間被拒絕，要麼可以被物件的消費者忽略。此外，消費者可以按照自己的任意但穩定的順序重新排列包中的證書。

ClusterTrustBundle 物件應被視為叢集中可全域性讀取的。如果你的叢集使用 RBAC 授權，則所有 ServiceAccounts 預設都具有允許它們**獲取**、**列出**和**觀察**所有 ClusterTrustBundle 物件的許可權。如果你使用自己的授權機制，並且已在叢集中啟用了 ClusterTrustBundles，則應設定一個等效規則，使這些物件在叢集中公開，以便它們按預期工作。

如果您的叢集預設沒有列出叢集信任包的許可權，您可以模擬您有權訪問的服務帳戶以檢視可用的 ClusterTrustBundles。

kubectl get clustertrustbundles --as='system:serviceaccount:mynamespace:default'

簽名者關聯的 ClusterTrustBundle

簽名者關聯的 ClusterTrustBundle 與*簽名者名稱*相關聯，如下所示：

apiVersion: certificates.k8s.io/v1alpha1
kind: ClusterTrustBundle
metadata:
  name: example.com:mysigner:foo
spec:
  signerName: example.com/mysigner
  trustBundle: "<... PEM data ...>"

這些 ClusterTrustBundle 旨在由叢集中的特定於簽名者的控制器維護，因此它們具有以下幾個安全特性：

  • 要建立或更新簽名者關聯的 ClusterTrustBundle，您必須被允許在簽名者上進行**證明**（自定義授權動詞 attest，API 組 certificates.k8s.io；資源路徑 signers）。您可以為特定資源名稱 <signerNameDomain>/<signerNamePath> 配置授權，或匹配模式，例如 <signerNameDomain>/*。
  • 簽名者關聯的 ClusterTrustBundles **必須**以其 spec.signerName 欄位派生的字首命名。斜槓 (/) 替換為冒號 (:)，並附加一個最終的冒號。這之後是任意名稱。例如，簽名者 example.com/mysigner 可以連結到 ClusterTrustBundle example.com:mysigner:<arbitrary-name>。

簽名者關聯的 ClusterTrustBundle 通常會在工作負載中透過簽名者名稱的欄位選擇器和單獨的標籤選擇器組合來使用。

簽名者非關聯的 ClusterTrustBundle

簽名者非關聯的 ClusterTrustBundle 具有空的 spec.signerName 欄位，如下所示：

apiVersion: certificates.k8s.io/v1alpha1
kind: ClusterTrustBundle
metadata:
  name: foo
spec:
  # no signerName specified, so the field is blank
  trustBundle: "<... PEM data ...>"

它們主要用於叢集配置用例。每個未與簽名者關聯的 ClusterTrustBundle 都是一個獨立物件，這與與簽名者關聯的 ClusterTrustBundle 的慣常分組行為形成對比。

未與簽名者關聯的 ClusterTrustBundle 沒有 attest 動詞要求。相反，您使用常用機制（例如基於角色的訪問控制）直接控制對其的訪問。

為了將它們與簽名者關聯的 ClusterTrustBundle 區分開來，簽名者未關聯的 ClusterTrustBundle 的名稱**不能**包含冒號 (:)。

從 Pod 訪問 ClusterTrustBundle

功能狀態： `Kubernetes v1.33 [beta]` (預設啟用：false)

ClusterTrustBundle 的內容可以注入到容器檔案系統，類似於 ConfigMaps 和 Secrets。有關詳細資訊，請參閱clusterTrustBundle 投射卷源。

下一步

上次修改時間為 2025 年 8 月 12 日太平洋時間下午 7:56：fix: 語法錯誤 bug (bf1fda1e72)