讓你寫出更安全的 Dockerfile

自從進入大容器時代後，Docker、K8s 已經逐漸成為開發、測試及部署時不可或缺的工具，如果突然叫我不要用 Docker，那我可能什麼都做不了，但也因為這樣，跟容器有關的攻擊越來越普遍，因此容器的安全性也越來越重要

而想要從零開始建出一個容器，第一步就是要寫 Dockerfile 把你的應用包裝成 Docker image。關於怎麼產生出盡量小的 image 已經很多人寫過了，所以今天想要跟大家分享的是想要寫出一個安全的 Dockerfile，有哪些該注意的地方。

使用 stable 或 LTS 的 base image

很多人在寫 Dockerfile 並不會特別指定 base image 的版本（就懶啊，我懂 XD），譬如說想要包一個 Node API server，就直接寫 FROM node 或是 FROM node:latest

# Bad
FROM node

WORKDIR /app
COPY . .

RUN npm install
RUN npm run test

bad.Dockerfile hosted with ❤ by GitHub

但這樣可能會在哪次 build image 時就意外從 Node 14 升到 Node 16，導致部分功能直接壞掉。而且最新版本的 Node 可能有一些不為人知的 bug，需要有一些勇者去幫忙踩坑，所以除非是自己的 Side Project 想要玩玩看最新的 feature，否則直接把最新版本的 Node 用在 production 並不是個好作法

比較好的方式是先看看 Node 的 LTS（Long-Term Support） 版本是多少，像我在寫文章的當下是 v14.17.5，那就選擇 node:14 或是 node:14.17 作為 base image。

# Good
FROM node:14

WORKDIR /app
COPY . .

RUN npm install
RUN npm run test

這樣做一來是可以把版號固定在 Node 14、確保不會有大變動，二來是 LTS 的版本都會不斷推出 security fix，因此如果哪天 Node 更新到 v14.17.10，那些 security fix 也會在部署時被加進的 API server，我們只要坐等更新就好了

安裝套件時要指定版本

這點跟上面提到的不要用 latest image 有些類似，不管你是用 apt-get install 安裝 CLI 工具、用 npm install 裝函式庫、還是用 curl/wget 把東西下載回來編譯，都要盡量確保每次下載到的東西是一樣的

譬如在用 apt-get 安裝 nginx 時就可以透過 apt-get install nginx=1.14.0 來下載指定版本（有點麻煩對吧，我也覺得XD），而 npm、pip 這類的語言套件管理工具則是看官方推薦什麼方法，像 npm 就是用 package-lock.json 來鎖定套件的版本、pip 的話則是先跑 pip freeze > requirements.txt 把套件的版本凍起來，等要安裝時再跑 pip install -r requirements.txt 把原本的套件裝回來。

# Good
FROM ubuntu:20.04

RUN apt-get update
RUN apt-get install nginx=1.14.0 python=2.7.15 nodejs=12.18.2

雖然把套件版本的鎖定之後可以省下很多麻煩，但也不能一直鎖在那都不更新，所以記得偶爾去檢查一下版本是不是太舊了，如果太舊再手動把版號升上去就好了～

只 COPY 需要的東西

平常在寫 Dockerfile 時，有些人為了一時方便，會直接用 COPY . /app 把整個專案資料夾複製到 container 的 /app 資料夾內。這樣不用動太多腦筋，在 container 裡面也可以直接存取到所有檔案，但這樣的做法可以說是糟透了。

FROM node:14
WORKDIR /app

# Very BAD
COPY . .

RUN npm install
RUN npm run test
CMD ["node", "index.js"]

首先是這樣會讓 image 變得很肥（連 node_modules 都進去了能不肥嗎XD），而且一不小心就會把 .envrc 這類敏感資料一起放進去，如果哪天這個 image 被駭客拿到，裡面的 AWS 憑證、資料庫密碼等等超機密資料就會直接外洩出去，哪天突然被刪庫也是有可能的

為了避免這種事情發生，在 build image 時應該只把需要的東西複製進去，譬如說你馬上就要跑 npm install，這才把 package.json 跟 package-lock.json 放進去，而程式碼也是把真的會跑到的那些放進去就好。

FROM node:14
WORKDIR /app

# Good
COPY package.json package-lock.json ./
RUN npm install

# Good
COPY src/ index.js ./
RUN npm run test
CMD ["node", "index.js"]

而且這樣還有另外一個好處，就是如果你改了 src 裡面的程式碼，但沒有安裝新的 package（開發時大部分都是這樣吧～），因為 Docker 會自動做 cache，所以就不需要重新跑一次 npm install，會直接從第 10 行的 npm run test 開始跑，因此可以大幅縮減需要等待的時間

用 multi-stage build 捨棄不需要的檔案

這跟上一點有點類似，簡單來說就是不要留任何不需要的東西在 image 裡面（沒用的東西都給我滾），即便那是 build image 過程中產生的東西也是一樣

譬如說原本 Go API server 的 Dockerfile 可能長這樣，因為要在 build image 時編譯出執行檔，所以第 5 行的 COPY *.go 是一定要的，沒有他們就無法進行編譯。

FROM golang:1.17

WORKDIR /app

COPY *.go go.mod go.sum ./
RUN go build -o main

CMD ["./main"]

但說真的一旦編譯出執行檔之後，那些 Go 程式碼就用不到了，所以應該來個爽快的過河拆橋，用 multi-stage build 把編譯完的執行檔保留下來就好，程式碼什麼的就直接拜拜

像下面這個這個 Dockerfile 經過 multi-stage build 後 image 裡面就只有 /app/main 這個編譯好的執行檔，沒有任何程式碼以及 Go 的編譯器，非常的存粹。

# compile stage
FROM golang:1.17 as compile-env
WORKDIR /app
COPY *.go go.mod go.sum ./
RUN go build -o main

# final stage
FROM gcr.io/distroless/base
COPY --from=compile-env /app/main /app
CMD ["/app/main"]

那這樣有什麼好處呢？除了 image 可以變小很多之外，即便 image 被駭客拿到了，程式碼也不會外流出去（有很多攻擊都是拿到程式碼後從裡面找到漏洞），因此只保留執行檔可以提高安全性

除此之外，因為環境越複雜就越可能有沒發現的漏洞，而把 base image 從原本的 golang:1.17 換成 Google 提供的 distroless image 剛好可以大幅減少環境的複雜度（distroless 幾乎沒裝什麼東西，連 shell 都沒有），也就可以提高安全性

不要把敏感資料 hardcode 在 Dockerfile 裡面

我想這已經是常識等級的安全知識了，因為直接把敏感資料用 ENV 寫在 Dockerfile 裡會讓駭客輕易拿到（只要拿到 image 就可以了），所以絕對不要想不開把資料庫或任何的帳號密碼寫在裡面，ENV 頂多用來設定時區或是 NODE_ENV 這種被看光也不會出事的變數就好，不然哪天資料被偷走真的會哭出來。

FROM node:14

ENV TZ=Asia/Taipei
ENV NODE_ENV=production

# Very Bad
ENV PG_HOST=test.postgresql.com
ENV PG_USER=thisIsmyUserName
ENV PG_PASS=mySecretPa55w0rd
ENV PG_DBNAME=projectName

COPY . .
RUN npm install
CMD ["node", "index.js"]

如果說 ENV 不能放敏感資料，那這些資料究竟要怎麼被加進環境變數呢？

答案就是在 docker run 時加上 --env 或是 --env-file 把環境變數塞進去；如果是用 docker-compose 的話，則是把那些資料寫進 docker-compose.yml 的 environment 裡面，這樣 container 啟動時就會讀到這些變數，而且即便 image 被偷走也不用擔心資料外洩

弱點掃描

可以做的事情都做了之後，最後就是要來用工具來做弱點掃描了。因為做弱描的工具還滿多的，這邊就介紹已經被 Docker 加進 CLI 的 Snyk，他可以把你的環境、安裝的套件丟到他們資料庫去做搜尋，看有哪些潛在的危險

譬如說我手邊有幾個多年前用 Node.js 寫的 express server，Dockerfile 長這樣（看到 9.2.0 就知道真的是多年前XD，現在都已經 Node 16 了）。

FROM node:9.2.0

COPY index.js package.json /app/
WORKDIR /app
RUN npm install && npm cache clean --force

CMD node index.js

先用 docker build . -t app 把 image 建出來後，接著就下 docker scan app 對他做掃描。因為我用的是古早古早以前的 node:9.2.0，所以光 Base Image 的部分掃出來就有 1039 個漏洞，而且其中 99 是屬於 critical 等級的，嚇都嚇死

除了告訴你有多少漏洞之外，他還會把每個漏洞給列出來（有興趣可以去讀一下那些漏洞的報告，其實都不長），並且告訴你那些漏洞分別在哪些版本修掉了

如果懶得看那些漏洞的話，也可以直接滑到最底下看他給你的建議，譬如這邊他就建議把 base image 升級到 node:16.7.0，若是不一定要 full image 的話，那 node:16-bullseye-slim 也是不錯的選項，因為安裝的東西更少，所以漏洞自然也更少。

總結

今天介紹了一些在寫 Dockerfile 時的注意事項，雖然很多都是小地方，但畢竟魔鬼藏在細節裡，想要讓你的 Docker image 更安全，那就連這些小細節都不能放過。