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

雖然是個人網站 但是搜尋引擎現在都會對有加密的網站加分 所以為了要對搜尋引擎優化, 只能在不得已的情況下將自己的網站做SSL的加密 只是傳統的SSL售價並不便宜, 對於部落格這種應用來說, 用免費的就很夠囉! 也可以避免受到廠商的剝削 所以我們可以直接到SSL for Free網站申請就好 他們提供的是Let’s Encrypt的免費憑證, 缺點是每次只有90天 好在申請簡單又方便, 90天更新的問題也有方法用自動處理, 所以也自然成為許多網站使用憑證的首選! 首先打開SSL for Free這個網站 ( 輸入要申請的網域 以水哥自己的網站為例 前面打*的原因是指要申請wildcard的憑證 這樣就可以一個憑證用在很多子網域 像是www.mshw.info, blog.mshw.info, app.mshw.info等等 如果你直接打以上的網域, www.mshw.info 就會只能用在www.mshw.info, 如果今天還要用在app.mshw.info就會需要再申請一次 申請前需要對網域做驗證 這個部分並不難, 只需要到申請網域的地方新增修改一筆DNS的TXT紀錄就可以 主要是要確認你申請的網域是不是你自己擁有的 畢竟, 應該沒有人希望別人盜用你的資料去申請你的身分證吧? 新增紀錄的部分 要看你是用哪一間廠商申請像是Namecheap, Godaddy, NS1等等 也或許你是使用其他網域服務代管, 像是Cloudflare, 百度雲加速等等的 以Cloudflare為例 就新增一筆TXT類別的紀錄, 然後把內容設定成剛剛網址上給你那串 而TTL建義設定成1秒 這樣才會比較快更新, 但Cloudflare最少是2分鐘(120秒) 所以你就得等上2分鐘才能驗證成功 沒法成1秒的話會跳警告 不過這個部分可以忽略, 紅字只是提醒你你沒有設定成1秒 只要下方的TXT紀錄查出來跟剛剛設定的一樣就可以跳下一步了 像是NS1就可以設定成1秒 所以幾乎是設定好就馬上能驗證, 不需要過多的時間等待 [ 32 more words ]
https://mshw.info/mshw/?p=19540

【07/04～07/10】一周資安新聞回顧

1⃣使用者密碼重設流程驗證極為隨便！日本7-Eleven行動支付甫推出就驚傳大量盜刷事件
2⃣冒牌三星更新應用程式的廣告軟體出現在Google Play市集
3⃣搭臉書加密貨幣熱潮，有心人士大量註冊相關網域名稱，恐出現新詐騙攻擊
4⃣macOS惡意程式偽裝成Flash播放器軟體
5⃣D-Link產品安全訴訟案與FTC達成和解，承諾全面提升網路設備產品安全
6⃣首個針對DNS over HTTPS的惡意程式出現
7⃣兩名開發人員的OpenPGP憑證遭垃圾簽章淹沒
8⃣數位身分證上線在即，公民團體與學者認為政府應立專屬法規，並重視潛在資安風險