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 去處理。

本篇是一個 Kubernetes 的入門介紹文，探討 Kubernetes 內要如何透過 SSL/TLS 憑證來加強應用程式之間的連線。

本篇文章不使用任何第三方套件，反而是從 Kubernetes 內建的資源功能出發去探討，理解 Kubernetes 的能力與極限其實長久下來對於評估各種專案都滿有幫助的。

Kubernetes 的 Secret 除了使用 base64 作為編碼技術外，其實本身也提供不少類型方便管理人員使用，譬如本文提到的 tls 類型， container registry credential 以及最廣泛使用的 generic 等。

Secret(tls類型)本身創建時會吃兩個參數，分別是 tls.crt 與 tls.key，接者這類型的 secret 可以與 ingress 進行整合，將 TLS 給掛載到 Ingress 物件中並且同時執行 TLS Termination，讓 Ingres 與外部連線使用 HTTPS 而內部服務則使用 HTTP 來溝通。

文章中提到如何透過 openssl 創建一個 self-signed 的憑證，並且針對 self-signed 的特性進行討論，其列出了四個 self-signed 的缺點

1. 瀏覽器連接到這些 self-signed 憑證的網站時都會露出警告告知使用者，因此這類型的憑證不適合任何正式生產環境使用
2. 因為 self-signed 就是開發者自行創造，缺少第三方可信任機關的認證，因此惡意攻擊者可以輕鬆換掉服務上的簽證，畢竟瀏覽器本來就覺得簽證有問題，無法分辨到底是先前的自簽憑證還是被替換的憑證。
3. 第三方CA都會針對發行的憑證給予一些保固與服務，這部分是自簽沒有辦法擁有的
4. 愈來愈多的使用者會不太願意瀏覽與使用沒有合法且信任憑證的網站

作者提到 Kubernetes 內部雖然有一個 CA，但是不推薦把任何服務相關的憑證都跟其扯上關係，
因為該 CA 是給 Kubernetes 內部控制平面使用的，譬如 kubelet, API Server, Controller, Scheduler 等元件彼此溝通中間使用的。

文章最後作者示範透過 cfssl 的該指令幫一個內部服務創建一個憑證，由於內部服務會透過 Kubernetes Service 提供的 DNS 來存取，因此創建憑證時會於 CN 欄位補上 alternative 的名稱，把 service.svc.... 之類的全部都補上。

https://medium.com/avmconsulting-blog/how-to-secure-applications-on-kubernetes-ssl-tls-certificates-8f7f5751d788