NIST SP 800–190 Part 1容器簡介

Application Container Security指南

運用雲端服務加速企業數位轉型

25 min readAug 1, 2023

虛擬化的出現讓企業可以在每一個OS只安裝一個應用程式，讓它們是互相隔離不會彼此干擾 — 也就是本文的重點：容器(Container)。OS虛擬化技術重點在於封裝與運作應用程式可以產生＂可移植、可重複使用與自動化＂。

NIST SP 800–190介紹的是在使用容器技術時所產生的資安議題，並且提供當我們在＂設計、實行與維護＂容器時，一些實用的建議來解決這些議題。許多建議都是當我們在使用容器架構時針對特定的組件或層級(如下圖)。

企業可以使用以下的建議來確認容器的實行與使用的安全：

客制組織的維運文化和技術流程，以支援容器的開發、運作和應用程序的新方法。

新方法一定會對企業帶來一些對既有文化與軟體開發方法的一些破壞。重點在於現有的員工是否能適應這些新方法，這就會是關於成員、團隊的激勵，與領導者的能力有關。另外企業也必須思考再三，這個現有的程序是否可以得到運用容器的優勢。在整個開發流程中，企業需要對員工的心態、技術、維運的方法做出整體的改變。以下是NIST SP 800–190的幾點安全建議:

1.使用容器專用的Host OS而非通用型的，以減少攻擊面積

所謂容器專用的OS是指 — 該OS將去除所有運作容器不需要的服務或功能，並且file system是”read-only”另外加上一些資安強化的實踐。因為這麼做攻擊面積將會減少，引此受攻擊的機會也將減少。相應的，資安風險也減少了。不過隨著時間的流逝，Host OS終究還是有可能產生弱點，我們需要隨時修補它。

然而這在公有雲上使用PaaS的容器服務卻是我們不需要關心的。因為雲端平台業者比我們更緊張它們的資安，他們隨時隨地都在注意這一塊。企業使用這一類公有雲服務可以大幅降低其底層的管理。

2.僅將具有相同用途、敏感性和威脅態勢的容器分組在一群具有相同的OS Kernel上，以實現額外的縱深防禦

雖然容器管理平台(如K8S)可以很好的將容器與底層的OS解偶，但它不會知道當我們把不同功能的app(容器)放在同一個相同的OS運作時，可能會產生不必要的風險。因為不同功能的容器所運行的資料可能有著不同的機敏度。我們需要根據容器的目的、機敏度與威脅態勢進行切分(Segmenting)以實現縱深防禦。

在具有上千個Host和上萬個容器的大規模環境中，這種分組必須自動化才能實際運作。幸運的是，容器技術通常包含一些能夠將應用程式分組在一起的概念(如下label)，並且容器安全工具可以使用容器名稱和標籤等屬性來在它們之間實行資安政策。

3.對容器的Images採用特定於容器的漏洞管理工具和流程以防止被竄改

傳統的漏洞掃描工具對主機存續時間和應用程式update的機制和頻率做出了許多假設，這些假設從本質上與容器化模型不一致。例如，它們通常假設特定的server隨著時間的推移運行一套一致的應用程式，但根據資源可用性，不同的功能的容器實際上可能在任何特定時間在不同的server上運作。此外，傳統工具通常無法偵測容器內的漏洞，從而導致錯誤的安全感。組織應該使用將"宣告式、逐步構建方法以及容器和Images的不可變性質"納入其設計的工具，以提供更具可操作性和可靠性的結果。

這些工具和流程應考慮Image中軟體漏洞和配置。組織應採用工具和流程來驗證和強制遵守Images安全配置最佳實踐。這應包括集中報告和監控每個Images的合規狀態。

4.考量使用基於硬體的反制措施為可信任的運算提供基礎

安全性應該擴展到容器技術的所有層面。當前實現此目的的方法是將安全性建立在信任硬體上，例如產業標準TPM(Trust Platform Module)。 Hardware root of trust中存儲了主機的fireware、軟體和配置資料的測量結果。 在啟動主機之前對照存儲的測量值驗證當前測量值可確保主機是受信任的。 Root於硬體的trust chain可以擴展到OS Kernel和OS組件，以實現啟動機制、system images、container runtime時和container image的加密驗證。此方法提供了一種"構建(build)、運行(run)、編排(orchestrate)和管理(manage)"容器的安全方法。

5.使用能感知容器在運作時的防禦工具

部署和使用專用的容器安全解決方案，能夠在運行時預防、偵測和回應針對容器的威脅。傳統的安全解決方案，例如IPS) 和 WAF，通常無法為容器提供適當的保護。他們可能無法以容器的規模進行運作、管理容器環境的變化率以及了解容器活動。利用容器原生安全解決方案來監控容器環境並精確偵測其中的異常和惡意活動。

容器的簡介

本節將介紹運行在server中的應用程序容器。首先，它定義了理解本文其他部分所需的應用程式虛擬化(Application virtualization)和容器的基本概念。接下來，本節介紹容器如何與其運行的OS交互。我們還會說明了容器技術的整體架構，定義了容器實現中常見的所有主要組件，並解釋了組件之間的工作流程。本節的最後一部分描述了容器的常見用途。

應用程式虛擬化與容器的基本概念

NIST SP 800–125定義了虛擬化是 — 其他軟體運行的軟體和(或)硬體的模擬。虛擬化已經存在非常多年了，但它也是雲端運算的核心。在雲端環境，硬體虛擬化是被用來在單一台實體機上運作需多OS instance但它們同時也是狀態分離的技術。這麼做的用意是將硬體的使用效率最大化。

在硬體虛擬化中，每個OS insatnce都與虛擬化硬體交互。另一種形式的虛擬化稱為OS虛擬化，具有類似的概念。它在單個實際OS Kernel之上提供多個虛擬化OS。這種方法通常稱為OS Container，自 2000 年代初期以來，OS Container的各種實作就已經存在，從 Solaris Zone 和 FreeBSD Jails 開始。 Linux 最初於 2008 年提供支援，幾乎所有現代發行版都內置了 Linux Container (LXC) 技術。 OS Container與NIST SP 800–190要介紹的不同，因為OS Container旨在提供一個行為非常類似於普通OS的環境，多個應用程式和服務可以在其中共存。

近年來，應用程式虛擬化(也就是Container)由於其易用性的進步以及對開發人員敏捷性作為主要優勢而逐漸變成了主流。在應用程式虛擬化中，同一個共享的OS Kernel實際上讓給多個離散的應用程式進行運作。 OS組件使每個app instance與server上的所有其他app insatnce隔離。在這種情況下，每個應用程式只能看到OS及其自身，並且與可能在同一個OS Kernel上運行的其他應用程式是隔離的。

OS虛擬化和應用程式虛擬化之間的主要區別在於，使用應用程式虛擬化時，每個vurtual instance通常只運行一個應用程式。當今的應用程式虛擬化技術主要致力於提供一種"可移植、可重複用且可自動化"的方式來打包和運行應用程式。術語“application container”或簡稱“container”經常用於指代這些技術。

與傳統的應用程式架構不同，傳統的應用程式架構通常將應用程式劃分為幾個tier（例如，Web、application和DB），並且每個tier都有一個server(或VM)，而容器架構通常將一個應用程式劃分為更多組件，每個定義明確的函數都有一個單獨的組件。每個應用程式組件都在獨立的容器中運行。在應用程式容器技術中，共同組成應用程式的容器集稱為微服務。通過這種方法，應用程式部署更加靈活和可擴展。由於功能更加獨立，開發也更加簡單。然而，這樣會變成有很多的物件需要管理和保護，這可能會給應用程式管理以及安全工具和流程帶來問題。

大多數應用程序容器技術都實現了不變性(immutability)的概念。換句話說，容器本身應作為部署但不更改的無狀態實體進行運作。當正在運行的容器需要升級或更改其內容時，只需將其銷毀並替換為具有更新的新容器。這使得開發人員和維運人員能夠以更快的速度對應用程序進行更改和推送。 不變性是容器和硬體虛擬化之間的根本運作差異。傳統VM通常作為有狀態(Stateful)實體運行，並在其整個生命週期中進行部署、重新配置和升級。傳統的安全工具和流程通常主要採用靜態運作，可能需要進行調整以適應容器化環境的變化率。

容器的不變性也對資料持久性(Data persistence)產生影響。容器強調隔離的概念，而不是將應用程式與其使用的資料混合在一起。資料持久性不應通過簡單寫入容器的root file system來實現，而應通過使用外部持久性資料存儲（例如DB或cluster-aware persistent volumes，如NFS）來實現。容器使用的資料應存儲在容器本身之外，以便當應用程式的下一個版本替換運行現有版本的容器時，所有資料仍然可供新版本使用。

現代容器技術在很大程度上是隨著DevOps實踐的採用而出現的，這些實踐旨在提高構建和運行應用程式之間的整合，強調開發和維運團隊之間的密切協調。容器的可移植性和宣告特性尤其適合這些實踐，因為它們允許組織在開發、測試和生產環境之間能有"高度的一致性"。組織通常利用CI流程，在構建流程本身中直接將其應用程式放入容器中，這樣從應用程式生命週期的一開始，就可以保證其運行時環境的一致性。 Container Image（包含運行容器所需的檔案的package）通常被設計為可橫跨機器和環境移動，因此在開發中建立的image可以容易移動到測試環境進行評估，然後復製到生產環境中無需進行任何修改即可運行。 這樣做的缺點是，用於保護容器的安全工具和流程不應該對特定的雲服務商、主機OS、網路拓撲或可能經常變化的容器運行時環境的其他方面做出假設。 更重要的是，安全性應該在所有這些環境以及從開發到測試再到生產的整個應用程式生命週期中保持一致。

容器與Host OS

將應用程式在容器內的部署與佈署在VM內的應用程式進行比較，可以更容易地解釋容器內應用程式的部署。下圖左側顯示了VM部署，中間顯示了沒有VM（安裝在“bare metal”上）的容器部署，右側顯示了在VM內運行的容器部署。

VM和容器都允許多個應用程式共享相同的物理基礎設施，但它們使用不同的隔離方法。 VM 使用VM管理程序提供跨 VM 的硬體等級的資源隔離。每個VM都有自己的虛擬硬體組件，除了應用程式及其資料之外，還包括完整的guest OS。 VM 允許不同的OS（例如 Linux 和 Windows）共享相同的實體機氣。

使用容器，多個應用程式共享相同的OS Kernel Insatnce，但彼此隔離。 OS Kernel是Host OS的一部分。 Host OS位於容器下方，並向容器提供OS功能。不同類類型的容器運作在不同類型的OS的； Linux 主機只能運行為 Linux 構建的容器，Windows 主機只能運行 Windows 容器。此外，為一個OS系列構建的容器應該在該系列的任何最新OS上運作。

用於運行容器的Host OS有兩大類。 Red Hat Enterprise Linux、Ubuntu 和 Windows Server 等通用OS可用於運行多種應用程式，並且可以加入特定於容器的功能。特定於容器的OS，例如 CoreOS Container Linux、Project Atomic 和 Google Container-Optimized OS 是專門設計用於只能運行容器的極簡OS。它們通常不附帶package manage，它們只有core adminstration tools的子集，並且它們積極防止在容器之外運行應用程式。通常，特定於容器的OS使用real-only file system設計來降低攻擊者能夠在其中保留資料的可能性，並且它還利用簡化的升級過程，因為幾乎不擔心應用程式的兼容性。

用於運行容器的每個Host OS都有為每個容器建立和維護環境的binaries，也稱為container runtime。 container runtime協調多個OS組件，這些組件隔離resource和resource usage，以便每個容器只能看到自己專用的OS，並與同時與其他運行的容器隔離。 實際上，容器和Host OS通過container runtime進行交互。 Container runtime還提供管理工具和 API，允許 DevOps 人員和其他人員指定如何在特定主機上運行容器。運行時無需手動建立所有必要的配置，並簡化了啟動、停止和操作容器的過程。運行時的instance包括 Docker、rkt 和 Open Container Initiative Daemon。

Container runtime確保Host OS提供的技術功能範例包括：

Namespace isolation限制容器可以與哪些資源交互。這包括file systems, network interfaces, interprocess communications, host names, user information, 與processes。 Namespace isolation可確保容器內的應用程序和processes只能看到分配給該容器的實體和虛擬資源。例如，如果我們在Host上運行 Apache 的容器內運行“ps –A”，而Host上還有許多其他容器運行其他應用程式，則我們只會看到processes中列出 httpd。 Namespace isolation為每個容器提供了自己的networking stack，包括唯一的interface和 IP 地址。 Linux 上的容器使用masked process identities等技術來實現Namespace isolation，而在 Windows 上則使用object namespaces。
Resoruce allocation限制了特定容器可以消耗的主機資源量。例如，如果Host OS有 100 GB memory，我們可能希望為 90 個單獨的容器各分配 1 GB。任何容器都不能干擾另一個容器的運作，因此資源分配確保每個容器只能使用分配給它的資源量。在 Linux 上，這主要通過cgroup 來完成，而在 Windows 上，job objects具有類似的作用。
Filesystem Virtualization 允許多個容器共享相同的實體存儲，而無需存取或更改其他容器的存儲。雖然可以說與namespace類似，但Filesystem Virtualization是單獨提出的，因為它通常還涉及優化，以確保容器通過copy-on-write等技術有效地使用主機的存儲。例如，如果使用同一Images的多個容器在一台主機上運行 Apache，則Filesystem Virtualization可確保硬碟上只存儲 httpd binary的一份副本。如果其中一個容器修改了自身內部的檔案，則只有特定變更的位元(bit)才會寫入disk，並且這些變更只有對執行它們的容器可以看到。在 Linux 上，這些功能由AUFS(Advanced Multi-Layered Unification Filesystem)等技術提供，而在 Windows 上，它們是 NTFS的擴展。

容器的技術能力因Host OS而異。 從根本上講，容器是一種為每個應用程式提供單一OS的獨特視圖的機制，因此實現這種分離的工具在很大程度上依賴於不同OS。例如，Linux 和 Windows 之間用於相互隔離processes的方法是不同的。然而，雖然底層實現可能不同，但常用的container runtime提供了一種通用的介面格式，很大程度上從使用者那裡抽像出了這些差異。

雖然容器提供了很強的隔離性，但它們無法提供像VM那樣清晰具體的安全邊界。 由於容器共享相同的內核，並且可以在Host上以不同的功能和權限運行，因此它們之間的segmentation程度遠遠小於VM的hypervisor為VM提供的segmentation程度。因此，不僅慎配置的環境可能會導致容器能夠比同一Host上的多個VM更容易、更直接地交互以及與Host交互。

儘管容器有時被認為是虛擬化的下一階段，超越硬體虛擬化，但對於大多數企業來說，現實與其說是革命，不如說是演進。容器和硬體虛擬化不僅可以很好地共存，並且實際上可以增強彼此的功能。 VM提供了許多效益，例如強大的隔離性、OS自動化以及廣泛而深入的解決方案生態系統。企業不需要在容器和VM之間做出選擇。相反，企業可以繼續使用VM來部署、隔離和管理其硬體，同時使用容器來打包其應用程式並更有效地利用每個VM。

容器技術架構

下圖為容器技術架構的5個tiers.

開發人員（產生images並將其發送至測試和認證）
測試和認證（驗證images內容、簽署images並將images發送到registries）
Registries（存儲images並根據請求將images分發給orchestrator）
Orchestrator（將images轉換為容器並將容器部署到Host）
Host（按照orchestrator的指示運行和停止容器）

上圖的灰色部分（開發者、測試認證、管理員）不屬於容器技術架構的範圍，但它們確實與容器技術架構有重要的交互。在大多數使用容器的企業中，開發和測試環境也利用容器，這種一致性是使用容器的主要效益之一。 NIST Sp 800–190不聚焦這些環境中的灰色部分，因為保護它們的建議與生產環境的建議基本相同。綠色部分（(internal registry, external registry, orchestrator）是容器技術架構的核心組件。最後，橙色系統（帶有容器的Host）是使用容器的地方。

理解容器技術架構的另一種方法是考慮容器生命週期階段，如上圖底部所示。下面將更詳細地討論這三個階段。

由於企業通常會同時構建和部署許多不同的應用程式，因此這些生命週期階段通常在同一企業內同時發生，不應被視為成熟的漸進階段。相反，請將它們視為連續運行的engine(引擎)中的循環。在這個比喻中，每個應用程序都是引擎內的一個汽缸，不同的應用程式可能同時處於該生命週期的不同階段。

1.Image Creation, Testing, and Accreditation
在容器生命週期的第一階段，應用程式的組件被構建並放置到一個image中（或者可能放置到多個image）。 image是一個package，其中包含運行容器所需的所有檔案。例如，運行 Apache 的image將包含 httpd binary以及相關的library和configuration file。 Image應該只包含應用程式本身所需的可執行文件和library；所有其他OS功能均由底層Host OS內的OS Kernel提供。 Image通常使用layering和copy-on-write（其中共享master image是read-only的，更改記錄是存在於單獨的檔案中）等技術來最小化其在Disk上的大小並提高運作效率。

由於Image是分層構建的，因此加入所有其他組件的底層通常稱為base layer。 Base Layer通常是常見OS（例如 Ubuntu 和 Windows Nano Server）的簡化版，省略了OS Kernel。我們(使用者)開始構建完整的image，首先從這些base layer之一開始，然後加入應用程式框架和自己的代碼來開發其獨特應用程式的完全可部署的image。 Container runtime支援使用同一種OS中的Image，即使特定Host OS版本不同也是如此。例如，運行 Docker 的 Red Hat 主機可以運行在任何 Linux base layer（例如 Alpine 或 Ubuntu）上建立的Image。但是，它無法運行使用 Windows base layer建立的Image。

Image建立過程由負責打包應用程式以移交測試的開發人員管理。 Image建立通常使用構建管理和自動化工具（例如 Jenkins 或GitLab）來協助所謂的“CI”過程。這些工具獲取應用程式的各種library、binary和其他組件，對它們執行測試，然後根據開發人員建立的清單（描述如何為應用程式建立image）從建立Image。

大多數容器技術都採用宣告式方法來描述應用程式的組件和要求。例如，Web server的image不僅包括 Web server的可執行檔案，還包括一些機器可解析的資料來描述 Web server應如何運行，例如它listening port或它使用的配置參數。

建立Image後，企業通常會執行測試和認證。例如，測試自動化工具和人員將使用建立的Image來驗證最終形式的應用程序的功能，而資安團隊將對這些相同的image執行認證。 為應用程式構建、測試和認證完全相同的工件(artifacts)的一致性是容器的關鍵運作和安全效益之一。

2. Image Storage and Retrieval
Image通常存儲在一個集中的位置，以便於可以橫跨Host的控制、共享、尋找和重複使用它們。 Registries是允許開發人員能容易存儲Image、標記和編目Image以進行識別和版本控制以幫助尋找和重複使用以及下載其他人建立的Image的服務。 Registries可以使用雲端的服務。範例包括 Amazon EC2 container registry、Docker Hub、Docker Trusted Registry。

Registries提供 API，可自動執行常見的Image相關作業。例如，企業可能在Image建立階段有觸發器，一旦測試通過，就會自動將Image推送到registry。 Registry可能還有進一步的觸發器，可以在加入新的image後自動部署新的image。這種自動化可以更快地迭代專案，並獲得更一致的結果。

一旦存儲在registry中，DevOps 人員就可以容易提取並在能運行容器的任何環境中運行image。這是容器可移植性優勢的另一個例子； Image建立可能發生在公有雲服務商中，該服務商將image推送到私有雲中託管的registry，然後使用該registry來分發image以在第三個位置運行應用程式。

3.Container Deployment and Management
稱為Orchestrators的工具使 DevOps 人員或類似的自動化工作能夠從Regisrty中提取Image，將這些Image部署到容器中，並管理正在運行的容器。 此部署過程實際上會產生應用程式的可用版本，運行並準備好回應請求。 將Image部署到容器中時，Image本身不會更改，而是將其副本放置在容器中，並從休眠的應用程式代碼集轉換為應用程式的running instace。 Orchestrators的平台包括 Kubernetes、Mesos 和 Docker Swarm。

請注意，小型、簡單的容器平台(例如K3S)可能會省略成熟的Orchestrators。在其他情況下，Orchestrators也可能被規避。例如，Host可以直接聯繫registry，以便從其中提取容器運行時的Image。

Orchestrators提供的abstraction允許 DevOps 人員簡單地指定需要運行特定Image的容器數量以及需要為每個容器分配哪些資源，例如memory、precessing和disk。 Orchestrators了解cluster中每個Host的狀態，包括每個Host可用的資源，並確定哪些容器將在哪些Host上運行。然後，Orchestrators從regisrty中提取所需的Image，並將它們作為具有指定資源的容器運行。

Orchestration平台還負責跨Host監控容器資源消耗、作業執行和機器運行狀況。根據其配置，如果最初運行的Host出現故障，Orchestration可能會自動在新Host上重新啟動容器。許多Orchestration支援跨Host容器網路和service discovery服。大多數Orchestration還包括一個SDN組件，稱為overlay network，可用於隔離共享同一實體網路的應用程式之間的通訊。

當容器中的應用程式需要更新時，現有容器不會更改，而是會被銷毀，並根據更新的Image建立新容器。 這是容器的一個關鍵的運作差異：初始部署的software baseline不應隨著時間的推移而改變，並且更新是通過立即替換整個Image來完成的。這種方法具有顯著的潛在安全優勢，因為它使企業能夠在每個階段以完全相同的配置構建、測試、驗證和部署完全相同的軟體。當應用程式更新時，企業通常可以利用Orchestrator來確保使用最新版本。 Orchestrator 通常配置為從registry中取得最新版本的Image，以便應用程式始終是最新的。這種“CD”自動化使開發人員能夠簡單地為其應用程式構建新版本的Image、測試Image、將其推送到Registry，然後依靠自動化工具將其部署到目標環境。

這意味著所有弱點管理（包括patches和configuration setting）通常由開發人員在構建新image版本時負責。對於容器，開發人員主要負責應用程式和Image的安全性，而不是維運團隊。這種職責的變化往往需要人員之間比以前更多的協調與合作。

"採用容器的企業應確保為每個利害關係人群體建立明確的流程和團隊職責。"

容器管理包括安全管理和監控。然而，為非容器環境設計的安全控制通常不太適合與容器一起使用。例如，考慮考慮 IP 地址的安全控制。這對於靜態 IP 地址幾百年不變的VM和bare metal非常有效。相反，容器通常由Orchestrators分配 IP 地址，並且由於容器的建立和銷毀比VM更加頻繁，因此這些 IP 地址也會隨著時間的推移而頻繁變化。這使得使用依賴於靜態 IP 地址的安全技術（例如基於 IP 地址過濾流量的防火牆規則）來保護容器變得困難或不可能。此外，容器網絡路以包括同一節點上、跨不同節點甚至跨雲端平台的容器之間的通訊。

容器的使用

如同其他先進技術一樣，容器技術不是萬靈丹，可以對應所有的技術場景。例如，企業現行使用一套古老的ERP套裝軟體，這就不太可能企業自行進行容器化技術。因為原始的廠商可能已經倒閉或是該套軟軟體早已不再支援。不過以下的一些案例則是使用容器技術的案例：

敏捷開發，應用程式會經常更新和部署。容器的可移植性和宣告性使得這些頻繁的更新具有效能且更易於測試。這使得企業能夠加速創新並更快地交付軟體。這還可以修復應用程序代碼中的漏洞，並更快地測試和部署更新的軟體。
環境的一致性和切分，開發人員可以擁有相同但獨立的環境來構建、測試和運作應用程式。容器使開發人員能夠在自己的電腦上運行生產應用程序的完整副本，去除了在一個完整環境中的協調和共享測試的需求，並消除了老舊測試環境的麻煩。
“橫向擴展(scale out)”場景，其中應用程式可能需要根據特定的時間點的負載快速部署或停用許多new instance。容器的不變性使得可靠地擴展insatnce變得更加容易，因為知道每個instance都與其他所有instance完全相同。此外，由於容器通常是stateless的，因此當不再需要它們時更容易停用它們。
雲原生應用程式，開發人員可以從一開始就構建微服務架構，確保更高效的應用程序迭代並簡化部署。

容器還有額外的效益；例如，由於container image的不可變特性，它們可以提高構建pipeline的效率。容器改變了生產環境的代碼安裝的時間和地點。在非容器系統中，應用程式安裝發生在生產環境中（即在server正在運作時），通常通過run人工編寫的腳本來管理應用程序代碼的安裝。這意味著在pre-production build pipeline中運行的任何測試都不是測試實際的生產工件，而是測試build system中包含的最佳猜測近似值。隨著時間的推移，這種對生產的近似值往往會偏離生產，特別是在管理生產和構建系統的團隊不同的情況下。這個場景就是“它可以在我的機器上運行但可能無法在生產環境運作”問題的體現。

通過容器技術，build system將應用程式安裝在它建立的Image中（即在編譯時）。該Image是應用程式的所有userspace requirements（即programming language runtime, dependent third-party libraries, init scripts, 與OS tools）的immutable snapshot。在生產環境中，只需下載並運行build system構建的container image。這解決了“它可以在我的機器上運行但可能無法在生產環境運作”的問題，因為開發人員、build system和生產環境都運行相同的不可變工件(immutable artifact)。

現代容器技術通常還強調重複使用(reuse)，這樣由一個開發人員建立的container image可以很輕易地由同一間企業內或其他團隊的其他開發人員共享和resue。 Registry service提供集中式的images共享和discovery service。這種易用性也導致主流的軟體廠商和專案使用容器來讓客戶輕鬆找尋並快速運行廠商的軟體。此外，由於容器運行時將容器彼此以及Host OS隔離，因此這些應用程式可以更安全可靠地運行，企業不必擔心它們會干擾底層Host OS。