不重要的前言

• 這串鐵人文章來到了第十篇，還在看文件階段，今天本來沒有要先寫機敏資訊 Secret 這項的，還有其他基本款，只不過礙於「工作上」接獲一個臨時案件需要用到，所以就順便來説説，在實際工作上會發生的事件，然後說明可能的做法。
• 由於跳過了想寫的東西，所以有些前幾回還沒提到的東西，之後再補充。

前言

這篇文章會快速說明幾種憑證的用途，做法。 在這個維運案件中，因為有多座叢集「PROD」、「UAT」、「SIT」。 在不同的叢集中，簽證的來源也會有所不同，能接受的憑證可靠程度也會不同。 演示如何在 OCP 叢集中調查所使用到的憑證，進行更新。

什麼是憑證

發展的脈絡可以用很簡約的方式列在下方

靜態網站 / 明文傳輸

古早時代，自從有 HTTP 協議之後，使用者可以透過瀏覽器，訪問伺服器，還沒有「會員系統」的概念，誰來訪問，就全部都給他，這樣的架構像是去大興善寺領一碗平安結緣麵來吃。 提供服務的伺服器，通常不會驗證請求端的身份，使用者請求，伺服器就明文回傳給請求端。 當然這是服務商不會因為使用者不同而有所區別，通通都回一樣的東西，請求端和服務端，雙方互信，假設不存在惡意的使用者的前提下。

Client & Server 架構: 使用者透過瀏覽器連網站，使用者透過程式如 PCMan 連上 BBS，⋯⋯還有很多。

動態的網頁 / 偽造的網站

• 隨著透過網路能提供的服務越來越多，使用者開始會需要註冊，提供更多個資給網站，或是透過付費購買服務或商品。 這時候就會出現一些街坊鄰居，開始在公開的通道上，收聽傳輸內容。

加密傳輸 / 對稱式密碼系統

• 為了避免「鄰居」偷聽，於是 「加密傳輸」 就有其必要，避免機敏資訊被聽走。 收發雙方可以事先約定好用同一組金鑰加密解密，這個叫對稱式金鑰系統。
• 使用者一多，就必須要事先存一堆金鑰，如果伺服器的金鑰外流，之後要換金鑰也會需要一個一個客戶重新約定。

加密傳輸 / 非對稱式密碼系統

• 於是非對稱金鑰系統，係透過眾多數學公式上，如橢圓曲線公式 y^2=x^3+ax+b 或是 兩個大質數相乘後，進行質因數分解。具有單向門(One-Way Trap)特性的公式，即正向運算很容易，反向運算很麻煩複雜，除非你有關鍵因子；對應生成兩把金鑰，透過「公鑰加密」和「私鑰解密」的密碼系統，稱為非對稱金鑰。
• 當瀏覽器與伺服器初次見面時，伺服器端先丟給使用者一把「公鑰」，說以後你要給我的資料，都用這個公鑰加密吧！
• 因為非對稱金鑰，是伺服器端自己產生的，假設他有好好保管好私鑰，都沒外流，那麼沒有私鑰鄰居或路人，想要透過暴力法嘗試解密，因為算力有限，有生之年是做不到的。
• 使用者把自己的個資 key 好了之後，加密傳送給伺服器。
• 伺服器端使用私鑰解開訊息。

雖然加密傳輸了，但只能保證一件事情，就是使用者和某個伺服器，進行了加密傳輸。

偽造的網站 / 中間人攻擊

• 後來「街坊鄰居」變壞了，聽不到有點生氣，想到了一個方法可以偷聽到內容。
• 壞鄰居先假裝自己是正版的網站、伺服器，可能透過綁架你的 resolv.conf 還是在你的網路環境中，篡改了 DNS 查詢結果，使你走錯路。

這不就是你要買正版的「呷七碗」，結果有人仿造了一樣的招牌，使你跑去買了山寨版的「呷七碗」買東西。

參考連結： https://www.chinatimes.com/realtimenews/20140304003653-260503?chdtv
參考連結： https://www.cna.com.tw/news/asoc/202507170055.aspx

又或者歹徒給你了一串看起來是正版網站的連結，但他已經事先污染你的環境，使你訪問「釣魚網站」，騙取你的個資或是信用卡號。
我是陳冠希，我現在在LA，我遇到一些很壞很壞的人，一些 Gangster，現在我需要你的幫助，微信轉帳 300 塊，幫我回到香港，你懂我意思嗎？ 我向你敬禮，Salute ！
https://www.youtube.com/watch?v=K4ku8tNY6SM

三百！ 懂我意思嗎？

憑證授權中心 (CA)

• 為了避免壞人假裝陳冠希，為了補全非對稱金鑰系統，所以在網路架構上，需要透過一個「公正的第三方」 —— 憑證授權中心(Certificate Authority ，縮寫成 CA)，來公告正版陳冠希使用的公鑰。
• 正版的陳冠希 和 盜版的陳冠希 各自當然都可以產生不同對公鑰私鑰。
• 只有那個公鑰被傳送到 CA 且由 CA 幫忙背書的，才是正版陳冠希。
• 那個「由 CA 背書的陳冠希公鑰」，便是 「陳冠希的憑證」。
• 在這個含有 CA 的系統中，CA 是被假設成不會被攻破，不會被偽造的。 使用協定的成員都要相信 CA。

說了這麼多，找人背書，都會有個期限。 而且是要花錢的！！
在台灣，常見的就那幾種： 政府憑證中心、TWCA⋯⋯等；免費的是 Let's Encrypt。
因為免費用了很久，就特別要提一下，Let's Encrypt 是一個由非營利組織Internet Security Research Group (ISRG) 營運的憑證機構。 它是一個由公眾信任的CA，與其他付費CA 類似，其目的就是為網站提供可被瀏覽器信賴的SSL/TLS 憑證。
還有自己簽署的憑證（Self-signed），即是那些自己幫自己背書的憑證，會被瀏覽器視為不可信任。
https://gcp.nat.gov.tw/views/about/about_1t.html
https://letsencrypt.org/certificates/
https://www.twca.com.tw/

調查流程

在前言的部分提到，因為憑證會有效期，要調查即將過期的憑證，主要的脈絡如下。

調查手法

1. 找出叢集內的所有使用中的路由
   • 在這一步，透過指令可以調查出各條 OCP Route 的 Name 以及...
     • 所屬的 Namespace
     • 所使用的 Host / Port / (Path)
     • 所屬的 Services
     • 轉送機制 Termination / 相關說明參考: https://docs.redhat.com/en/documentation/openshift_container_platform/4.8/html/networking/configuring-routes#CO95-1
2. 找出這些路由，理解 Termination 後，區別加解密發生的地點，才能知道憑證被套在哪些地方
   • 參考資料：OpenShift router encryption options in one picture
   • (基於站在巨人肩膀上，我就先觀看不重繪這張圖，看官們可以從上述連結去觀察)
   • 在 OCP 的叢集解決方案，OpenShift Router 是 Reverse Proxy (反向代理)。
   • Unencrypt
     • 使用者 -- (不加密) --> OpenShift Router (轉送) -- (不加密) --> Pod
     • 使用者 <-- (不加密) -- OpenShift Router (轉送) <-- (不加密) -- Pod
   • Edge
     • 使用者 -- (加密_A段) --> OpenShift Router (解密後) -- (不加密) --> Pod
     • 使用者 <-- (加密_B段) -- OpenShift Router (加密後) <-- (不加密) -- Pod
   • Re-encrypt
     • 使用者 -- (加密_A段) --> OpenShift Router (解開後，再加密) -- (加密_B段) --> Pod
     • 使用者 <-- (加密_D段) -- OpenShift Router (解開後，再加密) <-- (加密_C段) -- Pod
   • Passthrough
     • 使用者 -- (加密_A段) --> OpenShift Router (直接轉送) -- (加密_A段) --> Pod
     • 使用者 <-- (加密_B段) -- OpenShift Router (直接轉送) <-- (加密_B段) -- Pod
3. 在得知上面四種模式後，還需要知道憑證可能被附掛的形式
   • 走 Unencrypt 模式，沒有用到憑證。
   • 走 Edge 模式，Pod 和 Reverse Proxy 間不加密，加解密在 OpenShift Router 被解開，所以加解密只跟 使用者 <--> Router 有關
   • 走 Re-Passthrough 模式，加解密的事情，是 使用者 <--> Pod 之間的事情
     • 被寫在 Secret 中 (best practice，棒棒)
     • 被寫在 ConfigMap 中 (bad boy，壞壞)
     • 被寫在 容器 內部 (根本就是頑劣份子)
   • 走 Re-encrypt 模式，除了第一段 使用者 <--> Router，還有後面一段 Router <--> Pod，可以視為前面兩項的綜合體。
4. 從 Service / Namespace 取得 Pod 的 Label Selector
5. 用 Describe 的方式查看 Pod 怎麼被叫起來的，到底是棒棒，壞壞，還是頑劣份子⋯⋯

結論

• 下回待續
  

參考資料

1. OCP 文件 / Chapter 4. Certificate types and descriptions
2. 宅宅新聞 / 「公開金鑰加密」的迴轉壽司！？
3. Twitter / https://x.com/wsuzume/status/1620411460093612032