本篇是一個 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
openssl自簽憑證 在 產生自簽憑證筆記 的推薦與評價
上次上班花很多時間處理憑證問題為了碰到下次不要花費太多時間設備根憑證不正確導致不能打API問題| 程式狂想筆記今天要還債(技術債)了主要試試看建立 ... ... <看更多>
相關內容