容器的真相：它其實只是一個被騙的 Process

先做一個思想實驗（你也可以真的動手做），這個現象會直接摧毀「容器是小虛擬機」的錯覺。

步驟

1. 在你的 Linux 機器上啟動一個容器，裡面跑 nginx：

   docker run -d --name web nginx

2. 進容器裡面看看有哪些 process：

   docker exec web ps -ef
   
   UID   PID  PPID  CMD
   root    1     0  nginx: master process
   nginx  29     1  nginx: worker process

   容器裡只有兩個 process，而且 nginx 是 PID 1。
3. 現在離開容器，在宿主機上找同一個 nginx：

   ps -ef | grep nginx
   
   UID    PID   PPID  CMD
   root  48231  48210  nginx: master process
   nginx 48277  48231  nginx: worker process

你發現了什麼？

如果容器真的是一台虛擬機，你在宿主機上絕對看不到裡面的 process——就像你看不到 VMware 裡那台 Windows 的 process 一樣。但你看得到。

Namespace（命名空間）是 Linux 核心的一個功能，作用只有一句話：讓一個 process 對「系統資源」看到的是一份獨立的清單，而不是全機器那份。

Linux 有幾種 namespace，各自隔離一類東西

• PID namespace（行程編號）：容器內自己編號，第一個 process 就是 PID 1，而且看不到容器外的任何 process。這就是上一張卡的謎底。
  沒有它會怎樣：容器內 ps 會看到宿主機上所有程式，還能 kill 掉別人的服務。
• Mount namespace（檔案系統掛載）：容器有自己的一份掛載表，看到的 / 跟宿主機的 / 完全不同。
  你何時感覺到它：容器裡看不到你 home 目錄的檔案；你要給它檔案必須明講（bind mount，ch06）。
• Network namespace（網路）：每個容器有自己的一整套網路堆疊——自己的網卡、自己的 IP、自己的路由表、自己的一整組 port 號碼（0~65535）。
  這解釋了一個你一定遇過的現象：兩個容器可以「同時」都用 8080，完全不衝突——因為那是兩組不同的 8080。但你要從宿主機連進去就得做 port mapping（ch07）。
• UTS namespace（主機名稱）：容器可以有自己的 hostname。
  你何時感覺到它：進容器後提示字元變成一串亂碼般的 ID，那就是容器自己的 hostname。
• IPC namespace（行程間通訊）：共享記憶體、訊號量這類機制彼此隔離，A 容器不能透過共享記憶體偷看 B 容器。
• User namespace（使用者）：可以做到「容器內是 root（uid 0），對應到宿主機上其實是一個沒權限的普通使用者（uid 100000）」。
  這是重要的安全機制，但 Docker 預設沒有開啟——也就是說預設情況下，容器內的 root 就是宿主機的 root。ch10 會談這件事的嚴重性。
• Cgroup namespace（隔離資源限制的視角）：讓容器內看到的資源限制資訊也是自己那份。

怎麼做到的？

其實非常樸素——就是 Linux 建立新 process 的系統呼叫 clone() 多帶幾個旗標：

clone(..., CLONE_NEWPID | CLONE_NEWNET | CLONE_NEWNS | CLONE_NEWUTS | ...)

Namespace 解決了「看到什麼」，但沒解決「用多少」。一個沒有限制的容器，可以把整台機器的 CPU 和記憶體吃光，害死所有鄰居——這叫做吵鬧的鄰居（noisy neighbor）問題。

Cgroups（Control Groups，控制群組）就是核心的計量與收費員：把一組 process 圈起來，統計並限制它們用掉的資源。

能管什麼

• 記憶體：最多用 512 MB，超過就殺掉。
• CPU：最多用 1.5 顆核心的算力；或是在搶奪時給予相對權重。
• 磁碟 I/O：讀寫頻寬上限。
• 行程數量：最多能開幾個 process（防 fork bomb）。
• 裝置存取：能不能存取某個硬體裝置。

你早就在用它了（只是不知道）

docker run -m 512m --cpus 1.5 my-app

或是在 compose 裡：

services:
  app:
    image: my-app
    deploy:
      resources:
        limits:
          memory: 512M
          cpus: '1.5'

經典現場：Exit Code 137 是什麼意思？

容器莫名其妙死掉，docker ps -a 顯示 Exited (137)——這是最常見的容器死因之一：

• 137 = 128 + 9，代表這個 process 被 signal 9（SIGKILL）殺死。
• 誰殺的？核心的 OOM Killer：容器用的記憶體超過 cgroup 上限，核心直接把它砍了。
• docker inspect <容器> 會看到 OOMKilled: true。

第三個法術回答這個問題：為什麼容器裡的 /usr/bin、/etc 跟宿主機的完全不一樣？

從老祖宗 chroot 說起

Unix 很早就有一個指令叫 chroot（change root）：把某個 process 眼中的「根目錄 /」換成某個子目錄。

• 假設宿主機上有個目錄 /var/lib/docker/.../merged/，裡面已經放好了 Ubuntu 的完整使用者空間檔案（/bin、/etc、/usr、/lib…）。
• 對某個 process 執行 chroot 到那個目錄後，它眼中的 / 就是那個目錄。它去讀 /etc/os-release，讀到的是那個目錄下的檔案，於是它「相信」自己在一台 Ubuntu 上。
• 它也爬不出去——對它來說 / 已經是世界的盡頭，沒有「上一層」了。

ch01 那個謎題的完整答案

「容器裡 cat /etc/os-release 顯示 Ubuntu」的真相就是這個：那只是換過根目錄之後讀到的一個文字檔而已。映像檔（image）解壓出來的內容，就是這一整套目錄結構。沒有第二個作業系統在跑，只有一份不同的檔案。

現代容器用的是 pivot_root，不是 chroot

• chroot 有已知的逃脫技巧（例如某些情況下可以透過檔案描述符爬出去），它當初的設計目的是方便，不是安全。
• 現代容器執行環境（runc）用 pivot_root：把整個根掛載點換掉，並把舊的根卸載（unmount）——舊的根不只是看不到，是從掛載表裡整個消失，配合 mount namespace 一起用，隔離更徹底。

把三個法術串起來，完整重演 docker run nginx 的內部流程（略過細節，抓主幹）：

1. 準備檔案系統：把 nginx 映像的各層疊起來，組成一個完整的目錄樹，再蓋上一層可寫層（ch03 詳解），得到一個像 /var/lib/docker/overlay2/xxx/merged 的目錄。
2. 建立 process 並開新 namespace：呼叫 clone()，帶上 CLONE_NEWPID | CLONE_NEWNET | CLONE_NEWNS | CLONE_NEWUTS | CLONE_NEWIPC——這個新 process 一出生就活在自己的世界裡。
3. 設定 cgroup：把這個 process 放進一個新的 cgroup，寫入記憶體上限、CPU 配額。
4. 設定網路：建立一對虛擬網卡（veth pair），一端放進容器的 network namespace 當作它的 eth0，另一端接到宿主機的網橋 docker0 上（ch07 詳解）。
5. 換根目錄：pivot_root 到第 1 步準備好的目錄，卸載舊的根。
6. 丟掉多餘權限：裁掉不需要的 Linux capabilities（例如不讓它改系統時間、不讓它載入核心模組）。
7. 執行你的程式：execve("/docker-entrypoint.sh")——這一步之後，這個 process 就變成了 nginx 本身。它睜開眼睛，看到的是一個叫做「容器」的世界。

理解了原理，就能自己推導出安全性的邊界，不用死背規則。

推導一：容器和宿主機共用核心 ⇒ 核心漏洞可以打穿隔離

• VM 之間隔了一層 hypervisor，要從一台 VM 打到另一台，得先打穿 hypervisor——難度很高。
• 容器之間只隔了 namespace 這層「視野遮罩」，底下是同一個核心。一旦核心本身有提權漏洞，惡意程式就可能從容器內取得核心權限，進而跳出容器控制整台機器。這就是容器逃逸（container escape）。

推導二：預設沒開 user namespace ⇒ 容器內的 root 就是宿主機的 root

• 如果你的容器以 root 執行（而這正是很多映像的預設），那個 uid 0 跟宿主機的 uid 0 是同一個。
• 一旦攻擊者從你的應用漏洞取得容器內 shell，他就是以 root 身分站在你的核心前面——距離接管整台機器只差一個核心漏洞。
• 對策（ch10 詳談）：Dockerfile 裡明確 USER appuser，用非 root 身分跑你的應用。

推導三：--privileged 等於把所有法術通通解除

• docker run --privileged 會給予容器幾乎全部的 capabilities、放開裝置存取。
• 此時容器基本上等於直接在宿主機上跑的 root 程式，隔離形同虛設。
• 網路上很多教學為了「解決權限問題」叫你加 --privileged——那是把門拆掉來解決鑰匙插不進去的問題。