保護 Windows 容器
適用於：Windows Server 2025、Windows Server 2022、Windows Server 2019、Windows Server 2016
容器的映像大小之所以縮減，是因為它們可以依靠主機來限制訪問各種資源。 如果容器知道主機將能夠提供執行特定動作集所需的功能，則容器不需要在其基底映像中包含相關的軟體。 不過，發生的資源分享範圍可能會對容器的效能和安全性產生重大影響。 如果共用太多資源，則應用程式可能也會像主機上的進程一樣執行。 如果資源分享太少，則容器會變得無法從 VM 中區分。 這兩個組態都適用於許多案例，但大部分使用容器的人通常會選擇中間專案。
Windows 容器的安全性取決於它與主機的共用程度。 容器的安全性界限是由將容器與主機分開的隔離機制所構成。 最重要的是，這些隔離機制會定義容器中的哪些進程可以與主機互動。 如果容器的設計允許提升許可權的 （admin） 程式與主機互動，則Microsoft不會將此容器視為具有強固的安全性界限。
Windows Server 容器與 Linux 容器
進程隔離的 Windows Server 容器和 Linux 容器會共用類似的隔離程度。 針對這兩種容器類型，開發人員必須假設任何可透過主機上提升許可權進程執行的攻擊，也可以透過容器中的提升許可權進程來執行。 兩者都透過各自主機核心所提供的基本功能運作。 容器映像的建置包含利用主機核心所提供 API 的使用者模式二進位檔。 主機核心會將相同的資源隔離和管理功能提供給在用戶空間中執行的每個容器。 如果核心遭到入侵，則每個容器都會共用該核心。
Linux 和 Windows 伺服器容器的基本設計可讓安全性獲得彈性。 Windows Server 和 Linux 容器建置在 OS 所提供的基本元件之上。 這樣做可提供在容器之間共用資源和命名空間的彈性，但它會增加額外的複雜性，以開啟惡意探索的大門。 廣義來說，我們不認為內核是惡意的多租戶工作負載的足夠安全邊界。
使用 Hypervisor 隔離的容器進行核心隔離
Hypervisor 隔離的容器提供比進程隔離的 Windows Server 或 Linux 容器更高的隔離程度，而且被視為健全的安全性界限。 Hypervisor 隔離的容器是由封裝在輕量級虛擬機內的 Windows Server 容器所組成，然後透過 Microsoft 的 Hypervisor 與宿主作業系統並行運行。 Hypervisor 提供硬體層級隔離，其中包含主機與其他容器之間的高度強固安全性界限。 即使漏洞若逸出 Windows Server 容器，它也會被限制在 Hypervisor 隔離的虛擬機內。
Windows Server 容器或 Linux 容器都未提供Microsoft認為強固的安全性界限，不應用於惡意的多租使用者案例。 容器必須受限於專用 VM，以防止流氓容器進程與主機或其他租用戶互動。 Hypervisor 隔離技術可達到如此程度的分離，同時相較於傳統的 VM 提供多項效能提升。 因此，強烈建議在惡劣的多租戶場景中，應選擇 Hypervisor 隔離容器作為首選容器。
容器安全性維護準則
Microsoft 致力於修補所有會破壞任何 Windows 容器類型的既定隔離界限的漏洞和逃逸方法。 不過，只有違反安全性界限的惡意探索會透過Microsoft安全性回應中心 （MSRC） 程式提供服務。 只有 Hypervisor 隔離的容器提供安全性界限，而進程隔離的容器則不會。 產生進程隔離容器逸出 Bug 的唯一方法是，如果非系統管理員進程可以取得主機的存取權。 如果惡意探索使用系統管理程式來逸出容器，則Microsoft會將其視為非安全性錯誤，並且會根據一般維護程序進行修補。 如果惡意探索使用非系統管理員程式來執行違反安全性界限的動作，則Microsoft會根據 建立的安全性服務準則來調查它。
多租戶工作負載為何敵意重重？
當多個工作負載在共享的基礎設施和資源上運行時，就會存在多租戶環境。 如果無法信任在基礎結構上執行的一或多個工作負載，則多租用戶環境會被視為敵意。 Windows Server 和 Linux 容器都會共用主機核心，因此在單一容器上執行的任何惡意探索都可能會影響在共用基礎結構上執行的其他所有工作負載。
您可以採取步驟來減少漏洞利用發生的機會，例如，使用 Pod 安全政策、AppArmor 和角色型存取控制（RBAC），但對攻擊者不會提供絕對的保護。 我們建議您在任何多租戶環境中遵循 叢集隔離 的最佳做法。
使用 ContainerAdmin 和 ContainerUser 使用者帳戶的時機
Windows Server 容器提供兩個預設用戶帳戶 ContainerUser 和 ContainerAdministrator，每個帳戶都有自己的特定用途。 ContainerAdministrator 帳戶可讓您將容器用於系統管理用途：安裝服務和軟體（例如在容器內啟用 IIS）、進行設定變更，以及建立新的帳戶。 這些工作對於一些可能在自定義內部部署部署環境中執行的IT案例而言很重要。
ContainerUser 帳戶存在於不需要 Windows 中系統管理員許可權的所有其他案例中。 例如，在 Kubernetes 中，如果使用者是 ContainerAdministrator，而且允許將主機卷掛接至 Pod，則使用者可以掛接 .ssh 資料夾並新增公鑰。 因為 ContainerUser 這個範例是不可能的。 這是專為不需要與主機互動的應用程式所設計的受限用戶帳戶。 強烈建議，在將 Windows 伺服器容器部署到任何多租用戶環境時，請確保您的應用程式通過 ContainerUser 帳戶執行。 在多租用戶環境中，最好遵循最低許可權原則，因為如果攻擊者入侵您的工作負載，則共用資源和鄰近工作負載也有較低的影響機會。 使用 ContainerUser 帳戶執行容器可大幅降低整個環境遭到入侵的機會。 不過，這仍然無法提供強健的安全界限，因此當安全性是個問題時，您應該使用 Hypervisor 隔離的容器。
若要變更使用者帳戶，您可以在 dockerfile 上使用 USER 語句：
USER ContainerUser
或者，您可以建立新的使用者：
RUN net user username ‘<password>’ /ADD
USER username
Windows 服務
Microsoft Windows 服務，先前稱為 NT 服務，允許您建立可在各自的 Windows 會話中長時間運行的可執行應用程式。 當操作系統啟動時，可以自動啟動這些服務、可以暫停和重新啟動，而且不會顯示任何使用者介面。 您也可以在與登入使用者或預設電腦帳戶不同的特定用戶帳戶的安全性內容中執行服務。
當容器化和保護以 Windows 服務身分執行的工作負載時，有一些其他考慮需要注意。 首先，容器的 ENTRYPOINT 不會是工作負載，因為服務是以背景進程的形式執行，通常 ENTRYPOINT 會是 服務監視器）或 記錄監視器之類的工具。 其次，工作負載運作的安全性帳戶將由服務設定，而不是由 dockerfile 中的 USER 指示詞所設定。 您可以執行 Get-WmiObject win32_service -filter "name='<servicename>'" | Format-List StartName，以檢查服務將在什麼帳戶下運行。
例如，當使用包含 ASP.NET 的 (Microsoft Artifact Registry) 映像檔裝載 IIS Web 應用程式時，容器的 ENTRYPOINT 是 "C:\\ServiceMonitor.exe", "w3svc"。 此工具可以用來設定 IIS 服務，並且在監控服務的過程中確保它持續運行。如果該服務因任何原因停止運行，工具會結束並停止容器。 根據預設，IIS 服務，因此 Web 應用程式會在容器內的低許可權帳戶下執行，但服務監視工具需要系統管理許可權來設定及監視服務。