系統設計面試：如何把 Kubernetes Pod 遷移到 user namespaces？

題幹與適用場景

Kubernetes 叢集有一批歷史映像仍以容器內 UID 0 運行。安全團隊希望利用 user namespaces 降低容器逃逸對主機的影響，但業務擔心磁碟區權限、hostPath、監控代理、特權能力與舊節點相容。請設計遷移、驗證、灰度、觀測與回滾方案。

這是一道 system-design 題。重點是把隔離能力落到身份映射、儲存、調度、安全策略與運維流程，而不是只寫 hostUsers: false。

面試官在考察什麼

• 能否解釋容器內 root 與主機 UID 的區別，以及 capabilities 的作用域。
• 能否識別磁碟區、host namespace、CRI/OCI runtime 與 Pod Security 的邊界。
• 能否設計不影響現有工作負載的相容性檢查與分批遷移。
• 能否定義安全收益、效能成本、SLO、指標與回滾條件。
• 能否處理 rootless 遷移後應用、除錯、監控與備份的反例。

Kubernetes 官方文件將 user namespaces 標為 v1.36 stable、預設啟用，Pod 透過 spec.hostUsers: false opt-in。Amazon SDE II 資料把系統設計的可靠性、效率、最佳化與擴展性作為評估維度；本題還要求把安全收益與運維風險同時量化。

回答前需要澄清的問題

1. 叢集是否 Linux-only，kubelet、CRI、OCI runtime 與核心版本是否符合要求？
2. 工作負載是否使用 hostNetwork、hostPID、hostIPC、hostPath、裝置、特權容器或需要主機 UID 的監控代理？
3. 哪些磁碟區需要跨 Pod 共用？磁碟區內既有檔案的 UID/GID 是否落在可映射範圍？
4. 應用是否真的依賴「主機 root」，還是只需要容器內 root 的檔案與能力？
5. 遷移目標是降低逃逸影響、符合 Pod Security，還是允許容器內管理網路等特定能力？
6. 能否按 namespace、節點池或 workload 灰度，並保留 hostUsers=true 模板回滾？

30 秒回答框架

先做資格矩陣：Linux、核心、CRI/OCI runtime、host namespace、磁碟區與特權能力逐項檢查。對符合條件的 Pod 設定 hostUsers: false，驗證容器內 UID 仍按應用語義運作，但主機看到的是映射後的非特權 UID。重點測試檔案權限、監控、網路與除錯，再按 workload 灰度，監控啟動延遲、權限錯誤、OOM、逃逸防護與業務 SLO，異常時切回舊模板。

分步深入解答

1. 解釋隔離模型

user namespace 把容器內使用者映射到主機的不同 UID/GID。容器內的 root 仍可執行容器內需要的操作，但其 capabilities 只在該 user namespace 有效，不能直接取得主機 root 權限。Kubernetes 透過 hostUsers: false 為 Pod opt-in，並為同一節點上的 Pod 分配不衝突的主機映射。

這改變的是核心身份邊界，不等於完整沙箱。仍需 seccomp、AppArmor/SELinux、網路策略、唯讀檔案系統、最小權限與節點修補；不能把 user namespaces 當成解決所有容器逃逸的單一控制。

2. 做執行環境與節點資格檢查

先確認所有目標節點的 kubelet、CRI 與 OCI runtime 支援 user namespaces。官方資料列出 containerd 2.0、CRI-O 1.25、runc 1.2 或 crun 1.9 等支援要求；實際部署還要驗證核心、idmapped mount 與發行版設定。

Admission policy 可拒絕不符合標籤的節點或能力組合。CI 產生最終 Pod 物件並檢查 hostUsers、securityContext、host namespace 與 volume 類型；部署前用探針 Pod 驗證建立、掛載、重啟與節點遷移行為。

3. 評估磁碟區與 UID/GID

Pod 內的 runAsUser、runAsGroup 與 fsGroup 仍表示容器內使用者。掛載磁碟區時，檔案看到的權限語義應與未啟用 user namespace 時保持一致，應用通常不需要重寫磁碟區所有權。

但超出可映射 UID/GID 範圍的檔案可能顯示為 overflow ID，且不能正常修改。遷移前掃描磁碟區所有者、init 腳本、共用磁碟區與備份還原工具；發現不相容時先修復映像或資料，再切換 namespace。

4. 處理禁止組合與安全策略

啟用 user namespace 後，Pod 不能同時使用某些 host namespace，例如 hostNetwork、hostPID 或 hostIPC；依賴主機裝置、特權模式或特殊 proc 掛載的工作負載也要單獨評估。Pod Security Standards 對部分欄位會受控放寬，但不代表可以刪除其他策略。

把「必須使用主機 namespace」的 workload 標記為暫不遷移，並記錄例外審批、補償控制與期限。不要為了通過策略檢查而自動清除欄位，避免把功能故障變成隱性安全回退。

5. 設計效能、SLO 與觀測

關注 Pod 啟動延遲、磁碟區掛載延遲、節點 CPU/記憶體、容器內權限錯誤、監控資料遺失、備份還原成功率與重啟次數。idmapped mounts 可以避免大磁碟區遞迴 chown，但仍要用真實核心、runtime 與檔案系統測量，不能只引用理論複雜度。

日誌與指標帶上 userns 遷移版本、節點池、映像與磁碟區類型。安全指標包括被拒絕的逃逸測試、特權操作失敗與 Pod Security 違規；業務指標包括請求錯誤率、延遲與資料完整性。

6. 分批遷移與回滾

先在無狀態、無 host namespace、磁碟區簡單的工作負載上灰度，再擴大到有狀態服務。每批保留 hostUsers: true 舊模板雜湊，設定自動停止條件：權限錯誤、啟動延遲、業務錯誤率、磁碟區讀寫異常或節點驅逐超過門檻立即停止。

回滾時不只是改欄位，還要驗證磁碟區掛載、runAs 使用者、監控代理與 admission 輸出恢復舊形態。遷移期間避免同時升級 runtime、核心與映像，否則無法定位故障來源。

7. 安全收益與殘餘風險

user namespaces 可以降低容器內 root 逃逸後對主機的影響，並為部分需要容器內管理能力的場景提供更窄的權限域。它不能保護應用自身的密鑰洩漏、容器間邏輯攻擊、錯誤網路策略或已被攻破的共用服務。

最終安全評審應列出仍允許的 hostPath、裝置、capability、核心介面與服務帳號，結合 seccomp、SELinux、節點隔離與漏洞修補形成縱深防禦。

高品質示範回答

我會先建立資格矩陣：目標節點必須是 Linux，kubelet、CRI/OCI runtime、核心與檔案系統符合 user namespace 要求；同時篩掉使用 hostNetwork、hostPID、hostIPC、特權裝置或依賴主機 UID 的 Pod。通過檢查的模板設定 hostUsers: false，並確認容器內 UID/GID 符合應用語義，主機看到的是不具備 root 權限的映射。

遷移前掃描磁碟區所有者、init 腳本、共用磁碟區與備份還原，測試 overflow ID 與權限邊界。用探針 Pod 驗證建立、掛載、重啟與節點遷移，灰度時觀察啟動與掛載延遲、權限錯誤、業務 SLO、驅逐、監控與備份指標。保留舊模板雜湊，異常立即切回。

我會把 user namespaces 視為縱深防禦的一層，繼續使用 seccomp、SELinux/AppArmor、網路策略、最小權限與節點修補。安全收益、效能成本與例外 workload 都寫入遷移清單，避免把「設定一個欄位」誤認為完成安全遷移。

常見錯誤

• 只寫 hostUsers: false，不檢查 Linux、runtime、核心與磁碟區條件。
• 說「容器內 root 變成普通使用者」，忽略容器內與主機 UID 的雙重語義。
• 認為 user namespaces 自動解決所有逃逸、特權與網路風險。
• 忽略 hostNetwork、hostPID、hostIPC、hostPath、裝置與 proc mount 限制。
• 遷移前遞迴 chown 所有磁碟區，或不檢查 overflow UID/GID 檔案。
• 同時升級 runtime、核心與映像，導致無法歸因。
• 沒有舊模板、自動停止條件與可驗證的回滾路徑。

追問及應對

user namespaces 在 Kubernetes 哪個版本穩定？

官方文件將其標為 Kubernetes v1.36 stable 且預設啟用；Pod 仍需透過 spec.hostUsers: false opt-in。部署時要核對實際叢集與節點版本。

容器內 root 還能使用 capability 嗎？

可以使用在該 user namespace 內有效的能力，但這些能力不會自動變成主機權限。仍要按最小權限、seccomp 與 LSM 策略限制。

現有 PVC 權限會不會全部失效？

通常容器內 UID/GID 語義保持一致，磁碟區不必因 user namespace 統一重寫所有權；但超出映射範圍的檔案可能成為 overflow ID，需要先掃描並修復。

為什麼 hostNetwork 不能一起用？

user namespace 依賴隔離的使用者與部分資源邊界，某些 host namespace 組合會破壞預期隔離，因此 Kubernetes 禁止這些組合。依賴主機網路的 workload 應保留例外並加入補償控制。

如何證明遷移降低了風險？

用隔離逃逸測試、特權操作測試與節點觀測驗證主機 UID、capability 與存取範圍，同時比較業務錯誤、啟動延遲與磁碟區完整性；不能只看 Pod 建立成功。

哪些工作負載應暫不遷移？

需要 host namespace、特殊裝置、特權核心介面或無法修復磁碟區 UID/GID 的工作負載先保留舊模板，記錄例外原因、補償控制與重新評估日期。