中英文對照表
| 英文 | 英文 - 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
系列文章
?️ 參考文件
- cert-manager - cert-manager Documentation
- 使用 cert-manager 為 dnspod 的域名簽發免費證書 | kubernetes 學習筆記 (imroc.cc)
三人行, 必有我師; 知識共享, 天下為公. 本文由東風微鳴技術部落格 EWhisper.cn 編寫.