NT 430 特價中

在大型企業開發 Java 應用程式並不容易。每天都被要求使用許多不同的技術。早上，你可能需要將資料保存到 MySQL 資料庫。下午，你可能正在與 RabbitMQ 合作。明天你可能被要求與 Mongo 或 Redis 一起工作。

想想在使用所有這些不同技術時需要做什麼。

如果你將所有這些安裝在筆記本電腦上，則會變得凌亂而緩慢。當然，你可以使用虛擬機運行這些 – 如果你真的想減慢你的筆記本電腦。虛擬機是非常棒的，但虛擬機也可以佔巨大的資源。

如果你在開發團隊中，則可以設置專用的開發伺務器。但是你沒有一個乾淨的開發環境。你的開發工作必須倚賴開發用的伺服器。

Docker是一種令人興奮的技術，讓你可以在企業開發中槓桿。

https://softnshare.com/docker-for-java-developers/

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，都可能造成重要的資料外洩與潛在的資安危機。

本篇文章是個經驗分享文，作者分享使用 Docker 作為開發環境時值得注意的 Best practices，透過這些經驗分享希望能夠讓開發者少走一些冤枉路。

原文提出了 15 個經驗談，這邊幫大家節錄幾個，有興趣的可以點選原文瞭解更多!
1. One thing at a time
2. Be ephemeral
3. Utilize .dockerignore
4. Less is more
5. Secrets should be secret
6. PID 1 is your birth right
7. Share and Care
8. Vulnerability Scan
9. Tag like you mean it
10. Permissions are costly
11. Source of Truth
12. Always official
13. Don’t include debug
14. Use entry point script smartly
15. Size does matter

One thing at a time
建置 Image 的時候專注做好一件事情，每個 Image 應該有一個專心要解決的問題，譬如一個應用程式，一個小工具等。對於 Nginx 這類型的 Image 來說，應該沒有人會期望於裡面看到有 Apache 的應用程式吧?

Be ephemeral
這個主要探討的是該 Image 本身建置時應該要以 stateless 的概念去處理，未來不論是透過 docker 或是 Kubernetes 來管理部署時，Contaienr 都很有機會被重啟，每次的重啟都意味該容器是重新啟動。所以千萬不要讓你的 Image 變成多次重啟會導致應用程式出問題的形式，任何的這類型資料應該都要透過外部取得，不要塞到你的 Image 內

Utilize .dockerignore
善用 .dockerignore 這個檔案來將不必要的檔案從 build 過程給排除，使用方法與 .gitignore 類似。透過這個檔案的設定可以避免 docker build 的時候不會把一些過大或是完全不需要的檔案都送給 docker daemon，不當浪費時間也浪費空間。

Less is more
避免安裝任何無關或是非必要的套件到你的 image 中，特別是那些 "nice to have" 的理由。

註: 我個人是滿討厭把 Image 弄得很乾淨的，除錯什麼工具都沒有，連 ash/sh/busybox/bash 都沒有的 image 更是我討厭中的排行榜冠軍

Secrets should be secret
任何機密資訊都應該要於運行期間動態載入，而不是建置期間塞入。請使用其他工具譬如 Vault 來管理這些機密資訊，並且執行期間讓 Container 能夠存取到正確的值。

PID 1 is your birth right
Linux 環境下會使用 SIGTERN, SIGKILL 等相關的 Singal 來戳你的應用程式，請確保你運行的應用程式要能夠攔截這些訊號來處理並完成有效的 Graceful shutdown.

Share and Care
如果環境中有多個 Image 彼此有共享相同的工具與功能，與其每個 Image 都單獨建置維護不如建置一個 Base Image，接者讓所有要使用的 image 去載入使用即可。
透過這種方式可以讓整體的維護性與管理性更為簡單，每個 image 可以減少重複的程式碼，同時要升級時只要針對 base Image 處理即可。

https://medium.com/pradpoddar/avoid-costly-mistakes-using-advanced-docker-development-best-practices-acd812784109