容器資安的致命盲點：你忽略了什麼？

華經資訊企業股份有限公司 高級工程師/廖一銘

隨著企業數位轉型加速，容器化 (containerization) 已成為現代應用交付的核心基礎。容器不僅提供了敏捷的部署流程與資源使用效率，更因為微服務架構的普及而被廣泛採用。然而，安全性始終是 IT 環境能否穩定與合規運作的關鍵。相較於傳統 VM，容器基於共享的 Linux 核心，安全邊界較薄弱，一旦缺乏嚴謹的安全設計，將面臨從作業系統層級到應用層級的多重威脅。

本文將從威脅模型、Linux 核心安全機制、映像檔漏洞管理，直至實務應用與風險管控，全面剖析容器安全議題，並輔以實際指令與範例，協助讀者快速掌握實務操作方法。

容器安全威脅(Container Security Threats)

在雲原生與容器化技術廣泛應用的今天，容器安全已成為企業資訊安全策略中不可忽視的領域。容器技術本質上是基於 Linux 作業系統提供的命名空間(Namespaces)、控制群組(cgroups)與檔案系統隔離(chroot、OverlayFS)等機制。然而，這些技術並非為全面安全而設計，因此在實務應用中容易引發新的威脅模型。

常見的容器威脅模型包括：

  1. 隔離不足：容器之間或容器與宿主機之間隔離不完全，導致攻擊者可能透過逃逸(Container Escape)取得宿主機權限。
  2. 不安全的預設組態：許多容器以 root 身份執行，或在未限制 capabilities 的情況下運行，導致權限過大。
  3. 映像檔污染：惡意映像檔或第三方套件中可能存在惡意程式或已知漏洞，成為攻擊進入點。
  4. 供應鏈攻擊：從程式碼、映像檔到部署的整個鏈路都有可能被入侵或植入惡意元件。
  5. 弱密碼與憑證管理：容器應用若未搭配安全的密碼與金鑰管理，容易被暴力破解或竊取敏感資訊。

企業在規劃容器環境時，必須以威脅模型為基礎，建立相對應的防禦策略。例如，採用零信任架構 (Zero Trust)、加強網路策略隔離 (如 Kubernetes Network Policy)、以及持續監控與事件回應，才能降低潛在的風險。

Linux System Calls, Permissions, and Capabilities

容器的核心在於 Linux 提供的系統呼叫 (System Calls) 與權限模型。所有應用程式與服務最終都必須透過系統呼叫與核心互動，而核心則透過檔案權限、使用者身份、以及 Linux Capabilities 來進行存取控制。

系統呼叫(System Calls)

容器中應用程式與宿主機核心的互動，都是透過系統呼叫完成的。例如檔案存取 (open、read、write)、網路操作 (socket、bind、connect)、程序管理 (fork、execve) 等。容器安全機制如 seccomp，便是透過過濾允許的系統呼叫，降低攻擊面。

檔案權限與使用者模型

Linux 採用傳統的 UID/GID 與 rwx 權限模式來控管檔案存取。舉例來說：

UID/GID 與 rwx 權限模式

代表檔案擁有者(root)有讀寫權限，群組成員僅能讀取，其他使用者也只能讀取。

在容器環境中，若容器內程序以 root 身份執行，且檔案權限設定寬鬆，則攻擊者可能利用漏洞修改關鍵設定檔案。

Linux Capabilities

傳統上，root 使用者擁有幾乎所有系統權限。Linux 引入 Capabilities 概念，將 root 權限拆分為更細的能力(如 NET_ADMIN、SYS_TIME、CHOWN)，讓程序僅能擁有其運行所需的最小權限。

例如，可透過以下指令檢視程序所擁有的 Capabilities：

Linux Capabilities

在 Docker 中，可以利用 “–cap-drop” 或 “–cap-add” 調整容器所需的權限：

Docker

在 Kubernetes 中，則可透過 Pod SecurityContext 來限制：

Kubernetes

特權提升(Privilege Escalation)

在容器安全中，特權提升是常見風險之一。攻擊者可能利用系統漏洞或錯誤設定，將容器內的非特權使用者提升為 root，甚至進一步突破容器邊界影響宿主機。為了降低風險，建議在容器中使用非 root 使用者執行應用，並透過 `allowPrivilegeEscalation: false` 來限制可能的提權行為。

Software Vulnerabilities in Images

容器映像檔是應用程式運行的基礎。若映像檔中包含軟體漏洞，將直接影響容器的安全性。常見的問題包括使用過時的基底映像檔、安裝未經驗證的第三方套件、或未及時更新系統元件。

常見漏洞來源

1. 過時的基底映像檔：許多映像檔仍基於已不再維護的版本(如舊版 Debian 或 CentOS)，導致漏洞無法修補。
2. 第三方套件：未驗證來源的軟體套件可能內含惡意程式或後門。
3. 應用程式漏洞：應用程式本身若未更新，可能成為攻擊目標。
4. 配置不當：未刪除不必要的工具(如 curl、bash)，可能增加攻擊面。

映像檔安全最佳實踐

– 使用可信任的官方映像檔作為基底。
– 定期更新並掃描映像檔，使用工具如 Trivy、Clair。
– 採用多階段建構(multi-stage builds)以減少映像檔中不必要的依賴。
– 確保最小化映像檔(Minimal Images)，避免安裝多餘工具。

容器網路安全(Container Network Security)

容器網路安全是確保應用程式在分散式環境下安全運作的核心議題。由於 Kubernetes 中的網路設計天生是「所有 Pod 之間皆可互通」，若缺乏限制，任何 Pod 皆可能存取其他 Pod，這對企業環境而言具有相當的風險。因此，理解 Kubernetes 的網路基礎與 Network Policy 的管控能力，對於防止橫向移動攻擊、資料外洩與存取控制至關重要。

1. Kubernetes Networking Fundamentals

在容器編排系統中，Kubernetes 採用 CNI(Container Network Interface) 來實作網路連線，並建立了一致性的規範：

Inter-POD(跨 Pod 通訊)

每個 Pod 都擁有唯一的 IP 位址，Kubernetes 預設允許所有 Pod 在同一叢集中互相存取。這對於微服務架構非常便利，但若缺乏存取控制，攻擊者若控制一個 Pod，可能直接掃描並攻擊其他 Pod。

Intra-POD(Pod 內部通訊)

Pod 內的多個容器共享同一個網路命名空間，因此它們透過 localhost 就能彼此通訊。這種設計降低了內部溝通的複雜度，但同時也需要注意單一容器被入侵後，可能對同一 Pod 內的其他容器造成威脅。

Ingress(入口流量)

Ingress 是 Kubernetes 中暴露服務到叢集外部的方式，通常搭配 Ingress Controller 使用，例如 NGINX Ingress Controller。Ingress 必須搭配憑證(TLS/SSL)與存取控制，否則可能成為攻擊者的入侵入口。

Egress(出口流量)

Pod 對外存取網際網路或其他內部服務的流量稱為 Egress。若未限制，惡意 Pod 可能外洩敏感資料，或與 C&C(Command and Control)伺服器建立連線，因此對於 Egress 控制同樣至關重要。

2. Kubernetes Network Policy

雖然 Kubernetes 預設允許所有 Pod 互相通訊，但企業環境通常需要 零信任網路架構(Zero Trust Network)，必須明確規範哪些 Pod 可以通訊、哪些不行。這就是 Kubernetes Network Policy 的作用。

Network Policy 功能：

  • 限制 Pod 的 ingress (進入流量)。
  • 限制 Pod 的 egress (對外流量)。
  • 以 Label 為基礎定義存取規則 (PodSelector)。
  • 搭配支援 NetworkPolicy 的 CNI 外掛 (例如 Calico, Cilium, Weave Net)。

3. Network Policy

範例一，展示如何限制某個應用程式只能被指定 Pod 存取：

如何限制某個應用程式只能被指定 Pod 存取

說明：

  • podSelector：選擇 app=backend 的 Pod 作為管控目標。
  • policyTypes: Ingress：表示這份規則只控制進入流量。
  • from：僅允許帶有 app=frontend Label 的 Pod 存取 backend。
  • ports：限制只能存取 TCP 8080 連接埠。

這樣的規則確保只有 frontend Pod 可以連線到 backend Pod，其他 Pod 即使在同一命名空間內，也會被拒絕存取。

範例二，同時限制 Egress

若要同時限制 Pod 的外部連線，可以新增 egress 控制：

說明：

  • 僅允許 backend Pod 對0.0.0/16 網段的 MySQL(3306/TCP)進行連線。
  • 這樣能避免 backend Pod 外洩資料到不明來源或網際網路。

4. Network Policy最佳實踐

無論使用哪種工具來建立、管理和強制執行 Network Policy，都建議遵循以下最佳實務：

  • Default Deny(預設拒絕)

遵循最小權限原則，為每個命名空間設定預設拒絕 ingress 流量，然後只允許需要的流量。

  • Default Deny Egress(預設拒絕出口流量)

Egress 政策控制 Pod 對外流量。若容器遭入侵，攻擊者可能探測周圍環境。

建議每個命名空間設定預設拒絕 egress 流量，再針對必要的對外連線添加允許規則。

  • Restrict Pod-to-Pod Traffic(限制 Pod 間流量)

使用 Pod Label 定義應用程式，限制流量只在允許的應用間流動。

只允許帶有適當 Label 的 Pod 存取特定 Pod。

  • Restrict Ports(限制端口)

限制流量只允許通往應用所需的特定端口。

避免開放非必要端口，降低攻擊面。

5. Service Mesh

Service Mesh 提供應用層級的額外控制能力，用於管理服務間連線。其運作方式通常是在每個 Pod 注入 Sidecar 容器，由 Sidecar 代理容器處理網路流量，並在用戶空間執行規則強制。

核心特性

  • Sidecar 代理

所有進出 Pod 的流量都透過 Sidecar Proxy 處理。

支援流量加密、流量監控、路由控制及策略執行。

  • Mutual TLS (mTLS)

Sidecar 代理可啟用 mTLS，確保 Pod 之間的連線加密，降低攻擊者攔截流量的風險。mTLS 提供身份驗證與加密，提升部署內部的安全性。

  • 限制與注意事項

Service Mesh 僅對已注入 Sidecar 的 Pod 提供保護。未注入 Sidecar 的 Pod 不受影響。

Service Mesh 網路策略通常以服務層級定義，無法直接保護底層基礎設施免於被入侵的 Pod。

最佳實務

  • 配合 Defense in Depth (多層防禦) 原則，Service Mesh 外，應同時使用容器網路安全解決方案，限制 Pod 之間以及 Pod 對外的直接流量。
  • 使用工具確認所有容器都注入了 Sidecar，避免未受保護的 Pod 存在安全漏洞。
  • 搭配 Network Policy，確保即使 Pod 被入侵，也無法繞過 Sidecar 進行未授權流量。

結語

容器技術的快速發展，帶來了更高的靈活性與彈性，但也引入了新的安全挑戰。本書從威脅模型、Linux 系統呼叫與權限機制，到映像檔漏洞管理，全面剖析了容器安全的關鍵要素。最終，容器安全並非單一技術可解決，而是需要從基礎設計、組態管理、持續監控、以及供應鏈防護等多層面共同努力。唯有透過縝密的規劃與實務落實，企業才能在享受容器技術帶來效益的同時，有效降低資安風險。

【 作者簡介 】：

 華經資訊企業股份有限公司 高級工程師/廖一銘

  • 回上層