Kubernetes安全攻防：容器安全防禦策略

– 15 分鐘閱讀

根據以上分析，我建議採取以下安全措施來防禦掛載名稱空間相關的攻擊：

1. 限制掛載許可權

掛載點是容器安全的重要邊界，應該嚴格控制。遵循以下原則：

  • 盡可能使用只讀掛載
  • 避免掛載宿主機的敏感目錄
  • 禁止掛載 Docker 通訊端到容器中

2. 停用特權容器

特權容器本質上會繞過大多數安全控制，除非絕對必要，否則應該停用。在 Kubernetes 中，使用 PodSecurityPolicy 或 Pod Security Standards 來強制執行這一點。

3. 隔離名稱空間

確保容器不分享關鍵名稱空間，特別是：

  • 避免設定 hostPID: true
  • 避免設定 hostIPC: true
  • 避免設定 hostNetwork: true

4. 實施最小許可權原則

容器應該只擁有完成其任務所需的最小許可權集。這包括：

  • 使用非 root 使用者執行容器
  • 移除不必要的 Linux 能力
  • 實施 seccomp 和 AppArmor 設定檔案

在處理容器安全時，我總是將掛載名稱空間視為首要關注點之一。透過深入理解掛載機制的工作原理及其潛在風險，我們可以構建更安全的容器環境。

容器技術提供了便利的隔離環境，但這種隔離並非絕對。掛載名稱空間尤其是容器抽象層中最容易被利用的部分之一。透過理解這些風險並實施適當的防禦措施，我們可以顯著提高容器環境的安全性，防止潛在的容器逃逸攻擊。

容器安全是一個持續演進的領域，需要我們不斷學習新的攻擊技術和防禦策略。掛載名稱空間的安全只是整體容器安全策略的一部分，但它是一個不容忽視的關鍵環節。

容器逃逸的隱形殺手：檔案系統漏洞剖析

在容器化環境中，安全性一直是最重要的議題之一。容器技術的核心是隔離性，但這種隔離並非絕對。容器的檔案系統雖然與主機隔離，但實際上仍然建立在主機檔案系統上，這就為潛在的容器逃逸攻擊留下了可能性。

/proc/self/exe 漏洞：容器逃逸的經典案例

在我分析容器安全漏洞時，發現 CVE-2019-5736 是一個極具代表性的案例。這個漏洞利用了 /proc/self/exe 這個特殊的偽檔案，成功實作了從容器到主機的逃逸。

/proc/self/exe 是 Linux 系統中的一個符號連結，指向當前執行中程式的可執行檔案路徑。在容器環境中，這個檔案本應該被妥善處理，但 runc 實作中的一個錯誤假設導致了嚴重的安全漏洞。

漏洞技術原理解析

這個漏洞的核心在於符號連結處理的錯誤。當容器啟動時，容器執行時（如 runc）會解壓檔案系統層並準備 pivot_root 操作。在這個過程中，/proc/self/exe 這個偽檔案會指向容器執行時本身，例如指向主機上的 runc 二進位檔案。

攻擊路徑如下：

  1. 容器映像設定入口點為指向 /proc/self/exe 的符號連結
  2. 容器內的本地 /proc/self/exe 實際上指向主機檔案系統上的容器執行時
  3. 攻擊者利用這個連結，獲得對主機上 runc 二進位檔案的寫入許可權
  4. 完成主機提權，在容器內獲得主機 root 存取許可權

這種攻擊的危險性在於它可以完全從惡意映像執行，不需要外部輸入，並能以 root 身分在主機上執行任何負載。這是典型的供應鏈攻擊，但具有雲原生的特色。

為何這個漏洞如此危險？

這個漏洞之所以特別危險，主要有三個原因：

  1. 無需外部互動：攻擊可以完全從容器映像內部發起，不需要外部輸入
  2. 許可權提升：成功利用後，攻擊者可以獲得主機的 root 許可權
  3. 隱蔽性強：可以隱藏在看似正常的容器映像中，難以透過常規掃描發現

值得注意的是，這個漏洞是由關注安全的 runc 核心開發者 Aleksa Sarai 發現的，並沒有被駭客在野外利用的先例。這再次突顯了安全測試的困難性，必須考慮惡意輸入、邊界情況和意外的程式碼路徑。

Kubernetes 中的敏感資訊安全風險

在容器協調平台中，敏感資訊的管理同樣面臨重大挑戰。Kubernetes 中的 Secret 資源用於儲存敏感資訊，但其預設實作存在一些安全隱患。

Secret 掛載機制及其安全隱憂

Kubernetes 中的 Secret 預設以未加密的形式儲存在 etcd 中，並可以透過掛載卷或環境變數的方式被 Pod 消費。工作節點上執行的 kubelet 負責將包含明文 Secret 的卷掛載到 Pod 中。

這些 Secret 用於與其他系統元件互動，包括 Kubernetes API 授權的服務帳戶 Secret，或外部服務的憑證。

apiVersion: v1
kind: Secret
# ...
data:
  ca.crt: LS0tLS1CRUdAcCE55B1e55ed...
  namespace: ZGVmYXVsdA==
  token: ZXlKaGJHY2lPC0DeB1e3d...
immutable: true

Secret 掛載的安全風險

當 Secret 被掛載到 Pod 中時，存在以下安全風險：

  1. 節點許可權擴散：如果攻擊者能夠獲得工作節點的 root 許可權，他們可以讀取該節點上所有 Pod 的所有 Secret
  2. 缺乏自動輪換：標準服務帳戶令牌是永不過期的 JWT，沒有自動輪換機制
  3. 身分盜用風險：攻擊者可能竊取服務帳戶令牌，獲得對工作負載和資料的更深入存取

在我多年的安全實踐中，發現節點 root 許可權與所有工作負載的許可權等同，這是一個經常被忽視的嚴重安全風險。節點上的 root 使用者可以存取所有工作負載的身分，這大擴大了潛在的攻擊面。

繫結服務帳戶令牌：增強的安全解決方案

為瞭解決標準服務帳戶令牌的安全問題，Kubernetes 引入了繫結服務帳戶令牌。這種令牌擴充套件了標準服務帳戶令牌，實作了完整的 JWT，支援過期和受眾限制。

繫結服務帳戶令牌由 kubelet 為 Pod 請求，並由 API 伺服器頒發。NodeAuthorizer 確保 kubelet 只請求它應該執行的 Pod 的令牌，以緩解被盜用的 kubelet 憑證造成的風險。

繫結令牌的許可權衰減特性降低了被入侵的影響範圍和利用的時間視窗。

容器環境中的服務帳戶攻擊技術

當攻擊者獲得對 Pod 的遠端存取許可權時，他們通常會首先檢查服務帳戶令牌。服務帳戶濫用是 Kubernetes 許可權提升的常見機制。

服務帳戶許可權探測技術

攻擊者可以使用 selfsubjectaccessreviews.authorization.k8s.io 和 selfsubjectrulesreviews.authorization.k8s.io API 來列舉可用的許可權。在實戰中，如果能夠在容器內執行命令，可以使用 kubectl auth can-i --list 檢視當前服務帳戶的許可權。

對於更複雜的情況，如果能夠提取二進位檔案，可以使用 rakkess 工具獲得更清晰的許可權檢視：

$ rakkess
NAME                                      LIST  CREATE  UPDATE  DELETE
apiservices.apiregistration.k8s.io        ✔      ✔       ✔       ✔
...
secrets                                   ✔      ✔       ✔       ✔
selfsubjectaccessreviews.authorization.k8s.io  ✔
selfsubjectrulesreviews.authorization.k8s.io   ✔
serviceaccounts                           ✔      ✔       ✔       ✔
services                                  ✔      ✔       ✔       ✔
...

許可權探測的安全意義

這種許可權探測技術本身不是漏洞，而是 Kubernetes 身分機制的正常工作方式。但未繫結服務帳戶令牌缺乏過期機制確實是一個嚴重風險。從安全形度看，我認為應該採取以下措施：

  1. Kubernetes API 伺服器不應該對不直接需要它的客戶端開放
  2. 包括 Pod 在內，如果不需要與 API 通訊，應該使用網路策略進行防火牆隔離
  3. 需要與 API 伺服器通訊的營運工具必須有網路由和身分（服務帳戶），但需要特別注意確保其許可權不會過大

Kubernetes 儲存概念與安全實踐

在容器協調環境中，儲存系統的安全同樣至關重要。Kubernetes 透過容器儲存介面（CSI）使用卷來整合 Pod 和外部或虛擬儲存系統。

容器儲存介面的安全考量

CSI 允許多種型別的儲存與 Kubernetes 整合，並包含大多數流行的區塊儲存和檔案儲存系統的驅動程式，以在卷中公開資料。這些包括：

  • 來自託管服務的塊和彈性儲存
  • 開放原始碼分散式檔案系統（如 Ceph）
  • 專用硬體和網路附加儲存
  • 各種第三方儲存解決方案

從安全形度看，儲存介面的整合點是潛在的攻擊面。在設計使用 CSI 的系統時，應該考慮以下安全原則：

  1. 最小許可權原則：CSI 驅動程式應該只具有必要的許可權
  2. 身分隔離：不同的儲存系統應使用不同的服務帳戶
  3. 加密傳輸：在 CSI 和儲存系統之間的通訊應該加密
  4. 存取控制：實施嚴格的存取控制策略，限制誰可以使用特定的儲存類別

容器安全最佳實踐建議

根據上述分析，我總結了一些容器環境中的安全最佳實踐：

  1. 定期更新容器執行時：及時修補已知漏洞，如 CVE-2019-5736
  2. 使用不可變 Secret：Kubernetes v1.21 引入了不可變 ConfigMap 和 Secret，建立後無法更改
  3. 實施 Secret 輪換：定期輪換服務帳戶令牌，透過從 Kubernetes Secrets API 刪除它們
  4. 採用繫結服務帳戶令牌：利用其過期和受眾限制功能增強安全性
  5. 網路隔離：使用網路策略限制 Pod 與 API 伺服器的通訊
  6. 監控和入侵檢測：佈署監控系統檢測異常行為，特別是針對供應鏈攻擊
  7. 容器映像掃描：定期掃描容器映像中的已知漏洞
  8. 儲存加密：確保敏感資料在儲存時加密

容器安全是一個多層面的挑戰，需要從基礎設施、設定、網路和應用程式層面同時加強。透過理解這些漏洞的工作原理和攻擊途徑，我們可以更有效地設計防禦策略，保護容器化環境的安全。

安全不是一次性的努力，而是一個持續的過程。隨著容器技術的不斷發展，新的漏洞和攻擊向量也會不斷出現。保持警覺，及時更新知識和系統，是維護容器環境安全的關鍵。

Kubernetes 儲存安全：卷攻擊與防禦機制

容器技術的美妙之處在於其無狀態特性，但實際應用中，我們總需要處理持久化資料。Kubernetes 提供了豐富的卷機制來解決這個問題，但每一種卷型別都可能帶來安全風險。在我多年的容器安全實踐中發現，儲存元件往往是被忽視的攻擊面，卻可能成為整個系統的突破口。

卷掛載的傳播機制與安全隱憂

在 Kubernetes 的底層實作中，外掛會「傳播」掛載的卷，這意味著 Pod 內的容器可以分享這些卷，甚至可以將容器內的變更傳播回主機。當主機的檔案系統反映容器掛載的卷時，這被稱為「雙向掛載傳播」(bi-directional mount propagation)。

這種機制雖然便利，但也帶來了明顯的安全風險。當攻擊者控制了容器，他們可能利用這種傳播機制影響主機或其他容器的檔案系統。特別是在許可權設定不當的情況下，雙向傳播可能導致敏感資料被竊取或惡意程式碼被注入。

投影卷：API 資料的容器化存取

除了標準的 Linux 卷型別，Kubernetes 還提供了特殊的投影卷(Projected Volumes)型別。這些卷用於將 API 伺服器或 kubelet 的資料掛載到 Pod 中，例如將容器或 Pod 的中繼資料投影到卷中。

以下是一個簡單的範例，展示如何將 Secret 物件投影到卷中，並設定適當的許可權：

apiVersion: v1
kind: Pod
metadata:
  name: test-projected-volume
spec:
  containers:
  - name: test-projected-volume
    image: busybox
    args:
    - sleep
    - "86400"
    volumeMounts:
    - name: all-in-one
      mountPath: "/projected-volume"
      readOnly: true
  volumes:
  - name: all-in-one
    projected:
      sources:
      - secret:
          name: user
          items:
          - key: user
            path: my-group/my-username
            mode: 511
      - secret:
          name: pass
          items:
          - key: pass
            path: my-group/my-username
            mode: 511

這個 YAML 檔案定義了一個名為 test-projected-volume 的 Pod，其中包含一個同名的容器。這個容器掛載了一個名為 all-in-one 的投影捲到 /projected-volume 路徑。該卷從兩個不同的 Secret（user 和 pass）取得資料，並將它們對映到相同的路徑 my-group/my-username。

值得注意的是 mode: 511 設定，這是八進位制的 0777，表示這些檔案將具有完全的讀、寫和執行許可權。在生產環境中，應該設定更嚴格的許可權來遵循最小許可權原則。

投影卷的主要優勢在於它們從與 Pod 相同的名稱空間中取得現有資料，並使其在容器內更容易存取。Kubernetes 支援的投影卷型別包括：

  1. Secret - 來自 Kubernetes API 伺服器的 Secret 物件
  2. downwardAPI - 來自 Pod 或其節點設定的元素（如中繼資料、標籤、註解、資源限制等）
  3. ConfigMap - 來自 Kubernetes API 伺服器的 ConfigMap 物件
  4. serviceAccountToken - 來自 Kubernetes API 伺服器的服務帳號令牌

服務帳號令牌的安全處理

投影卷還可以用來改變服務帳號 Secret 的位置，使用 TokenRequestProjection 功能，這可以防止 kubectl 和其客戶端自動發現服務帳號令牌。雖然這種隱蔽性不應被視為安全邊界，但它確實可以增加攻擊者的難度：

apiVersion: v1
kind: Pod
metadata:
  name: sa-token-test
spec:
  containers:
  - name: container-test
    image: busybox
    volumeMounts:
    - name: token-vol
      mountPath: "/service-account"
      readOnly: true
  volumes:
  - name: token-vol
    projected:
      sources:
      - serviceAccountToken:
          audience: api
          expirationSeconds: 3600
          path: token

這個 YAML 範例定義了一個 Pod，它使用投影卷來自定義服務帳號令牌的位置。與預設的 /var/run/secrets/kubernetes.io/serviceaccount 不同，此設定將令牌掛載到 /service-account/token 路徑。

設定中的 audience: api 指定了令牌的目標受眾，expirationSeconds: 3600 將令牌的過期時間設定為一小時。這種做法增加了安全性，因為即使令牌被竊取，也只在有限的時間內有效。

卷攻擊：容器儲存的安全風險

對攻擊者而言，掛載到 Pod 中的每個卷都是潛在的目標。這些卷可能包含他們想要竊取或滲透的資料，包括：

  • 使用者資料和密碼
  • 個人識別訊息
  • 應用程式的核心機密
  • 任何對擁有者具有財務價值的資訊

服務帳號令牌：容器身份的安全隱患

無狀態的容器應用不會在容器內部持久化資料，它們從其他服務（應用、資料函式庫或掛載的檔案系統）接收或請求訊息。當攻擊者控制了 Pod 或容器，他們實際上是在冒充它，可以使用掛載為 Kubernetes Secret 的憑證從其他服務竊取資料。

掛載在 /var/run/secrets/kubernetes.io/serviceaccount 的服務帳號令牌是容器的身份：

bash-4.3# mount | grep secrets
tmpfs on /var/run/secrets/kubernetes.io/serviceaccount type tmpfs (ro,relatime)

預設情況下，服務帳號令牌會掛載到佈署的每個 Pod 例項中，這使其成為一種相當通用的身份形式。它也可能被掛載到其他 Pod 及其副本中。GCP 的工作負載身份(Workload Identity)將此稱為「工作負載身份池」，可以理解為一個角色。

攻擊者進入 Pod 後，可以惡意地發起普通的網路請求，使用服務帳號憑證向雲 IAM 服務授權。這可能會使攻擊者獲得對 SQL、熱儲存和冷儲存、機器映像、備份和其他雲儲存系統的存取許可權。

容器內許可權提升的風險

執行容器網路導向程式的使用者應該具有最小許可權。容器攻擊面（通常是其網路導向的通訊端）中的漏洞最初只會給攻擊者提供對該程式的控制權。

在容器內提升許可權可能涉及攻擊者的複雜漏洞利用，這為像「恐怖海盜 Hashjack」這樣的攻擊者設定了另一道安全障礙，他們可能更傾向於轉向更容易的目標。如果他們堅持不懈，他們將無法深入滲透，必須在網路中停留更長時間，這可能會增加被發現的可能性。

在下面的例子中，Pod 在 /cache 處有一個掛載的卷，它受到自主存取控制(DAC)的保護，就像所有其他 Linux 檔案一樣：

# df
Filesystem     1K-blocks    Used Available Use% Mounted on
overlay        98868448  5276296  93575768   5% /
tmpfs             65536        0     65536   0% /dev
tmpfs           7373144        0   7373144   0% /sys/fs/cgroup
/dev/sda1      98868448  5276296  93575768   5% /cache

掛載在捲上的檔案系統：

# ls -lap /cache/
total 16
drwxrwxrwx 4 root     root      4096 Feb 25 21:48 ./
drwxr-xr-x 1 root     root      4096 Feb 25 21:46 ../
drwxrwxrwx 2 app-user app-user  4096 Feb 25 21:48 .tmp/
drwxr-xr-x 2 root     root      4096 Feb 25 21:47 hft/

在這個例子中，擁有容器主要程式的應用使用者可以將臨時檔案（如處理產物）寫入掛載點，但只能讀取 hft/ 目錄中的資料。如果被入侵的使用者可以寫入 hft/ 目錄，他們可能會為卷的其他使用者汙染快取。如果容器從分割槽執行檔案，則在分享捲上放置的後門允許攻擊者在執行它的卷的所有使用者之間移動。

在這種情況下，root 擁有 hft/ 目錄，所以如果攻擊者不能在容器內成為 root，這種攻擊就不可能實作。

符號連結解析的安全風險

在掛載的檔案系統中，符號連結的解析是資料滲透的常見途徑。例如，在 Hackerone 漏洞獎勵計劃中發現的一個案例顯示，kubelet 在 /var/log 中以 root 身份跟隨符號連結，這可能導致嚴重的安全問題。

當容器執行來自捆綁在其映像內的應用程式時，它們通常支援確定性原則和容器映像掃描。執行不受信任或未知的程式碼，例如 curl x.cp | bash，是不明智的。同樣，在執行來自掛載卷或遠端位置的二進位檔案之前，應該驗證其校驗和。

資料的安全性依賴於檔案系統許可權。如果容器維護者沒有正確設定檔案系統或使用者，攻擊者可能會找到取得資料的方法。setuid 二進位檔案是提升許可權的傳統途徑，在容器內不應該需要這些許可權：特權操作應該由 init 容器處理。

主機掛載的危險性

如果攻擊者無法進入掛載了卷的目標 Pod，他們可能會使用竊取的服務帳號憑證將卷掛載到惡意 Pod。在這種情況下，攻擊者有許可權佈署到名稱空間，因此准入控制器是防禦被盜憑證的最後一道防線。防止 root 許可權的 Pod 可以幫助維護分享卷的安全性，以及來自 Pod 或從主機或網路掛載的程式和裝置的安全性。

Pod 中的 root 存取是麻煩的入口。許多攻擊可以透過在 Dockerfile 中降級到非特權使用者來防止。

主機掛載目錄的安全隱患

正如 2019 年 Aqua 的一篇部落格文章所指出的：

Kubernetes 有許多組成部分，有時將它們以特定方式組合可能會產生意外的安全漏洞。在這篇文章中，你將看到一個以 root 身份執行並掛載到節點的 /var/log 目錄的 Pod 如何將其主機檔案系統的全部內容暴露給任何有權存取其日誌的使用者。

Pod 可能會將主機檔案系統的目錄掛載到容器中，例如 /var/log。使用子目錄並不能阻止容器移動到該目錄之外。符號連結可以參照同一檔案系統上的任何位置，因此攻擊者可以探索他們有權存取的任何檔案系統。

防禦策略：保護容器卷安全

在瞭解了卷相關的攻擊向量後，讓我們來看一些實用的防禦策略：

1. 實施最小許可權原則

在容器安全中，最小許可權原則尤為重要。對於卷掛載，這意味著：

  • 使用只讀掛載：除非絕對需要寫入許可權，否則應將卷設定為只讀
  • 限制卷路徑：只掛載應用程式真正需要的目錄，避免掛載整個檔案系統
  • 使用適當的檔案許可權：確保捲上的檔案具有適當的所有權和許可權設定

2. 安全管理服務帳號

服務帳號是 Kubernetes 中的重要身份機制，但也是潛在的安全風險：

  • 停用自動掛載：使用 automountServiceAccountToken: false 停用不需要 API 存取的 Pod 的令牌掛載
  • 使用 RBAC 限制許可權：為每個服務帳號設定精確的角色繫結，遵循最小許可權原則
  • 實施令牌過期：使用投影卷的 expirationSeconds 設定短期令牌過期時間

3. 安全設定主機掛載

主機掛載是最危險的卷型別之一：

  • 避免使用主機掛載：盡可能使用 PersistentVolume 而非 hostPath
  • 使用只讀掛載：如果必須使用主機掛載，將其設定為只讀
  • 實施 Pod 安全策略：使用 PSP 或 Pod Security Admission 限制可以使用主機掛載的 Pod
  • 使用 SELinux/AppArmor：實施強制存取控制，限制容器對主機檔案系統的存取

4. 防止符號連結攻擊

符號連結攻擊是卷安全中的常見問題：

  • 使用卷掛載選項：某些儲存驅動程式支援 nofollow 選項，防止跟隨符號連結
  • 實施檔案系統隔離：使用適當的名稱空間和掛載選項隔離容器檔案系統
  • 掃描和監控：定期掃描掛載的卷，檢測可疑的符號連結

5. 實施容器執行時安全

除了卷特定的安全措施外，還應實施通用的容器安全實踐：

  • 使用非 root 使用者：在 Dockerfile 中使用 USER 指令以非 root 使用者執行容器
  • 啟用 read-only root filesystem：使用 readOnlyRootFilesystem: true 防止對容器檔案系統的修改
  • 實施 seccomp/AppArmor 設定：限制容器可以執行的系統呼叫
  • 使用容器安全掃描器：定期掃描容器映像，檢測已知漏洞

實際案例：卷安全漏洞利用與防禦

為了更好地理解卷安全的重要性，讓我們看一個實際的案例分析：

案例：服務帳號令牌濫用

在一個生產環境中，攻擊者利用一個存在漏洞的網路應用程式獲得了對 Pod 的存取許可權。由於該 Pod 自動掛載了服務帳號令牌，攻擊者能夠：

  1. 使用令牌查詢 Kubernetes API 伺服器
  2. 列出名稱空間中的所有資源
  3. 建立新的 Pod，掛載敏感的儲存卷
  4. 從這些卷中竊取資料

防禦措施：

  1. 為應用程式建立專用的服務帳號，僅授予必要的許可權
  2. 對不需要 API 存取的 Pod 使用 automountServiceAccountToken: false
  3. 實施網路政策，限制 Pod 對 API 伺服器的存取
  4. 使用 OPA Gatekeeper 或 Kyverno 等准入控制器，防止特權 Pod 的建立

案例：主機掛載漏洞利用

在另一個案例中，一個用於日誌收集的 Pod 以 root 身份執行，並掛載了主機的 /var/log 目錄。攻擊者利用容器中的漏洞獲得了存取許可權，然後：

  1. 在 /var/log 中建立指向 /etc/shadow 的符號連結
  2. 讀取主機的密碼雜湊
  3. 透過建立指向 /root/.ssh/authorized_keys 的符號連結，植入 SSH 金鑰
  4. 獲得對主機的完全存取許可權

防禦措施：

  1. 使用專用的日誌收集解決方案，如 Fluentd 或 Elasticsearch，避免直接掛載主機日誌目錄
  2. 如果必須掛載主機目錄，使用只讀模式並以非 root 使用者執行容器
  3. 使用 Pod 安全策略限制主機掛載的使用
  4. 實施強制存取控制（MAC）系統，如 SELinux 或 AppArmor，限制容器對主機檔案系統的存取

保護 Kubernetes 卷安全是容器安全策略的重要組成部分。透過遵循這些最佳實踐，可以顯著降低卷相關的安全風險：

  • 對所有卷實施最小許可權原則，使用只讀掛載和適當的檔案許可權
  • 謹慎管理服務帳號令牌，使用 RBAC 限制許可權，並考慮停用自動掛載
  • 避免使用主機掛載，如果必須使用，則實施嚴格的安全控制
  • 防範符號連結攻擊，特別是在掛載主機目錄時
  • 使用非 root 使用者執行容器，並實施容器執行時安全措施
  • 定期稽核卷設定和使用情況，檢測潛在的安全問題
  • 使用准入控制器強制執行卷安全策略

在容器化環境中，儲存安全往往是最容易被忽視的方面之一，但它可能是攻擊者取得敏感資料或提升許可權的關鍵途徑。透過理解卷相關的攻擊向量並實施適當的防禦措施，可以大提高 Kubernetes 環境的整體安全性。

在設計容器化應用時，應將儲存安全視為架構的核心組成部分，而不是事後的考慮。透過深入瞭解 Kubernetes 卷機制的工作原理及其安全隱患，我們可以構建更安全、更可靠的容器化系統。

玄貓

玄貓

技術愛好者，專注於分享程式開發、雲端技術與 AI 應用的心得體會。