保护 Windows 容器
适用于：Windows Server 2025、Windows Server 2022、Windows Server 2019、Windows Server 2016
容器之所以其映像大小减少，是因为它们可以依赖主机提供对各种资源的有限访问。 如果容器知道主机能够提供执行特定操作集所需的功能，则容器无需在其基础映像中包含相关软件。 但是，发生的资源共享程度可能会对容器的性能和安全性产生重大影响。 如果共享的资源过多，则应用程序也可以作为进程在主机上运行。 如果资源共享太少，则容器与 VM 不区分。 这两种配置都适用于许多方案，但大多数使用容器的人通常选择中间的内容。
Windows 容器的安全性派生自与主机共享的程度。 容器的安全边界由隔离机制构成，这些隔离机制将容器与主机分开。 最重要的是，这些隔离机制定义容器中的哪些进程可以与主机交互。 如果容器的设计允许提升的（管理员）进程与主机交互，则Microsoft不认为此容器具有可靠的安全边界。
Windows Server 容器与 Linux 容器
进程隔离的 Windows Server 容器和 Linux 容器共享类似的隔离度。 对于这两种容器类型，开发人员必须假定可以通过主机上提升的进程执行的任何攻击也可以通过容器中的提升进程执行。 两者都通过各自的主机内核提供的基元功能运行。 容器映像生成时包含了用户模式下的二进制文件，这些二进制文件利用了主机内核提供的 API。 主机内核为用户空间中运行的每个容器提供相同的资源隔离和管理功能。 如果内核遭到入侵，则每个容器共享该内核也是如此。
Linux 和 Windows 服务器容器的基本设计可提高安全性，实现灵活性。 Windows Server 和 Linux 容器基于 OS 提供的基元组件构建。 这样做可以灵活地在容器之间共享资源和命名空间，但它增加了额外的复杂性，从而为开发打开了大门。 总体而言，我们认为内核不足以成为恶意多租户工作负载的安全边界。
通过虚拟机监控程序隔离的容器实现内核隔离
与进程隔离的 Windows Server 或 Linux 容器相比，虚拟机监控程序隔离的容器提供了更高程度的隔离，被视为是更可靠的安全边界。 虚拟机监控程序隔离的容器由一个封装在超轻量 VM 中的 Windows Server 容器组成，通过 Microsoft 虚拟机监控程序与主机操作系统一起运行。 虚拟机监控程序提供硬件级隔离，其中包括主机和其他容器之间的高度可靠的安全边界。 即使成功利用了 Windows Server 容器的漏洞并从中逃脱，它仍然会被限制在虚拟机监控程序隔离的 VM 中。
Windows Server 容器或 Linux 容器都不提供Microsoft认为可靠的安全边界，不应在恶意的多租户方案中使用。 容器必须局限于专用 VM，以防止恶意容器进程与主机或其他租户交互。 虚拟机监控程序隔离实现了这种程度的隔离，同时它在性能方面相较于传统 VM 也有诸多提升。 因此，强烈建议在恶意多租户场景中，将虚拟机监控程序隔离的容器作为首选容器。
容器安全服务条件
Microsoft 承诺修补所有破坏任何 Windows 容器类型既定隔离边界的漏洞，并采取措施防止逃逸行为的发生。 但 Microsoft 安全响应中心 (MSRC) 流程仅处理破坏安全边界的漏洞。 只有虚拟机监控程序隔离的容器才提供安全边界，进程隔离的容器无法提供。 只有在非管理员进程能够访问主机的情况下，才可能生成进程隔离容器的逃逸 Bug。 如果漏洞利用管理过程来逃逸容器，则 Microsoft 公司将其视为非安全 bug，并会根据正常的服务过程对其进行修补。 如果攻击使用非管理员进程执行违反安全边界的操作，则Microsoft将根据 建立的安全服务条件调查它。
是什么导致多租户工作负载具有恶意？
当多个工作负荷在共享基础结构和资源上运行时，存在多租户环境。 如果不能信任在基础结构上运行的一个或多个工作负荷，则多租户环境被视为恶意环境。 Windows Server 和 Linux 容器都共享主机内核，因此对单个容器执行的任何攻击都可能会影响在共享基础结构上运行的所有其他工作负荷。
可以采取措施来减少攻击发生的可能性，例如，使用 Pod 安全策略、AppArmor 和基于角色的访问控制 （RBAC），但它们不提供针对攻击者的有保证保护。 建议在任何多租户方案中遵循我们的 群集隔离 最佳做法。
何时使用 ContainerAdmin 和 ContainerUser 用户帐户
Windows Server 容器提供两个默认用户帐户，即 ContainerUser 和 ContainerAdministrator，每个帐户都有各自的特定用途。 ContainerAdministrator 帐户使你能够将容器用于管理目的：安装服务和软件（例如在容器中启用 IIS）、进行配置更改和创建新帐户。 这些任务对于许多可能在自定义本地部署环境中运行的 IT 方案非常重要。
对于不需要 Windows 中的管理员权限的所有其他方案，存在 ContainerUser 帐户。 例如，在 Kubernetes 中，如果用户是 ContainerAdministrator，并且允许主机卷装载到 Pod 中，则用户可以装载 .ssh 文件夹并添加公钥。 由于 ContainerUser，本示例是不可能的。 它是专为不需要与主机交互的应用程序设计的受限用户帐户。 我们强烈建议将 Windows 服务器容器部署到任何多租户环境时，应用程序应通过 ContainerUser 帐户运行。 在多租户环境中，最好遵循最小权限原则，因为如果攻击者入侵了您的工作负载，则共享资源和邻近的工作负载受到影响的可能性更低。 使用 ContainerUser 帐户运行容器可大大减少整个环境遭到入侵的可能性。 不过，这仍然无法提供强大的安全边界，因此，当安全问题成为关注焦点时，应使用虚拟机监控程序隔离的容器。
若要更改用户帐户，可以在 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 项目注册表）镜像托管 IIS Web 应用程序时，容器的 ENTRYPOINT 是 "C:\\ServiceMonitor.exe", "w3svc"。 此工具可用于配置 IIS 服务，然后监视服务，以确保该服务保持运行和退出状态，从而在服务因任何原因停止时停止容器。 默认情况下，IIS 服务以及 Web 应用程序在容器中的低特权帐户下运行，但服务监视器工具需要管理权限来配置和监视服务。