技術文章 » Cert Manager 申請SSL證書流程及相關概念-三

Cert Manager 申請SSL證書流程及相關概念-三

2023-01-22 12:00:44

中英文對照表

英文 英文 - K8S CRD 中文 備註
certificates Certificate 證書 certificates.cert-manager.io/v1
certificate issuers Issuer 證書頒發者 issuers.cert-manager.io
ClusterIssuer 叢集證書頒發者 clusterissuers.cert-manager.io
certificate request CertificateRequest 證書申請 certificaterequests.cert-manager.io
order Order （證書）訂單 orders.acme.cert-manager.io
challenge Challenge （證書）挑戰 challenges.acme.cert-manager.io
SelfSigned 自簽名 cert-manager Issuer 的一種
CA 證書頒發機構 Certificate Authority 的縮寫；
cert-manager Issuer 的一種
Vault 金庫 cert-manager Issuer 的一種，即 Hashicorp Vault
Venafi Venafi 線上證書辦理服務，目前用的不多。
External 外部 cert-manager Issuer 的一種
ACME 自動證書管理環境 Automated Certificate Management Environment 的縮寫；
cert-manager Issuer, 包括 HTTP01 和 DNS01

書接上回, 最後瞭解一下 cert-manager 的相關概念.

相關概念

Issuer（證書頒發者）

Issuers 和 ClusterIssuers 是 Kubernetes CRD，代表證書頒發機構（CA），能夠通過兌現證書籤名請求來生成簽名證書。所有 cert-manager 證書都需要一個被參照的簽發者，該簽發者處於準備就緒的狀態，可以嘗試兌現請求。

Issuer 型別的一個例子是 "CA"。一個簡單的CA Issuer如下。

apiVersion: cert-manager.io/v1
kind: Issuer
metadata:
  name: ca-issuer
  namespace: mesh-system
spec:
  ca:
    secretName: ca-key-pair

這是一個簡單的Issuer，將根據私鑰（私鑰儲存在 Secret 的ca-key-pair中）簽署證書。

  • Issuer: 限定在一個 NameSpace 的資源；
  • ClusterIssuer: 可以用於在所有名稱空間中頒發 "證書"。

Certificate（證書）

cert-manager 有 Certificate 的概念，定義了所需的 X.509 證書，它將被更新並保持最新。一個 Certificate 是一個 Kubernetes 的 CRD，它參照了一個 Issuer 或 ClusterIssuer，決定了什麼將被授予證書請求。

當一個 Certificate 被建立時，一個相應的 CertificateRequest 資源由 cert-manager 建立，其中包含編碼的 X.509 證書請求，Issuer reference，以及其他基於 證書 資源規範的選項。

這個 Certificate 將告訴 cert-manager 嘗試使用哪個 Issuer 來獲取域名的證書金鑰對。如果成功，得到的 TLS 金鑰和證書將被儲存在一個 secret 中，Key 分別為tls.key和tls.crt。這個 Secret 將與Certificate CRD 在同一個名稱空間。範例如下：

當證書由中間 CA 簽發，並且Issuer 可以提供簽發的證書鏈時，tls.crt的內容將是請求的證書，後面是證書鏈。

此外，如果證書頒發機構是已知的，相應的 CA 證書將被儲存在 Secret 中，金鑰為ca.crt。例如，對於 ACME 發行者，CA 是不知道的，ca.crt將不存在於acme-crt-secret中。

cert-manager 有意避免在tls.crt中新增根證書，因為在安全進行 TLS 的情況下，這些證書是無用的。

當設定一個使用者端連線到具有由私人 CA 簽署的服務證書的 TLS 伺服器時，你需要向用戶端提供 CA 證書，以便它驗證伺服器。

dnsNames欄位指定了與證書相關的 SAN 的列表。

證書生命週期

這張圖顯示了使用 ACME/Let's Encrypt Issuer 的名為cert-1的證書的生命週期。

CertificateRequest(證書申請)

CertificateRequest是 cert-manager 中的一個 Kubernetes CRD，用於向 Issuer 申請 X.509 證書。該資源包含一個 Base64 編碼的 PEM 編碼的證書請求字串，它被傳送到被參照的簽發者。一個成功的簽發將返回一個基於證書籤署請求的簽名證書。CertificateRequests通常由控制器或其他系統消費和管理，不應該由人類使用 - 除非特別需要。

CertificateRequest的spec內的所有欄位，以及任何管理的 cert-manager 註釋，都是不可改變的，建立後不能修改。

成功簽發證書籤署請求將導致對資源的更新，用簽署的證書、證書的 CA（如果可用）設定狀態，並將 Ready 條件設定為 True。如下圖：

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

條件

CertificateRequests 有一組強定義的條件，控制器或服務應該使用和依賴這些條件來決定下一步對資源採取什麼行動。

Ready

每個準備好的條件由一對Ready--一個布林值，和Reason--一個字串組成。這組值和含義如下：

Ready Reason 條件含義
False Pending CertificateRequest目前正處於等待狀態，等待其他操作的發生。這可能是由於Issuer'還不存在，或者Issuer'正在簽發證書。
False Failed 證書未能被簽發--要麼是返回的證書未能被解碼，要麼是用於簽名的參考簽發者的範例失敗。它的控制器將不會對CertificateRequest採取進一步行動。
True Issued 被參照的 Issuer 已成功簽發了一份經簽名的證書。

ACME Orders 和 Challenges

cert-manager 支援從 ACME 伺服器請求證書，包括從 Let's Encrypt，使用 ACME Issuer。這些證書通常在公共網際網路上被大多數計算機所信任。為了成功申請證書，cert-manager 必須解決 ACME challenge，完成這些 challenge 是為了證明客戶擁有被申請的 DNS 地址。

為了完成這些 challenge，cert-manager 引入了兩種 CRD 型別：Orders 和 Challenges。

Orders （訂單）

Orders資源被 ACME 發行者用來管理 ACME '訂單' 的生命週期，以獲得簽名的 TLS 證書。關於 ACME 訂單和域名驗證的更多細節可以在 Let's Encrypt 網站 這裡 找到。一個訂單代表了一個單一的證書請求，一旦一個新的 CertificateRequest 資源參照 ACME 發行人，該訂單就會自動建立。一旦 Certificate 資源被建立、規格改變或需要更新，CertificateRequest資源將由 cert-manager 自動建立。

作為終端使用者，您將永遠不需要手動建立一個 Order 資源。一旦建立，Order 不能被改變。相反，必須建立一個新的 Order資源。

Order 資源封裝了該 "訂單" 的多個 ACME Challenge，因此，將管理一個或多個 Challenge 資源。

Challenges （挑戰）

Challenges 資源被 ACME 發行者用來管理 ACME challenge 的生命週期，為了完成對一個 DNS 名稱/標識的 "認證"，必須完成 challenge。

當一個 Order 資源被建立時，order 控制器將為每個正在被 ACME 伺服器認證的 DNS 名稱建立 Challenge資源。

作為終端使用者，你永遠不需要手動建立一個 Challenge 資源。一旦建立，Challenge就不能被改變。相反，必須建立一個新的 Challenge資源。

Challenge 生命週期

在 Challenges 資源被建立後，它最初將被排隊處理。在 challenge 被 "安排" 開始之前，處理將不會開始。這種排程過程可以防止一次嘗試太多的 challenge，或一次嘗試對同一 DNS 名稱的多個 challenge。

一旦 challenge 被安排，它將首先與 ACME 伺服器進行 "同步"，以確定其當前狀態。如果 challenge 已經有效，它的 status 將被更新為 valid，並且還將設定status.processing = false以 "取消計劃"。

如果 challenge 仍然 "pending"，challenge 控制器將使用設定的解決方法（HTTP01 或 DNS01 之一）"present" challenge。一旦 challenge 被 "present"，它將設定status.presented = true。

一旦 "present"，challenge 控制器將執行 "self check"，以確保 challenge 已經 "propagated（已傳播）"（即權威的 DNS 伺服器已被更新以作出正確響應，或 ingress 資源的變化已被 ingress controller 觀察到並正在使用）。

如果自檢失敗，cert-manager 將以固定的 10 秒重試時間間隔重試自檢。沒有完成自檢的 challenge 將繼續重試，直到使用者通過重試 "訂單"（通過刪除 "訂單 "資源）或修改相關的 "證書 "資源來解決任何設定錯誤進行干預。

一旦自檢通過，與此 challenge 相關的 ACME "authorization（認證） "將被 "accepted（接受）"。

接受認證後的最終狀態將被複制到 challenge 的status.state 欄位，如果 ACME 伺服器試圖驗證 challenge 時發生錯誤，也會複製 "error reason（錯誤原因）"。

一旦 challenge 進入 valid、invalid、expired 或 revoked （復原）狀態，它將設定 status.processing = false，以防止 ACME challenge 的任何進一步處理，如果有積壓的 challenge 要完成，允許安排另一個 challenge。

Challenge 排程

cert-manager 並不試圖一次處理所有的 challenge ，而是對 challenge 進行 "排程"。

這個排程器對同時進行的 challenge 的最大數量設定了上限，並且不允許對同一 DNS 名稱和解算器型別（HTTP01或DNS01）的兩個 challenge 同時完成。

一次可以處理的最大 challenge 數量是 60 個，原因是 ddff78

系列文章