NIST SP 800–190 Part 2 風險
本文將探討如何識別並分析容器技術核心組件（images, registries, orchestrators, containers, 與host OS）的主要風險。 由於該分析只著眼於核心組件，因此它適用於大多數的容器部署，無論容器技術、Host OS平台(公有雲、私有雲等)是長得甚麼樣。有以下兩種類型的風險需要被考量：
- Compromise of an image or container。使用 NIST SP 800–154 中描述的以data-centric的系統威脅建模方法來評估此風險。 要保護的主要“資料”是Image和Container，它們可能保存應用程式檔案、資料檔案等。要保護的次要資料是共享主機的資源（例如memory、storage和network interface）內的容器資料。
- 濫用容器來攻擊其他容器、Host OS、其他hosts等。
涉及核心組件的所有其他風險，以及涉及非核心容器技術組件的風險，包括開發人員系統、測試和認證系統、管理員系統以及主機硬體和VM管理器，不在NIST SP 800–190的討論中。
Image的風險
Image的弱點
由於Image實際上是一種static archive files，其中包含用於運作特定應用程式的所有組件，因此Image中的組件可能是舊的或是缺少主要的安全更新。 使用完全最新的組件建立的Image可能在建立後數天或數週內沒有已知漏洞，但有時會在一個或多個Image ccomponent中發現漏洞，因此該Image將不再更新。
與傳統的運作模式不同，在傳統的運作模式中，已部署的軟體是在其運作的主機上“現場”更新的，而對於容器，這些更新必須在Image本身的上游進行，然後重新部署。 因此，容器化環境中的常見風險是部署具有漏洞的容器，因為用於生成容器的鏡像版本存在漏洞。
反制措施
需要專用的容器技術的漏洞管理工具和流程。 傳統的漏洞管理工具的假設從根本上與容器化模型不一致。 這些工具通常無法檢測容器內的漏洞，從而導致錯誤的安全感。企業應該使用pipeline-based build approach以及容器和Image的不可變性質納入其設計的工具，以提供更具可操作性和可靠性的結果。 有效工具和流程的關鍵面向包括：
- 與Image的整個生命週期整合，從build process的開始，到企業使用的任何Registry，再到runtime。
- 了解Image所有層次的漏洞，不僅包括Image的base layer，還包括企業正在使用的應用程式框架和自行開發的軟體。 可見性應該集中在整個企業中，並提供與企業業務流程一致的報告和監控視圖。
- Policy-driven enforcement； 企業應該能夠在build and deployment process的每個階段建立“quality gates”，以確保只有滿足企業的漏洞和配置政策的Image才允許繼續進行。 例如，企業應該能夠在build process中配置規則，以防止包含CVSS(Common Vulnerability Scoring System) 評級高於選定閾值的漏洞的Image的進程。
Image的配置缺陷
除了軟體缺陷之外，Image還可能存在配置缺陷(Configuration defect)。 例如，Image可能沒有配置特定的user account來“運作”，因此常常會用root/admin的權限運行。 例如，Image可能包含 SSH daemon，這會使容器面臨不必要的網路風險。 就像在傳統伺服器或VM中一樣，不良的配置仍然可能使完全最新的系統受到攻擊，因此，即使所有包含的組件都是最新的，配置不良的Image也會增加風險。
反制措施
企業應採用工具和流程來驗證和強制遵守安全配置最佳實踐。 例如，Image應配置為以非特權用戶身份運作。 應採用的工具和流程包括：
- 驗證image configuration settings，包括廠商商的建議和第三方最佳實踐。
- 持續、不斷更新、集中報告和監控Image合規狀態，以識別組織面的弱點和風險。
- 通過選擇性地阻止不合規Image的運行來執行合規性要求。
- 只使用來自可信來源的base layer、頻繁更新base layer以及從 Alpine Linux 和 Windows Nano Server 等簡化技術中選擇base layer，以減少攻擊面。
對於image configuration的最後一個建議是，永遠不要在容器內啟用 SSH或其他類似的遠端管理工具。 容器應該以不可變的方式運行，以便從其中獲得最大的安全優勢。 通過這些工具實現對它們的遠端存取意味著一定程度的變更，這違反了這一原則，並使它們面臨更大的網路攻擊風險。 相反，容器的所有遠端管理都應通過container runtime API 來完成，這些 API 可以通過orchestration tools進行存取，或者通過建立與運行容器的Host的remote shell sessions來完成。
嵌入的惡意程式
由於圖Image只是打包在一起的檔案集合，因此惡意檔案可能會有意或無意地包含在其中。 此類惡意程式將具有與Image中任何其他組件相同的功能，因此可用於攻擊環境中的其他容器或主機。 嵌入式惡意程式的一個可能來源是使用第三方提供的base layer和其他Image。
反制措施
企業應持續監控所有Image是否存在嵌入式惡意程式。 監控過程應包括使用malware signature sets和主要基於實際“in the wild” attacks的行為偵測啟發法。
嵌入的明碼文字secrets
許多應用程式需要secrets才能實現組件之間的安全通訊。 例如，Web 應用程式可能需要username和apssword才能連接到後端資料庫。 嵌入式secret的其他範例包括connection strings, SSH private keys與X.509 private keys。 當應用程式打包成Image時，這些secrets可以直接嵌入到Image的 file system中。 然而，這種做法會帶來安全風險，因為任何有權存取該Image的人都可以輕鬆解析這些secrets。
反制措施
Secrets應該存儲在Image之外，並根據需要在runtime動態提供。 大多數Orchestrator（例如 Docker Swarm 和 Kubernetes）都包含native management of secrets。 這些Orchestrator不僅提供secrets的安全存儲和“及時”注入容器，而且還使將secret management整合到build and deployment processes中變得更加簡單。 例如，企業可以使用這些工具將DB connection string安全地配置到 Web 應用程式容器中。 Orchestrator可以確保只有 Web 應用程式容器可以存取這個secrets，並且不會將其保留到Disk，並且無論何時部署 Web 應用程序，都會將secrets配置到其中。
組織還可以將其容器部署與已用於在非容器環境中存儲機密的現有企業機secret management systems進行整合。 這些工具通常提供 API，以便在部署容器時安全地retrieve secrets，而不用將它們保留在Image中。
無論選擇哪種工具，企業都應確保根據預定義和管理員控制的設置，只將secrets提供給需要它們的特定容器，並且始終使用FIPS 140對靜態和傳輸中的secrets進行加密 。
使用未受信任的images
任何環境中最常見的高風險場景之一是執行不受信任的軟體。 容器的可移植性和重複使用性增加了團隊從可能未經充分驗證或不值得信賴的外部源運行Image的誘惑。 例如，在對網路應用程式進行故障排除時，使用者可能會在第三方提供的Image中找到該應用程式的另一個版本。 使用此外部提供的Image會導致與傳統外部軟體相同類型的風險，例如引入惡意程式、洩露資料或包含存在漏洞的組件。
反制措施
企業應維護一組受信任的Images和Registry，並確保只允許該組中的Image在其環境中運行，從而降低部署不受信任或惡意組件的風險。為了減低這些風險，組織應採取multilayered approach，包括：
- 能夠準確地集中式控制其環境中可信任的Image和Registry
- 使用經過 NIST 驗證的implementation，通過加密簽名離散(Discrete)識別的每個Image
- 強制執行以確保環境中的所有主機僅運行這些認可清單中的Image
- 在Image執行之前驗證image signatures，以確保Image來自可信任來源且未被篡改
- 持續監控和維護這些Repo，以確保隨著漏洞和配置要求的變化，維護和更新其中的Image。
Registry的風險
Registry的不安全連接
Image通常包含敏感組件，例如企業的自行開發的軟體和嵌入的secrets。 如果通過不安全的管道執行與Registry的連接，則Image內容將面臨與用明文傳輸的任何其他資料相同的保密風險。 man-in-the-middle攻擊的風險也有所增加，這些攻擊可能會攔截用於Registry的網路流量並竊取該流量中的開發人員或管理員credentials，並向Orchestrators傳述一個具欺詐或過時的Images。
反制措施
企業應將其開發工具、Orchestrator和容器運行時設定為只能只用加密通道連接到Registry。 不同工具有不同的步驟，但主要目標是確保在Registry進出的資料只能發生在受信任端點之間，並且在傳輸過程中進行加密。
Registry中過時的Images
由於Registry通常是企業部署的所有Image的來源位置，因此隨著時間的推移，它們存儲的Image set可能包含許多易受攻擊的過時版本。 雖然這些易受攻擊的Image僅存儲在Registry中不會直接構成威脅，但難保有人不會不小心佈署到生產環境的可能性。
反制措施
企業可以通過兩種主要方法來降低使用過時Image的風險。 首先，可以刪除不應該再使用的不安全、易受攻擊的Image。 此流程可以根據與Image關聯的時間觸發器和標籤來自動化。 其次，進行維運應強調使用特定的Image名稱加上版本號碼。
另一種方式不用版本號，而是對Image使用“latest”標籤，並在部署自動化中引用該標籤。 然而，由於此標籤只是附加在Image上的，並不能保證是最新，因此企業還是應謹慎行事，不要過度信任它。 無論企業使用哪一種方式，重要的是規定出流程以確保自動化使用上述兩種方法的其中之一。
驗證(Authentication)與授權(Authorization)的限制不足
由於Registry可能包含用於運行敏感或專有的應用程式以及存取敏感資料的Image，因此身份驗證和授權要求不足可能會導致IP(知識產權)遺失並向攻擊者暴露有關應用程式的重要技術細節。 更重要的是，由於Registry通常被視為有效、經過批准的軟體的來源，因此Registry的洩露可能會導致下游容器和主機受到損害。
反制措施
對所有包含企業所要使用的Container Image的Registry的所有存取都應該需要身份驗證。 對Registry的任何寫入都應該需要身份驗證，以確保只有來自受信任的Image才能加進去。 例如，只允許開發人員將Image 寫入(write)到Repo，而不是更新(Update) Repo。
企業應使用與現有的企業驗證系統結合，以利用這些身分系統已有的安全控制。 還要稽核對Registry的所有write，並且應類似地記錄機敏度高的Image的任何read。
Registry還提供了將"context-aware authorization controls"用於操運作的機會。 例如，企業可以配置其CI流程，以允許Image由授權人員簽名，並只能在通過漏洞掃描和合規性評估後推送到Registry。 企業應將這些自動掃描整合到其流程中，以防止使用到易受攻擊或配置錯誤的Image。
Orchestrator的風險
無限制的存取管理
從歷史上看，許多Orchestrator的設計假設是所有與它們交互的使用者都是管理員，並且這些管理員應該擁有最大範圍的控制權。 然而，在大多數的情況下，單一個Orchestrator可能運行許多不同的應用程式，每個應用程式由不同的團隊管理，並且具有不同的敏感等級。 如果向單一使用者和團隊提供的存取權限未滿足其特定需求，則惡意或粗心的使用者可能會影響或破壞Orchestrator所管理的其他容器運作。
反制措施
由於其控制範圍廣泛，Orchestrator應使用least privilege access model，在該模型中，使用者僅被授予在其工作角色所需的特定主機、容器和Image上執行特定操作的權限。 例如，測試團隊的成員應該只能存取測試中使用的Image以及用於運行它們的主機，並且應該只能操作他們建立的容器。 測試團隊成員對生產中使用的容器的存取權限應受到限制或無權限。
未授權的存取
Orchestrator 通常包含自己的authentication directory service，該服務可能與組織內已使用的傳統directory(如Windows AD)分開。 這可能會導致帳戶管理實踐較弱，並導致Orchestrator中出現“孤兒”帳號，因為這些系統的管理不太嚴格。 由於其中許多帳號在Orchestrator中具有很高的權限，因此它們的洩露可能會導致整個系統被攻擊。
容器通常使用由orchestration tool所管理而且不是特定於某個Host的data storage volumes。 由於容器可以在cluster內的任何特定節點上運作，因此容器內的應用程式所需的資料必須可供容器使用，無論它運行在哪個主機上。 與此同時，許多企業管理的資料必須靜態加密，以防止未經授權的存取。
反制措施
企業應嚴格控制對cluster-wide administrative accounts的存取，因為這些帳號能夠影響環境中的所有資源。 應使用強化的身份驗證方法，例如要求多重身份驗證而不僅僅是密碼。
企業應在適用的情況下對現有驗證系統實施SSO。 SSO簡化了 Orchestrator 身份驗證體驗，使用者更容易使用強化的身份驗證，並集中存取稽核，使異常偵測更加有效。
靜態資料加密的傳統方法通常是在主機中，不是用於容器。 因此，企業應該使用工具來加密與容器一起使用的資料，這些工具允許從容器中正確存取資料，無論它們在哪個節點上運行。 此類加密工具應使用與 NIST SP 800–111 中定義的相同加密方法，為未經授權的存取和篡改提供相同的屏障。
容器間網路流量分離不佳
在大多數容器化環境中，各個節點之間的流量通過virtual overlay network進行路由。 這個virtual overlay network通常由Orchestrator管理，並且通常對既有網路安全和管理工具是遮蔽的。 例如，傳統的網路設備無法看到從 Web 服務器容器發送到另一台主機上的資料庫容器的資料庫查詢，而是只能看到在兩個主機之間流動的加密資料，也無法看到正在發送的流量 。 儘管加密的overlay network提供了許多維運和安全優勢，但它也可能造成安全“盲點”的情況，使企業無法有效監控自己網路內的流量。
更重要的可能是來自共享同一virtual network的不同應用程式的流量風險。 如果不同敏感等級的應用程式（例如外部的官網和內部財務管理應用程式）使用同一virtual network，則敏感的內部應用程式可能會面臨更大的網路攻擊風險。 例如，如果外部官網遭到破壞，攻擊者可能能夠使用共享網路來攻擊財務應用程式。
反制措施
Orchestrator 應配置為按機敏度將網路流量分離到不同的virtual network。 雖然按應用程式分離也是可以的，但對於大多數企業和使用狀況來說，只需按機敏度定義網路就可以讓這個複雜的網路是可被管理並能充分緩解風險。 例如，外部網站的服務可以共享一個virtual network，內部應用程式可以使用另一個virtual network，並且兩者之間的通訊應該通過少量且定義良好的介面進行。
不同敏感等級workload的混合使用
Orchestrator主要關注於驅動著workload的規模和密度。 這意味著，預設情況下，他們可以將不同敏感等級的workload放置在同一主機上。 例如，在預設配置中，Orchestrator可能會將外部官網 的容器與處理敏感財務資料的容器放在同一主機上，僅僅是因為該主機在部署時恰好擁有最多的可用資源。 如果 外部官網中存在嚴重漏洞，則可能會使處理敏感財務資料的容器面臨更大的被攻擊風險。
反制措施
Orchestrator 應配置成按機敏度使用不同Host或不同的Cluster的方式。
雖然大多數容器運行時環境可以有效地將容器彼此隔離以及與Host OS隔離，但在某些情況下，在同一個Host OS上一起運行不同機敏度的應用程式可能會帶來不必要的風險。 "按用途、機敏度和威脅態勢"對容器進行分段可提供額外的縱深防禦。 規劃應用程式部署時應考量運用"application tiering"以及network/host segmentation等概念。 例如，假設Host正在為財務資料庫和官網運行容器。 雖然容器運行時通常會有效地將這些環境彼此隔離，但每個應用程式的 DevOps 團隊之間也有共同的責任，以安全地操作它們並消除不必要的風險。 如果官網受到攻擊者的破壞，並且這兩個應用程序在同一主機上運行，那麼保護資料庫的防禦層就會少得多。
因此，最佳實踐是按"相對機敏度"將容器分組在一起，並確保特定的Host kernel只運做單一種機敏度的容器。 這種分段可以通過使用多個實體機器來提供，但現代的hypervisors還提供足夠強大的隔離來有效減輕這些風險。 從前面的例子來看，這可能意味著企業的容器有兩個機敏度。 一種是財務應用程式，資料庫包含在該組中。 另一個用於外部應用程序，官網包含在該組中。 企業在此案例中應該擁有VM pools，每個VM pool託管不同機敏度的容器。 例如，名為 vm-financial 的Host可以託管運行財務資料庫以及稅務報告的容器，而名為 vm-web 的主機可以託管官網。
通過以這種方式對容器進行分段，對於攻陷其中一個攻擊者來說，將這種危害擴展到其他區段將變得更加困難。 危害單一個server的攻擊者對具有相似機敏度的其他容器執行偵察和攻擊的能力有限，並且除此之外沒有任何其他存取權限。 此方法還確保任何殘留資料（例如為臨時檔案安裝的cache或local volumes）保留在資料的安全區域內。 從前面的例子來看，此分區將確保在容器終止後local cache和殘留的任何財務資料永遠不會在以較低機敏度運行應用程序的Host是存在的。
在具有上千主機和上萬個容器的大規模環境中，這種分段必須自動化才能切實可行。 幸運的是，常見的Orchestrator platform通常包含一些能夠將應用程式分組在一起的概念，並且容器安全工具可以使用容器名稱和標籤等屬性來在它們之間強制執行安全策略。 在這些環境中，除了簡單的主機隔離之外的其他縱深防禦也可以利用這種分段。 例如，企業可以實現單獨的託管區域或網路，不僅可以隔離hypervisors內的這些容器，還可以更離散地隔離其網路流量，以便一種機敏度的應用程式的流量與其他機敏度的應用程式的流量分開。
Orchestrator節點信任
維護環境中節點之間的信任需要特別小心。 Orchestrator是最基本的節點。 Orchestrator Configuration較弱可能會使Orchestrator和所有其他容器技術組件面臨更大的風險。 可能的後果有：
- 未經授權的主機加入Cluster並運行容器
- 單一cluster host的compromise意味著整個cluster的compromise — — 例如，如果用於身份驗證的相同密鑰對在所有節點之間共享
- Orchestrator與 DevOps 人員、管理員和主機之間的通訊未加密且未經身份驗證
反制措施
Orchestration platform應該是提供為其運行的所有應用程式建立安全環境的功能。 Orchestrator應確保節點被安全地加入Cluster，在其整個生命週期中具有身份可以被持續驗證，並且還可以提供節點及其連接狀態的正確清單。 企業應確保Orchestration platform經過專門設計，能夠抵禦單一節點的攻擊，而不會影響Cluster的整體安全性。 必須能夠將受感染的節點從Cluster中隔離並刪除，而不會中斷或降低整個cluster的運行。 最後，企業應該選擇能夠在Cluster member之間提供相互驗證的網路連接以及cluster內流量的端到端加密的Orchestrator。 由於容器的可移植性，許多部署可能發生在企業不直接控制的網路上，因此預設的安全態勢對於這種情況尤為重要。
容器風險
Runtime 軟體的弱點
雖然這種狀況很少見，但運行時軟體中的漏洞如果允許“container escape”場景（其中惡意程式可以攻擊其他容器和Host OS本身中的資源），則特別危險。 攻擊者還可能利用漏洞來破壞runtime software本身，然後變更該軟體，以便攻擊者能夠存取其他容器、監視容器之間的通訊等。
反制措施
企業必須仔細監控容器運行時是否存在漏洞，並且當偵測到問題時，必須快速修復。 易受攻擊的runtime會將其運作的所有容器以及主機本身暴露出潛在的重大風險。 企業應使用工具在部署的runtime中尋CVE(Common Vulnerabilities and Exposures)漏洞，升級任何有風險的instance，並確保Orchestrator只允許部署到有正確維護的Runtime。
容器不受限制的網路存取
預設情況下，在大多數container runtimes中，各個容器都能夠通過網路存取Host OS與相互存取。 如果容器遭到破壞並進行惡意行為，允許此網路流量可能會使環境中的其他資源面臨風險。 例如，已經被入侵的容器可用於掃描其所連接的網路，以便找到可供攻擊者利用的其他弱點。 這種風險與分離度不夠高的虛擬網路相關，如＂容器間網路流量分離不佳＂所述，但有所不同，因為它更關注從容器出發到任何出站目的地的網路流量，而不是應用程式之間“cross talk”的場景。
在容器化環境中管理出口網路存取更加複雜，因為容器之間的大部分連接都是虛擬化的。 因此，從一個容器到另一個容器的流量可能簡單地顯示為網路上的封裝資料包，而不直接顯示最終來源、目的地或payload。 不了解容器的工具和操作流程無法檢查此流量或確定它是否代表威脅。
反制措施
企業應控制容器的Egress network。 至少，這些控制措施應該在網路邊界是到位的，確保容器無法跨不同機敏度網路，例如從保存公司內部資料的環境到外部網路，類似於傳統架構使用的模式。 然而，容器間流量的virtualized networking model帶來了額外的挑戰。
由於部署在多個Host上的容器通常通過虛擬的加密網路進行通訊，因此傳統網路設備通常對這種流量看不到網路封包內容。 此外，容器在由Orchestrator部署時通常會自動分配動態 IP ，並且這些IP會隨著應用程式的擴展和負載平衡而不斷變化。 因此，理想情況下，企業應該結合使用現有的網路設備和app-aware network filtering。 App-aware工具不僅應該能夠看到容器間流量，還應該能夠根據容器中運行的應用程式的特定特徵動態產生用於過濾此流量的規則。 由於容器化應用程式的"規模和變化速度及其短暫的網路拓撲"，這種動態規則管理至關重要。
app-aware tools應該具有以下的功能:
- 自動地確認正確的容器網路架構，包括inbound ports 與process-port綁定
- 測容器和其他網路實體之間的流量，包括“on the wire”流量和encapsulated traffic
- 偵測網路異常，例如企業網路內的沒預期到的流量、port scanning或對潛在危險目的地的網路連結。
不安全的container runtime configurations
Container runtime通常向管理員顯示許多可配置選項。 設置不當會降低系統的相對安全性。 例如，在 Linux 容器主機上，預設情況下允許的system call通常僅限於容器安全操作所需的system call。 如果擴大這個list，可能會使容器和Host OS面臨容器被入侵帶來的更大風險。 同樣，如果容器在特權模式下運行，它就可以訪問主機上的所有設備，從而使其本質上充當Host OS的一部分，並影響在其上運行的所有其他容器。
不安全的運行時配置的另一個例子是允許容器在主機上掛載敏感目錄。 容器應該很少對HOst OS file system進行變更，並且幾乎永遠不應該對控制Host OS基本功能的位置進行修改（例如，對於 Linux 容器來說是 /boot 或 /etc，對於 Windows 容器來說是 C:\Windows）。 如果允許受感染的容器更改這些路徑，則它可以用於提升權限並攻擊主機本身以及主機上運行的其他容器。
反制措施
企業應該自動合規於container runtime configuration standards。 普遍使用的技術實施指南（例如CIS的Security Docker Benchmark）提供了有關選項和建議設定的詳細資訊，但該指南的實施取決於自動化。 企業可以使用各種工具在某個時間點“掃描”並評估其合規性，但此類方法無法擴展。 相反，企業應該使用能夠持續評估整個環境中的Configuration setting並積極實施的工具或流程。
此外，SELinux 和 AppArmor 等MAC(mandatory access control)技術為運行 Linux OS的容器提供強化的控制和隔離。 例如，這些技術可用於提供額外的分段並保證容器只能存取特定的檔案路徑、processes和network sockets，從而進一步限制即使是被入侵的容器也無法影響其底層的Host或其他容器。
Secure computing(seccomp) Profiles是另一種機制，可用於限制容器在runtime分配到的system-level capabilities。 Docker 等這種常見的container runtime會包含預設的 seccomp profile，這些profile會刪除不安全且通常對容器用不到的system calls。 此外，可以建立自custom profile並將其傳遞到container runtimer以進一步限制其功能。 至少，企業應確保容器使用其runtimer提供的預設profiles運作，並應考慮對高風險應用程式使用其他profiles。
應用程式的弱點
即使企業採取了NIST SP 800–190建議的預防措施，容器仍可能因其運行的應用程式中的漏洞而被入侵。 這不是容器本身的問題，而只是容器環境中典型軟體缺陷的表現。 例如，容器化 Web 應用程式可能容易受到vulnerable to cross-site scripting 漏洞的影響，資料庫前端容器可能會受到SQL injection的影響。 當容器被入侵時，它可能會以多種方式被濫用，例如授予對敏感資訊的未經授權的存取權限或對其他容器或Host OS進行攻擊。
反制措施
應用程式的弱點與前面討論的技術架構和運作實踐不同，現有的基於主機的入侵偵測流程和工具通常無法偵測和防止容器內的攻擊。 企業應該實施額外的container aware tool，並設計成以容器會展現的規模和變化率來運作。 這些工具應該能夠使用行為學習自動分析容器化應用程序，並為其構建安全配置文件，以最大限度地減少人為干預。 這些配置文件應該能夠在運行時"防止和偵測"異常，包括以下事件：
- 無效或預期外的Process execution
- 無效或預期外的system calls
- 對受保護的configuration file和binaries的更改
- 寫入預期外的位置和檔案類型
- 建立預期外的network listeners
- 發送到預期外的網路目的地的流量，以及
- 惡意軟體的存儲或執行
容器還應該以其root filesystems以read-only mode運作。 這種方法將write行為隔離到專門定義的路徑或檔案目錄，然後可以通過上述工具監控這些目錄。 此外，使用readl-only filesystems能容易抵抗攻擊，因為任何篡改都被隔離到這些特定位置，並且可以與應用程式的其餘部分分離。
惡意容器(Rouge Containers)
惡意容器是環境中未經計劃或未經批准的容器。 這可能很常見，尤其是在開發環境中，應用程式開發人員可能會啟動容器作為測試其代碼的方法。 如果這些容器沒有經過嚴格的漏洞掃描和正確配置，它們可能更容易受到攻擊。 因此，惡意容器會給企業帶來額外的風險，特別是當它們在開發團隊和安全管理員不知情的情況下持續存在於環境中時。
反制措施
組織應該為開發、測試、生產和其他場景建立單獨的環境，每個環境都具有特定的控制項，以便為容器部署和管理活動提供RBAC。 所有容器建立都應與個人使用者身份相關聯並進行記錄，以提供清晰的活動稽核。 此外，鼓勵企業使用安全工具，在允許運作Image之前強制執行漏洞管理和合規性的基本要求。
Host OS的風險
大面積的攻擊
每個Host OS都有一個攻擊面，它是攻擊者嘗試存取和利用Host OS漏洞的所有方式的集合。 例如，任何可通過網路存取的服務都為攻擊者提供了潛在的入口點，從而增加了攻擊面。 攻擊面越大，攻擊者找到並存取漏洞的可能性就越大，從而導致Host OS及其上運行的容器被入侵。
反制措施
對於使用特定於容器的OS的企業來說，威脅通常較小，因為OS是專門為託管容器而設計的，並且禁用了其他服務和功能。 此外，由於這些優化的OS是專門為託管容器而設計的，因此它們通常是有read-only system，並預設採用其他強化措施。 只要有可能，企業就應該使用這些簡化版的OS來減少攻擊面，並減輕在一般OS相關的典型風險和hardening activities。
無法使用特定於容器的OS的企業應遵循 NIST SP 800–123《Guide to General Server Security》中的指南，以盡可能減少其主機的攻擊面。 例如，運行容器的主機應該只運行容器，而不能運行容器外部的其他應用程式，也就是容器專用。 最後，應該持續掃描主機是否存在漏洞，並快速更新，不僅針對container runtime，還針對較低等級的組件，例如容器所依賴的安全、分區運作的kernel。
共享的Kernel
容器專用的OS的攻擊面比一般性OS小得多。 例如，它們不包含一班OS能夠直接運行資料庫和 Web 服務器應用程式的library和package manager。 然而，儘管容器提供了強大的軟體等級的資源隔離，但使用共享kernel總是會導致比hypervisors更大的inter-object攻擊面，即使對於特定於容器的OS也是如此。 換句話說，container runtime提供的隔離等級不如hypervisors提供的隔離等級高。
反制措施
除了按機敏度將容器工作負載分組到主機上之外，企業不應在同一主機上混合使用容器化和非容器化工作負載。 將容器化工作負載與特定於容器的主機隔離，可以更簡單、更安全地應用針對保護容器而優化的對策和防禦措施。
Host OS組件的弱點
所有的Host OS，甚至特定於容器的Host OS，都提供基礎系統組件，例如，用於驗證remote connection的cryptographic libraries以及用於一般process invocation和管理的kernel primitives。 與任何其他軟體一樣，這些組件可能存在漏洞，並且由於它們存在於容器技術架構的底層位置，因此可能會影響在這些主機上運行的所有容器和應用程式。
反制措施
企業應實施管理實踐和工具來驗證為Base Os management和功能提供的組件的版本控制。 儘管特定於容器的OS比一般OS具有更少的組件集，但它們仍然存在漏洞並且仍然需要修復。 企業應使用OS廠商或其他受信任組織提供的工具來定期檢查OS中使用的所有軟體組件並將其應用更新。 OS不僅應保持最新的安全更新，還應保持廠商推薦的最新組件更新。 這對於Kernel和容器運行時組件尤其重要，因為這些組件的新版本通常除了簡單地糾正漏洞之外還加入了額外的安全保護和功能。 一些企業可能會選擇重新部署具有必要更新的Host OS，而不是更新現有系統。 這種方法也是有效的，儘管它通常需要更複雜的運作實踐。
Host OS應該以immutable的方式運作，沒有資料或狀態唯一且持久地存儲在Host上，並且Host不提供application-level dependencies。 相反，所有應用程式組件和dependencies都應打包並部署在容器中。 這使得Host能夠以近乎stateless的方式運行，並大大減少攻擊面。 此外，它還提供了一種更值得信賴的方法來識別異常和configuration drift。
不正確的使用者存取權限
特定於容器的OS通常不會針對支援multiuser的場景進行優化，因為交interactive user logon應該很少見。 當使用者直接登錄到Host來管理容器而不是通過Orchestrator時，企業就會面臨風險。 直接的主機管理可以對系統及其上的所有容器進行廣泛的變更，並且有可能使用者只需要管理特定應用程式的容器即可影響許多其他應用程式的容器。
反制措施
儘管大多數容器部署依賴Orchestrator跨主機的分配工作，但企業仍應確保對OS的所有身份驗證進行稽核，監控登錄異常，並記錄執行特權操作的任何升級。 這使得識別異常存取模式成為可能，例如個人直接登錄到主機並運行特權命令來操作容器。
Host OS file system的竄改
不安全的容器配置可能會使host volumes面臨更大的檔案篡改風險。 例如，如果允許容器在Host OS上掛載敏感目錄，則該容器可以修改這些目錄中的檔案。 這些修改可能會影響主機及其上運行的所有其他容器的穩定性和安全性。
反制措施
確保容器以所需的最小的filesystem權限集運行。 容器很少會在主機上掛載local file systems也不應該這麼做。 相反，容器需要任何持久性資料的寫入或修改都應該在專門為此目的分配的volume中進行。 企業應該使用可以監視容器正在掛載哪些目錄的工具，並防止部署違反這些政策的容器。
