映像瘦身與安全強化：從能跑到能上線

「映像小」聽起來只是省磁碟，其實影響面大得多：

1. 部署更快：擴容或滾動更新時，每個節點都要拉映像。1 GB 對 200 MB，在需要同時啟動 20 個實例時是分鐘級的差距。對 Auto Scaling（AWS ch03）這種「尖峰來了要立刻長出機器」的場景尤其關鍵。
2. 攻擊面更小：這才是重點。映像裡每個套件都可能有 CVE。一個 ubuntu 基底裝了幾百個套件，其中大部分你的 Java 應用根本用不到——但攻擊者用得到。
3. 入侵後的破壞受限：如果映像裡沒有 curl、wget、bash、apt，攻擊者拿到執行權限後連下載後續工具都做不到。這叫做降低「入侵後可用性」。
4. 成本更低：registry 儲存費、跨區傳輸費，在規模化後不是小數字。

先量出來：你的映像大在哪？

docker images myapp:1.0                  # 總大小
docker history myapp:1.0                 # 每一層多大、由哪個指令產生

# 最好用的工具：dive（互動式逐層瀏覽）
docker run --rm -it -v /var/run/docker.sock:/var/run/docker.sock \
  wagoodman/dive myapp:1.0

dive 會告訴你每一層加了哪些檔案、以及一個「浪費空間」的評分（例如某層新增的檔案在後面的層被刪掉了——ch03 說過那些檔案還在）。優化前先量測，不要憑感覺。

基底決定映像 80% 的大小與漏洞數量。但對 Java 來說，最直覺的選擇不一定對。

四個層級的選擇

• ① 完整發行版（ubuntu、debian）：約 70~120 MB，含完整的套件管理與工具。方便除錯，但攻擊面最大。
• ② 精簡發行版（-slim、eclipse-temurin:17-jre-jammy）：拿掉文件、locale 等非必要內容。Java 的合理預設。
• ③ Alpine（alpine、eclipse-temurin:17-jre-alpine）：只有 5~8 MB 的極簡發行版。但對 Java 有坑，見下。
• ④ Distroless（gcr.io/distroless/java17-debian12）：只有執行時期需要的東西——沒有 shell、沒有套件管理員、沒有任何指令工具。安全性最高。

Distroless：安全性的最佳解

FROM gcr.io/distroless/java17-debian12
COPY --from=builder /build/target/app.jar /app.jar
USER nonroot                       # distroless 內建 nonroot 使用者
ENTRYPOINT ["java", "-jar", "/app.jar"]

• 優點：沒有 shell 就沒有 shell 注入、沒有套件管理員就無法安裝惡意工具、CVE 數量極少。
• 代價：docker exec -it ... bash 完全用不了（裡面沒有 bash）。除錯得靠日誌、metrics，或用 docker debug／掛一個工具容器進同一個 namespace。
• 建議：正式環境用 distroless，開發環境用 -jre-jammy（有 shell 好除錯）。同一份 Dockerfile 用不同的最終階段就能切換。

JRE 裡包含了整個 Java 標準函式庫，但一個典型的 Spring Boot 應用只用得到其中一部分。jlink（JDK 9 起內建）可以裁出一個只含必要模組的自訂 runtime。

# ===== 階段 1：編譯 =====
FROM maven:3.9-eclipse-temurin-17 AS builder
WORKDIR /build
COPY pom.xml .
RUN --mount=type=cache,target=/root/.m2 mvn dependency:go-offline -B
COPY src ./src
RUN --mount=type=cache,target=/root/.m2 mvn clean package -DskipTests -B

# ===== 階段 2：用 jlink 裁一個最小 runtime =====
FROM eclipse-temurin:17-jdk-jammy AS jre-builder
RUN $JAVA_HOME/bin/jlink \
      --add-modules java.base,java.logging,java.naming,java.sql,java.desktop,java.management,java.instrument,java.security.jgss,jdk.unsupported \
      --strip-debug --no-man-pages --no-header-files --compress=2 \
      --output /custom-jre

# ===== 階段 3：最終映像 =====
FROM debian:12-slim
ENV JAVA_HOME=/opt/jre
ENV PATH="$JAVA_HOME/bin:$PATH"
COPY --from=jre-builder /custom-jre $JAVA_HOME

RUN groupadd -r spring && useradd -r -g spring spring
COPY --from=builder --chown=spring:spring /build/target/*.jar /app/app.jar
USER spring
ENTRYPOINT ["java", "-XX:MaxRAMPercentage=75.0", "-jar", "/app/app.jar"]

• 成果：自訂 runtime 約 50~70 MB（完整 JRE 約 190 MB），最終映像可以壓到 120 MB 上下。
• 怎麼知道要加哪些模組？用 jdeps 分析你的 jar：

  jdeps --print-module-deps --ignore-missing-deps target/app.jar

ch02 講過：Docker 預設不啟用 user namespace，所以容器內的 root 就是宿主機的 root。如果你的應用以 root 執行又被入侵，攻擊者等於站在你的核心前面。

Debian／Ubuntu 基底的寫法

RUN groupadd -r spring && useradd -r -g spring -s /sbin/nologin spring
COPY --from=builder --chown=spring:spring /build/target/*.jar /app/app.jar
USER spring

• -r：建立系統帳號（不需要家目錄、不能登入）。
• --chown 很重要：檔案複製進去時就設好擁有者，避免非 root 使用者讀不到自己的 jar。
• USER 之後的所有指令與容器主程式都用這個身分執行。

兩個常見的卡關點

• 無法綁定 1024 以下的埠：Linux 規定只有 root 能監聽特權埠。解法：讓應用監聽 8080，靠 -p 80:8080 對外映射。反正 port mapping 本來就在做轉接（ch07），毫無損失。
• 寫入權限不足：應用要寫暫存檔卻噴 Permission denied。解法：明確建立目錄並設好擁有者，或用 tmpfs 掛一個可寫的 /tmp。

執行時的最小權限強化（可以疊加）

docker run \
  --read-only \                       # 整個檔案系統唯讀
  --tmpfs /tmp:size=64m \             # 只開放必要的可寫路徑
  --cap-drop=ALL \                    # 丟掉所有 Linux capabilities
  --security-opt=no-new-privileges \  # 禁止提權（擋 setuid 攻擊）
  -m 512m --cpus 1.0 \                # 資源上限（ch02 cgroup）
  myapp:1.0

• --cap-drop=ALL：capabilities 是把 root 權限切成細項（改系統時間、載入核心模組、綁特權埠…）。一般應用一個都不需要。真的需要某一項再用 --cap-add 單獨加回來——絕不要用 --privileged 一次全開（ch02）。
• --read-only：攻擊者即使進來也無法植入檔案、修改程式。
• 這些設定在 K8s 裡對應 securityContext（runAsNonRoot、readOnlyRootFilesystem、capabilities.drop），觀念完全相同（ch14）。

ch03 證明過：寫進映像的秘密刪不掉，只是被遮住。這裡把正確與錯誤的做法一次列清楚。

❌ 四種錯誤（每一種都真實發生過）

1. Dockerfile 的 ENV DB_PASSWORD=xxx：永久寫進映像設定，docker inspect 或 docker history 直接看到。
2. COPY .env /app/ 或 COPY . . 沒排除 .env：秘密進到映像層。後面再 RUN rm 也救不回來。
3. --build-arg PASSWORD=xxx：會留在建置歷史裡，docker history 看得到。
4. 寫死在 docker-compose.yml：這份檔案會進版控，等於 commit 到 Git。

✅ 三種正確

① 執行時用環境變數注入（開發環境的標準做法）

# .env（務必加進 .gitignore！）
MSSQL_SA_PASSWORD=YourStrong!Passw0rd

# docker-compose.yml（進版控的是這份，裡面沒有明碼）
services:
  sqlserver:
    environment:
      MSSQL_SA_PASSWORD: ${MSSQL_SA_PASSWORD}

② 建置階段需要憑證 → BuildKit secret mount

RUN --mount=type=secret,id=maven_settings,target=/root/.m2/settings.xml \
    mvn package -B

docker build --secret id=maven_settings,src=$HOME/.m2/settings.xml .

檔案只在那一個 RUN 執行期間存在，不會留在任何一層。

③ 正式環境 → 專用的秘密管理系統

• 容器平台：Docker Swarm secrets、Kubernetes Secret（掛成檔案或環境變數，ch14）。
• 雲端服務：AWS Secrets Manager／Parameter Store（AWS ch10）、Azure Key Vault、HashiCorp Vault。
• 優勢是可輪替、有存取稽核紀錄、權限可細分——環境變數做不到這些。

① 漏洞掃描（最低限度必做）

docker scout cves myapp:1.0          # Docker 內建
trivy image myapp:1.0                # 業界最常用的開源工具
trivy image --severity HIGH,CRITICAL --exit-code 1 myapp:1.0   # CI 用：有高風險就失敗

• 掃描的是基底映像的系統套件與你的應用依賴（Maven 的 jar 也掃得到）。
• 接進 CI：把 --exit-code 1 當成建置關卡，有 CRITICAL 就不准推上 registry。
• 掃描是持續的事：今天沒漏洞的映像，下週可能因為新公布的 CVE 就有了。正式環境的映像要定期重掃、定期重建。

② 讓基底映像更新變成例行公事

• 矛盾點：ch04 說要「釘死版本」以保證可重現，但釘死了就不會拿到安全修補。
• 解法是把「更新」變成一個明確的、有人負責的動作：用 Dependabot／Renovate 自動偵測基底映像有新版就送 PR，走正常的測試與審查流程合併。可重現性與安全性同時滿足。

③ 簽章與 SBOM（進階，但 SRE 該知道）

• 簽章（cosign / Sigstore）：digest 保證「內容沒被改」，但不能證明「是誰做的」。簽章補上來源證明，部署時可以要求「只允許執行有我們簽章的映像」。
• SBOM（軟體物料清單）：一份「這個映像裡有哪些套件與版本」的清單。

  docker scout sbom myapp:1.0
  syft myapp:1.0 -o spdx-json > sbom.json

  價值在下次爆出重大漏洞時（像 Log4Shell）能在幾分鐘內回答「我們有沒有受影響」，而不是花三天人工盤點。

上線前檢查清單