新消息：在Twitter和Mastodon上獲取專案更新

CertificateRequest 資源

apiVersion: cert-manager.io/v1
kind: CertificateRequest

CertificateRequest 是 cert-manager 中一個命名空間的資源，用於從 Issuer 請求 X.509 憑證。該資源包含一個 Base64 編碼的 PEM 編碼憑證請求字串，該字串會被傳送至參考的簽發者。成功簽發後，將根據憑證簽署請求返回已簽署的憑證。CertificateRequest 通常由控制器或其他系統使用和管理，不應由人類使用 - 除非有特殊需要。

一個簡單的 CertificateRequest 看起來如下

apiVersion: cert-manager.io/v1
kind: CertificateRequest
metadata:
  name: my-ca-cr
spec:
  request: LS0tLS1CRUdJTiBDRVJUSUZJQ0FURSBSRVFVRVNULS0tLS0KTUlJQzNqQ0NBY1lDQVFBd2daZ3hDekFKQmdOVkJBWVRBbHBhTVE4d0RRWURWUVFJREFaQmNHOXNiRzh4RFRBTApCZ05WQkFjTUJFMXZiMjR4RVRBUEJnTlZCQW9NQ0VwbGRITjBZV05yTVJVd0V3WURWUVFMREF4alpYSjBMVzFoCmJtRm5aWEl4RVRBUEJnTlZCQU1NQ0dwdmMyaDJZVzVzTVN3d0tnWUpLb1pJaHZjTkFRa0JGaDFxYjNOb2RXRXUKZG1GdWJHVmxkWGRsYmtCcVpYUnpkR0ZqYXk1cGJ6Q0NBU0l3RFFZSktvWklodmNOQVFFQkJRQURnZ0VQQURDQwpBUW9DZ2dFQkFLd01tTFhuQkNiRStZdTIvMlFtRGsxalRWQ3BvbHU3TlZmQlVFUWl1bDhFMHI2NFBLcDRZQ0c5Cmx2N2kwOHdFMEdJQUgydnJRQmxVd3p6ZW1SUWZ4YmQvYVNybzRHNUFBYTJsY2NMaFpqUlh2NEVMaER0aVg4N3IKaTQ0MWJ2Y01OM0ZPTlRuczJhRkJYcllLWGxpNG4rc0RzTEVuZmpWdXRiV01Zeis3M3ptaGZzclRJUjRzTXo3cQpmSzM2WFM4UkRjNW5oVVcyYU9BZ3lnbFZSOVVXRkxXNjNXYXVhcHg2QUpBR1RoZnJYdVVHZXlZUUVBSENxZmZmCjhyOEt3YTFYK1NwYm9YK1ppSVE0Nk5jQ043OFZnL2dQVHNLZmphZURoNWcyNlk1dEVidHd3MWdRbWlhK0MyRHIKWHpYNU13RzJGNHN0cG5kUnRQckZrU1VnMW1zd0xuc0NBd0VBQWFBQU1BMEdDU3FHU0liM0RRRUJDd1VBQTRJQgpBUUFXR0JuRnhaZ0gzd0N3TG5IQ0xjb0l5RHJrMUVvYkRjN3BJK1VVWEJIS2JBWk9IWEFhaGJ5RFFLL2RuTHN3CjJkZ0J3bmlJR3kxNElwQlNxaDBJUE03eHk5WjI4VW9oR3piN0FVakRJWHlNdmkvYTJyTVhjWjI1d1NVQmxGc28Kd005dE1QU2JwcEVvRERsa3NsOUIwT1BPdkFyQ0NKNnZGaU1UbS9wMUJIUWJSOExNQW53U0lUYVVNSFByRzJVMgpjTjEvRGNMWjZ2enEyeENjYVoxemh2bzBpY1VIUm9UWmV1ZEp6MkxmR0VHM1VOb2ppbXpBNUZHd0RhS3BySWp3ClVkd1JmZWZ1T29MT1dNVnFNbGRBcTlyT24wNHJaT3Jnak1HSE9tTWxleVdPS1AySllhaDNrVDdKU01zTHhYcFYKV0ExQjRsLzFFQkhWeGlKQi9Zby9JQWVsCi0tLS0tRU5EIENFUlRJRklDQVRFIFJFUVVFU1QtLS0tLQo=
  isCA: false
  usages:
  - signing
  - digital signature
  - server auth
  # 90 days
  duration: 2160h
  issuerRef:
    name: ca-issuer
    # We can reference ClusterIssuers by changing the kind here.
    # The default value is Issuer (i.e. a locally namespaced Issuer)
    kind: Issuer
    group: cert-manager.io

這個 CertificateRequest 將使 cert-manager 嘗試從預設簽發者群組 cert-manager.io 中的 Issuer ca-issuer 請求憑證，並根據憑證簽署請求返回憑證。其他群組可以在 issuerRef 內指定，這會將目標簽發者更改為您可能已安裝的其他外部第三方簽發者。

該資源也公開了將憑證聲明為 CA、金鑰用途和請求的有效期限的選項。

CertificateRequest 的 spec 中的所有欄位，以及任何受管理的 cert-manager 註解，都是不可變的，並且在建立後無法修改。

成功簽發憑證簽署請求將導致資源更新，設定狀態並包含已簽署的憑證、憑證的 CA（如果可用），並將 Ready 條件設定為 True。

無論憑證簽署請求的簽發是否成功，都不會重試簽發。其他控制器有責任管理 CertificateRequest 的邏輯和生命週期。

條件

CertificateRequest 有一組明確定義的條件，控制器或服務應該使用並依賴這些條件來決定下一步對資源採取哪些操作。

就緒 (Ready)

每個就緒條件都包含一對 Ready - 布林值，以及 Reason - 字串。值和含義的集合如下：

就緒 (Ready)原因 (Reason)條件含義
False待處理 (Pending)CertificateRequest 目前處於待處理狀態，等待其他操作發生。這可能是因為 Issuer 尚不存在，或者 Issuer 正在簽發憑證。
False失敗 (Failed)憑證簽發失敗 - 要么是返回的憑證無法解碼，要么是簽署時使用的參考簽發者實例失敗。其控制器不會對 CertificateRequest 執行任何進一步的操作，並且可以認為其已最終失敗。
True已簽發 (Issued)已由參考的 Issuer 成功簽發已簽署的憑證。

此條件應由簽發者設定。

已拒絕 (Denied)

已拒絕 (Denied)原因 (Reason)條件含義
True<核准者名稱>CertificateRequest 已被核准者拒絕。可以認為此 CertificateRequest 已最終失敗。

此條件應僅由核准者設定。

已核准 (Approved)

已核准 (Approved)原因 (Reason)條件含義
True<核准者名稱>CertificateRequest 已由核准者核准。此 CertificateRequest 已核准，可以由簽發者簽發。

此條件應僅由核准者設定。

無效請求 (InvalidRequest)

無效請求 (InvalidRequest)原因 (Reason)條件含義
True<原因>CertificateRequest 無效。可以認為此 CertificateRequest 已最終失敗。

使用者資訊 (UserInfo)

CertificateRequest 在規範中包含一組 UserInfo 欄位，即：username、groups、uid 和 extra。這些值包含建立 CertificateRequest 的使用者。如果 CertificateRequest 是由 Certificate 資源建立的，則此使用者將是 cert-manager 本身，否則將是直接建立 CertificateRequest 的使用者。

警告：這些欄位由 cert-manager 管理，絕不應該由其他任何內容設定或修改。建立 CertificateRequest 時，這些欄位將被覆寫，並且任何嘗試修改它們的請求都會被拒絕。

核准 (Approval)

可以核准或拒絕 CertificateRequest。這些互斥的條件決定了 CertificateRequest 是否由其管理的簽署者簽署。

  • 如果沒有已核准的條件，簽署者不應該簽署受管理的 CertificateRequest。
  • 簽署者將簽署具有已核准條件的受管理 CertificateRequest。
  • 簽署者永遠不會簽署具有已拒絕條件的受管理 CertificateRequest。

這些條件是永久的，一旦設定就無法修改或更改。

NAMESPACE      NAME                    APPROVED   DENIED   READY   ISSUER       REQUESTOR                                         AGE
istio-system   service-mesh-ca-whh5b   True                True    mesh-ca      system:serviceaccount:istio-system:istiod         16s
istio-system   my-app-fj9sa                       True             mesh-ca      system:serviceaccount:my-app:my-app               4s

行為

「已核准」和「已拒絕」條件是 CertificateRequest 上的兩種不同條件類型。這些條件的狀態必須僅為 True，並且是互斥的（即 CertificateRequest 不能同時具有「已核准」和「已拒絕」條件）。此行為在 cert-manager 驗證 admission webhook 中強制執行。

「核准者」是負責設定「已核准」/「已拒絕」條件的實體。至於哪些 CertificateRequest 由該核准者管理，則取決於核准者的實作。

「已核准」/「已拒絕」條件的「原因」欄位應設定為誰設定了條件。誰可以根據核准者實作的方式進行解釋。例如，它可能包含核准策略控制器的 API 群組，或手動請求的用戶端代理程式。

「已核准」/「已拒絕」條件的「訊息」欄位應設定為為什麼設定條件。同樣，為什麼可以根據核准者實作的方式進行解釋。例如，核准此請求的資源名稱、導致請求被拒絕的違規行為，或手動核准請求的團隊。

核准者控制器

預設情況下，cert-manager 將執行一個內部核准控制器，該控制器將自動核准任何命名空間中引用任何內部簽發者類型的所有 CertificateRequest： cert-manager.io/Issuer、cert-manager.io/ClusterIssuer。

停用內部自動核准者

若要停用此控制器，請在 Helm 圖表中將 disableAutoApproval 值設定為 true

# ⚠️ This Helm option is only available in cert-manager v1.15.0 and later.
--set disableAutoApproval=true

使用內部自動核准者核准其他簽發者

或者，為了讓內部核准者控制器核准引用外部簽發者的 CertificateRequest，請在 Helm 圖表中將簽發者新增至 approveSignerNames 清單，或將 approveSignerNames 值設定為空清單，以核准所有簽發者（內部和外部）。

# ⚠️ This Helm option is only available in cert-manager v1.15.0 and later.
--set approveSignerNames[0]="issuers.cert-manager.io/*" \
--set approveSignerNames[1]="clusterissuers.cert-manager.io/*" \
\
--set approveSignerNames[2]="issuers.my-issuer.example.com/*" \
--set approveSignerNames[3]="clusterissuers.my-issuer.example.com/*"

RBAC 語法

當使用者或控制器嘗試核准或拒絕 CertificateRequest 時，cert-manager webhook 將評估它是否具有足夠的權限來執行此操作。這些權限基於請求本身 - 特別是請求的 IssuerRef。

apiGroups: ["cert-manager.io"]
resources: ["signers"]
verbs: ["approve"]
resourceNames:
 # namesapced signers
 - "<signer-resource-name>.<signer-group>/<signer-namespace>.<signer-name>"
 # cluster scoped signers
 - "<signer-resource-name>.<signer-group>/<signer-name>"
 # all signers of this resource name
 - "<signer-resource-name>.<signer-group>/*"

以下是一個 ClusterRole 的範例，它將授予設定 CertificateRequest 的「已核准」和「已拒絕」條件的權限，這些 CertificateRequest 引用群集範圍的 myissuers 外部簽發者，位於 my-example.io 群組中，名稱為 myapp

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: my-example-io-my-issuer-myapp-approver
rules:
  - apiGroups: ["cert-manager.io"]
    resources: ["signers"]
    verbs: ["approve"]
    resourceNames: ["myissuers.my-example.io/myapp"]

如果核准者沒有足夠的權限（如上所述）來設定「已核准」或「已拒絕」條件，cert-manager 驗證 admission webhook 將會拒絕該請求。

  • RBAC 權限必須在群集範圍內授予
  • 命名空間簽署者使用 <signer-resource-name>.<signer-group>/<signer-namespace>.<signer-name> 的語法表示
  • 群集範圍簽署者使用 <signer-resource-name>.<signer-group>/<signer-name> 的語法表示
  • 核准者可以透過 <signer-resource-name>.<signer-group>/* 獲准核准所有命名空間
  • apiGroup 必須始終為 cert-manager.io
  • 資源必須始終為 signers
  • 動詞必須始終為 approve，這會授予核准者設定「已核准」和「已拒絕」條件的權限

以下範例顯示如何簽署所有命名空間中的所有 myissuer 簽署者，以及在 my-example.io 群組中名稱為 myapp 的 clustermyissuers

resourceNames: ["myissuers.my-example.io/*", "clustermyissuers.my-example.io/myapp"]

以下範例顯示如何在 foo 和 bar 命名空間中簽署名稱為 myapp 的 myissuer

resourceNames: ["myissuers.my-example.io/foo.myapp", "myissuers.my-example.io/bar.myapp"]

給開發人員的內部運作圖