ref: https://medium.com/flant-com/cert-manager-lets-encrypt-ssl-certs-for-kubernetes-7642e463bbce

這篇文章是個分享文，作者分享如何使用 cert-manager 這個工具透過 lets-encrypts 來獲得一個被認證的 SSL 憑證供 kubernetes 內部應用使用。

根據 CNCF Technology Radar(https://radar.cncf.io/2021-02-secrets-management) 的介紹，目前 Cert-Manager 幾乎是 k8s 內管理憑證最為知名的專案。
本篇文章針對幾個四種不同的使用情境來介紹如何使用 cert-manager，以下針對每個用法給一些摘要。

前期提要：
Kubernetes 會使用 SSL 憑證的大部分情況都是透過 Ingress 這個物件去描述需要使用 Certificate，所以文章的範例都會是基於 Ingress 的使用下手。
譬如說 Ingress 想要使用開啟 TLS 的功能，需要使用一個 secret，而 Cert-Manager 則會基於其設定最後產生出一個符合 Certificate 用法的 Secert 物件給 Ingress 使用。

Self-signed certificate
第一種是最簡單也是最直接的用法，透過 cert-manager 來產生一組自行簽署的簽證
正常情況下產生後的自簽憑證預設是不被信任的，畢竟預設情況下並沒有加入一個 CA，因此簽出來的憑證用瀏覽器打開還是會呈現不可信任
如果環境有事先準備好 CA 的話，是可以將該 CA 加入到 cert-manager 的設定中，這樣就可以簽出一個被信任的憑證了。

Let’s Encrypt certificate with the HTTP/DNS validation
第二個則是最普遍的用法，就是透過 Let's Encrypt 的服務來獲得一個可以被信任的憑證，而 Cert-Manager 目前支持兩種 ACME 的認證方式，分別是 HTTP 以及 DNS，這兩個方式最主要的目的都是要確認
申請者是該申請 domain 的擁有者，所以可以透過不同的方式來驗證。

如果想要使用 DNS 來進行驗證的則必須要確認該域名管理的服務商是否有提供相關的 API 同時該 API 是否 cert-manager 有支援，文章中作者使用 CloudFlare 來當範例展示一下如何使用 DNS 挑戰來驗證相關的 TXT Record.
由於 DNS Record 本身會有 Propagation 延遲傳遞的問題，因此驗證上通常會比使用 HTTP 的方式還來得慢一點。
Cert-Manager 本身也支援兩種方式同時使用。

另外使用 Let's Encrypt 時要特別注意，非常推薦一開始使用 Let's Encrypt Staging 的服務來進行測試，不要一開始就直接使用 Production 的 API，因為 Production 會將短時間內發送大量請求的網域給停權一陣子，要等待一段時間後才可以再次發送。
因此開發測試過程請先使用 Staging 的 API，待一切沒問題後才轉向 Production API。

Using special Ingress annotations
這種方法其實是簡化維運者的工作，Cert-Manager 會有一個額外的 Controller 去監聽所有的 Ingress 物件，如果該 Ingress 物件的 Annotation 有描述跟憑證相關的資訊，該 Controller
就會自動創造 cert-manager 相關的資源，讓管理者減少需要自己部署的物件數量，反而將部分操作轉交給 Controller 去處理。

DSM 7.0設定完 QuickConnect 後，從DDNS到SSL憑證的申請都在背後自動完成，這次升上DSM 7.0，除了速度提升與功能增加外，智能動作也是也是相當有感。

Synology Quickconnet這麼實用，由於SSL安全憑證越來越受到重視，DSM 7.0設定完 QuickConnect 後，從DDNS到SSL憑證的申請都在背後自動完成，這次升上DSM 7.0，除了速度提升與功能增加外，智能動作也是也是相當有感。