ref: https://sysdig.com/blog/dockerfile-best-practices/

如果你常用到容器化、微服務架構，這些輕量化的架構當碰到問題時，背後的資安事件調查、報告、修復卻是影響甚鉅。然而，這些影響都可以透過「把安全意識擺在開發階段 (shifting left security)」來降低風險，而這篇文章就會講述 Dockerfile 的最佳實作手段有哪一些。

首先，我們會從幾個大面向來說明各種控制安全風險的細節，像是權限控管、降低攻擊層面、預防機敏資料洩漏，以及在發布 container image 時的注意事項。而你需要特別注意的是，其實 Dockerfile 也只是算是開發階段的一部份，所以這邊能提醒到的內容都屬於部署前（特別是開發階段）的準備。以下共提及 20 個你可以注意的重點，但因為篇幅較長，筆者將選出較重要的幾個來談談。

讓我們從「權限控管」說起：

Rootless container
根據報告結果顯示，有超過 58% 的 image 都是用 root 作為執行服務的使用者，所以在此也會建議透過 USER 參數來設定容器的預設使用者，同時，也可以利用執行環境/架構的設定來避免容器的預設使用者是 root。

Make executables owned by root and not writable
服務的 binary file 應該避免被任何人修改，容器的預設使用者只需要執行服務的權限，而不是擁有權。

至於「減少攻擊面」的部分：

Multistage builds小
在 image 的建立，可以透過 multistage build 來建立很多層 container，例如在第一層安裝編譯所需的套件，而第二層則只需安裝 runtime 所需的套件（如 openssl 等），再複製第一層所編譯出來的執行檔就可以了。其餘的因開發/編譯所安裝的套件皆不需要放在最後的 image，這樣同時也可以把 image 的大小縮小。

Distroless & Truested image
採用最小/最輕量化的 base image 來作為你打造 image 的基礎，同時使用可信任來源的 image，避免不小心在未知的情況引入好幾個潛在的安全威脅。（在原文中，sysdig 也使用了自身開發的工具來檢測 image 是否有安全問題，如果有需要也能參考看看）

而再來關於「機敏資訊」的部分：

Copy
當你在從你的開發環境複製檔案到 image 當中時，需要非常小心，因為你很可能一不小心就把你的密碼、開發環境的 token、API key 等資訊複製進去了。而且不要以為把 container 裡面的檔案刪掉就沒事了，別忘了 container image 是一層一層堆疊起來的，就算刪掉了，還是能在前面的 layer 裡面找到。

但如果還是有需要用到這些機敏資料，也可以考慮使用環境變數（docker run -e 引入），或是 Docker secret、Kubernetes secret 也能夠幫你引入這些參數。如果是設定檔的話，則可以用 mount 的方式來掛載到你的 container 裡面。

總而言之，你的 image 裡面不該有任何機敏資料、設定檔，開發服務時讓服務在 runtime 的時候可以接受來自環境變數的參數才是相對安全的。

其他的部分：

其實文章當中還有提到很多製作 image 的注意事項，像是在 deployment 階段，可能你部署的 latest 與實際的 latest 因時間差而不同。又或是在 image 裡面加上 health check，也才能做到狀況監測。

在容器化服務的時代，開發者不僅需要具備撰寫開發程式的能力，也要對於虛擬化環境有足夠的理解，否則，在對架構不熟的情況就將服務部署上去，或把 image 推送到公開的 registry，都可能造成重要的資料外洩與潛在的資安危機。

本篇文章是個經驗分享系列文，作者探討 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/

今天這篇文章用來介紹 docker 20.10 所帶來的改變，就算 kuberetes 未來不再預設使用 docker 作為其 CRI，但是對於本地開發者來說， docker 還是個短期不太可能淘汰的工具，所以適時的理解最新的一些變化也是不可或缺的一部分

1. Rootless 從過去的實驗性質到全面支援

自從 runc 這個 container runtime 支援 cgroupv2 之後，已經可以透過 rootless 來創造符合 OCI 標準的容器，因此 docker 也可以順便藉由這個過程一併支持 rootless 的環境

2. Logging drivers

過往大家可能比較少會去關注或是修改 docker logging 的輸出方式，比較常見的是直接基於預設的情況去使用，而有部分的解決方案可能會特別修改成 syslog 等不同方式

而 20.10 所做的事情就是強化整體的使用習慣，讓你不管底層是使用何種 logging driver，你都可以透過 docker logs 的方式去閱讀這些資訊

3. OS support
20.10 開始支援 Ubuntu 20.10, Fedora 33 以及 CentOS8

4. CLI improvements

docker CLI 一直持續改進與強化，移除沒用的功能同時也針對一些常見功能加入一些參數，譬如
1. docker push 與 docker pull 的概念一致，預設情況下，如果不給 tag 就會幫忙帶入 latest 進去
2. docker exec 可以透過事先撰寫檔案來一口氣傳入大量的環境變數

https://towardsdatascience.com/whats-new-in-docker-20-10-fd1de1216c0