本篇文章是個經驗分享系列文，作者探討 Kubernetes 內 15 種不被建議的部署策略與模式。
作者之前曾經撰寫過 Contianer 架構底下的部署模式探討，而本系列文(三篇)則是著重於如何將這些 containers 透過 Kubernetes 給部署到生產環境，總共會探討十五種不推薦的模式，接下來的三篇文章將會介紹各五種不好的模式。

Using containers with the latest tag in Kubernetes deployments
任何 container 的 image 都不應該使用 latest，因為 latest 本身沒有任何意義，這會使得維運人員沒有辦法掌握到底當前部署的版本是什麼，更嚴重的情況適當 latest 搭配 PullPolicy:Always 時會產生更為嚴重的問題。因為 Always 的策略導致每次 Pod 部署時都會重新抓取 image，所以一個 deployment 中，多個使用 latest tag 的 Pod 但是其實使用的 image hash 是不同的。

作者認為比較好的做法有
1. 所有 container image 都是不可修改的，一旦建立就禁止覆蓋，有任何改動就進版
2. 部署用的 image tag 使用有意義的版本名稱

補充: 實際上 pull image 也可以使用 sha256，譬如 "docker pull hwchiu/kubectl-tools@sha256:acfb56059e6d60bf4a57946663d16dda89e12bfb1f8d7556f277e2818680e4c8"

Baking the configuration inside container images
任何 contaienr image 建置的時候應該都要往通用的方向去設計，而不是參雜各種設定在裡面。著名的 12-factor app 裡面也有提到類似個概念，建置好的 image 應該要可以 build once, run everywhere，動態的方式傳入不同的設定檔案，而不是把任何跟環境有關的資訊都寫死
舉例來說，如果 image 內包含了下列設定(舉例，包含不限於)
1. 任何 IP 地址
2. 任何帳號密碼
3. 任何寫死的 URL

作者認為比較好的做法有
1. 透過動態載入的方式來設定運行時的設定，譬如Kubernetes configmaps, Hashicorp Consul, Apache Zookeeper 等
2. 根據不同程式語言與框架甚至可以做到不需要重啟容器就可以載入新的設定

Coupling applications with Kubernetes features/services for no reason
作者認為除了很明確專門針對 Kubernetes 使用，或是用來控制 Kubernetes 的應用程式外，大部分的 應用程式包裝成 Container 時就不應該假設只能運行在 Kubernetes 內。作者列舉了幾個常見的使用範例，譬如

1. 從 K8s label/annotation 取得資訊
2. 查詢當前 Pod 運行的資訊
3. 呼叫其他 Kubernetes 服務(舉例，假設環境已經存在 Vault，因此直接呼叫 vault API 來取得資訊)

作者認為這類型的綁定都會使得該應用程式無法於沒有 Kubernetes 的環境運行，譬如就沒有辦法使用 Docker-compose 來進行本地開發與測試，這樣就沒有辦法滿足 12-factor 中的精神。
對於大部分的應用程式測試，除非其中有任何依賴性的服務是跟外部 Kubernetes 綁定，否則這些測試應該都要可以用 docker-compose 來叫起整個服務進行測試與處理。
服務需要使用的資訊應該是運行期間透過設定檔案，環境變數等塞入到 Container 內，這樣也呼應上述的不要將與環境有關的任何資訊都放入 image 內。

Mixing application deployment with infrastructure deployment (e.g. having
Terraform deploying apps with the Helm provider)
作者認為近年來伴隨者 IaC 概念的熱門，愈來愈多的團隊透過 Terraform/Pulumi 這類型的工具來部署架構，作者認為將部署架構與部署應用程式放到相同一個 Pipeline 則是一個非常不好的做法。

將基礎架構與應用程式同時放在相同 pipeline 可以降低彼此傳遞資訊的困難性，能夠一次部署就搞定全部，然而這種架構帶來的壞處有
1. 通常應用程式改動的頻率是遠大於基礎架構的改變，因此兩者綁在一起會浪費許多時間在架構上
假如部署基礎架構需要 25 分鐘而應用

https://codefresh.io/kubernete.../kubernetes-antipatterns-1/

本篇文章探討的也是資安系列問題，而這次的目標主角則是 MAC 系統上廣為流傳的 Homebrew 系統。

結論:
作者透過觀察 Homebrew 的 Github Action 流程，成功得上傳一個會列印一行的程式碼到 iterm2 套件中，讓所有安裝的使用者都會於 Terminal 上看到一行作者客製化的訊息。

本次的漏洞是作者刻意從 Homebrew 的 Vulnerability Disclosure Program 專案中去嘗試尋找可能的問題，所有的操作都有跟官方專案的人探討過流程，並且一切的 PoC 都是單純證明該攻擊的可行性，所以有興趣研究的人請遵循一樣的想法去做，不要認真的想攻擊。

原因:
1. Homebrew 透過 Github Action 執行 CI/CD 動作
2. Homebrew 撰寫了一個自動合併 Pull Request 的 Action
3. CI 內會透過一個Ruby的 Git Diff 第三方函式庫來驗證，只要符合下列條件就可以自動合併
- Modifying only 1 file
- Not moving/creating/deleting file
- Target filepath matches \ACasks/[^/]+\.rb\Z
- Line count of deletions/additions are same
- All deletions/additions matches /\A[+-]\s*version "([^"]+)"\Z/ or - -\A[+-]\s*sha256 "[0-9a-f]{64}"\Z
- No changes to format of versions (e.g. 1.2.3 => 2.3.4)

作者一開始想要從該規則下手，找尋有沒有可能塞入惡意攻擊並且騙過系統讓其自動合併，然而這些規則看起來沒有什麼太多問題，於是作者轉往其他領域去找尋問題，其中一個想法就是到底該 Ruby 的 Git Diff 是如何實作，也許從實作下手更有辦法去欺騙這一切。

很順利的是，作者真的於該函式庫中找到問題，對於一個 Git Diff 的結果來說，該函式庫會透過 +++ "?b/(.*) 這樣的正規表達式來判別檔案路徑的資訊而並非程式修改內容，譬如下列 diff
```
diff --git a/source file path b/destination file path
index parent commit hash..current commit hash filemode
--- a/source file path
+++ b/destination file path
@@ line information @@
Details of changes (e.g.: `+asdf`,`-zxcv`)
```

作者就開始思考，如果讓程式碼可以符合 +++ "?b/(.*) 的規則，是否有辦法讓程式碼不被視為一個檔案的修改，因此就可以修改多行程式碼但是讓 CI 系統認為只有一行程式碼於是進行自動合併

作者最初的想法如下，第一行用來放惡意程式碼，第二行用來偽裝檔案路徑，經過一番嘗試後作者真的成功塞入了類似 PRINTF 的程式碼到環境中並觸發自動合併。接者各地使用者透過 brew 安裝 iterm 版本都會看到使用者塞入的程式碼。
```
++ "b/#{Arbitrary codes here}"
++ b/Casks/cask.rb
```

原文還有更多作者的思路過程，有興趣的不要錯過

原文:
https://blog.ryotak.me/post/homebrew-security-incident-en/#fn:7
測試用PR:
https://github.com/Homebrew/homebrew-cask/pull/104191

零基資安訓練營（十）：簡易製作加密虛擬碟中碟

文：薯伯伯

電腦加密有不同的層次，其中一種必須做，是要把整個硬盤也加密，方法很容易，Mac 用戶只需要打開系統的 FileVault 便可，Windows 的用戶則只需打開 BitLocker，就能把整個裝置加密。把系統加密之後，如果沒有開機的密碼，理論上別人即使把硬碟取出來，也難把檔案抽出。當然不是所有人也擔心自己的電腦會被強行拆開並抽出硬碟，但還有其他情況，例如將來變賣電腦，又或是電腦被狗咬，系統加了密，感覺就安心一些。

具體的操作方法很簡單，問問 Google 就可以，這裡就不多說。

👉 搜尋：Mac FileVault 2 啟動磁碟加密
👉 搜尋：Windows BitLocker 開啟裝置加密

這篇文章主要想普及的一種資安保障，是在電腦中製作另一些「虛擬加密磁碟檔案」（virtual encrypted disk）。簡單來說，就是電腦上生成一個檔案，載入並輸入密碼之後，就會成為一個新的磁盤，像個「碟中碟」。

先說為甚麼電腦本身已經用 FileVault 或 BitLocker 加密了，何以仍然要再在裡面設置一個「虛擬加密磁碟檔案」，因為當你開機輸入密碼之後，電腦中的檔案便會即時解密，若然在操作過程中電腦受到攻擊，就會有很大風險。

另一個要考慮的情況，是現在有不少人把原生的檔案同步至 Google Drive 或 口程 Dropbox 作備份，用起來雖然方便，但這些服務便能讀取你的檔案內容。而如果你的 Google Drive 是由院校或公司提供（即 Google for Education 或 Google Enterprise），管理員雖然看不到檔案內容，但卻可以看到檔案名字，這是另一層的隱患。所以，除了裝置要加密，還需要加裝一個碟中碟，方為上策。

虛擬碟中碟，我推介用 VeraCrypt。

官方地址：https://www.veracrypt.fr/en/Downloads.html
免費，開源，跨三大電腦平台，在資安界裡評價一直很好
留意：一定要從官方網站下載，不要從第三方網站下載

這裡示範如何做一個 10GB 大小的虛擬加密碟中碟。

安裝 Veracrypt 後，在主畫面點擊 Create Volume，出現 Creation Wizard，跟著一步一步去做。

選擇 Create an encrypted file container，按 Next。
選擇 Standard VeraCrypt volume，按 Next。
選擇 Volume Location，點擊 Select File，點擊桌面位置，在 Save As 一欄輸入名字，這裡舉例叫做 10gb。之後選擇 Never save history，按 Next。
在 Encryption Algorithm 選擇 AES，下方的 Hash Algorithm 選 SHA-512，按 Next。
Volume Size 選擇 10 GB，按 Next。（小一點也可以，看自己需要。）
Volume Password，輸入密碼。下方的設定，全都不選，按 Next。
之後如果顯示 Large Files 一欄，選擇「I will store files larger than 4GB on the volume」，按 Next。
Format Options 選擇 Filesystem type: MacOS Extended 或 NTFS，按 Next。
Cross-Platform Support 選擇 I will mount the volume only on Mac OS X，按 Next。
之後在 Volume Format，不停無意地移動鼠標，軟件會蒐集隨機的訊息。建議不要只管打圈，也可以用鼠標寫寫詩，蒐集到的隨機數據越多越好。
之後按 FORMAT，等一會，檔案就會生成，按 Exit 就可以。

這時在桌面就會看到一個 10gb 的檔案，把檔案拖至 VeraCrypt 的主畫面，按 Mount，輸入密碼，這時就會在 Finder 或檔案總管，就會看到好像插入了一個 USB 手指一樣。把需要加密的檔案放進這個加密虛擬碟中碟。用完之後，在 VeraCrypt 上按 Dismount All 便會自動退出。

VeraCrypt 還有很多有趣的功能，例如有個 Hidden VeraCrypt volume，可以製作同一個檔案，但輸入不同密碼，卻會看到不同檔案。例如有人節磨你，要求你打開檔案，你不情不願，輸入密碼後，裡面只有愛情動作片。但實際上當你輸入另一組密碼時，卻會有個驚世大陰謀！是不是有點電影橋段的感覺了？
把電腦檔案加密存儲，可以有千百萬個不同的原因及動機，但要記住，做事光明磊落的人，做實事的人，是更應保護好檔案免受侵擾。檔案加把檔，是保障資訊安全的重要的一步，必須學習。

照片：Markus Winkler via Unsplash

▶️ Patreon: www.patreon.com/pazu