101 文档：容器安全的关键指标

Document 101：The key Indicators of Container Security

101 文档：容器安全的关键指标

容器的爆发性增长是技术发展的必然结果。开发人员需要的是简单打包、快速部署、不断减
少环境依赖性、支持微服务、通用管理和横向可扩展性，容器恰好能够满足这些要求。

但是，容器完全“打包”服务，透明度极低，这对安全人员而言是一个噩梦。为了更快地运
行更多代码，只能降低对容器内可视化的要求。这不禁让人思考，我们怎样才能在充分利用
容器优势的前提下引入安全？

确保容器安全的责任落在了开发运维（DevOps）和安全团队的身上。但安全人员通常不了
解开发人员使用的工具和技术，开发人员也不了解如何处理安全风险问题。容器的安全问题
已经超越了容器本身，延伸到了构建、部署和运行时环境，需要更多人参与进来。

通过针对安全从业人员、开发人员和 IT 运营人员开展研究，本文涵盖容器和容器编排工具
的一些安全问题，以及如何在整个云原生系统中建立安全机制，包括操作系统层面、容器、
编排工具、镜像仓库等等。本文详细介绍了构建、容器管理、部署、平台和运行时的安全问
题。
 101 文档：容器安全的关键指标
Document 101：The key Indicators of Container Security

目 录
第 1 章：常见容器安全威胁 .......................................................................................................... 3

1.1 构建环境安全 ................................................................................................................... 3

1.2 运行时安全 ....................................................................................................................... 3

1.3 操作系统安全 ................................................................................................................... 3

1.4 编排管理安全 ................................................................................................................... 4

第 2 章：确保构建环节安全 .......................................................................................................... 4

2.1 构建安全 ........................................................................................................................... 4

2.2 容器验证和安全测试 ....................................................................................................... 5

第 3 章：确保运行时安全 .............................................................................................................. 6

3.1 运行时安全 ....................................................................................................................... 6

3.2 平台安全 ........................................................................................................................... 8

3.3 编排工具安全 ................................................................................................................... 9

3.4 Secrets 安全 ................................................................................................................... 10

第 4 章：容器监控和审计 ............................................................................................................ 10

4.1 监控 ................................................................................................................................. 11

4.2 审计和合规 ..................................................................................................................... 12

 101 文档：容器安全的关键指标
Document 101：The key Indicators of Container Security

第 1 章：常见容器安全威胁

容器安全威胁非常多，有一些威胁和问题是众所周知的。容器环境下的主要威胁体现在四个
方面：

1.1 构建环境安全

容器安全第一个需要保护的就是构建环境的安全。大多数人并不认为构建环境安全是优先级
最高的，但它通常是最不安全的，也是最容易被植入恶意代码的环节。开发人员往往不注重
开发中的安全检查和控制，因为这会减慢开发的速度，所以开发人员往往会绕过安全检查。

构建环境安全包括恶意或低级错误的源代码更改、对自动构建控制器的恶意或错误代码更
改、有错误或公开凭据的配置脚本检查、添加不安全的库或不安全版本的现有代码检查，以
及对运行时代码进行漏洞扫描等。

1.2 运行时安全

容器里到底有什么？容器有什么作用？这是容器的最新版本吗？这是运营人员常见的问题。
运维人员不知道开发人员是否在容器中使用了诸如 SSH 之类的工具，安全人员也很难知道
容器是否已经执行加固策略，比如打补丁、验证、加固等。如果容器存在开放的端口，也可
能会遭受威胁，并可能被用来攻击容器引擎、主机操作系统和其他容器。

图 1：运行时容器威胁

1.3 操作系统安全

用户经常会担心攻击者会通过容器攻击底层主机操作系统或容器引擎，担心容器引擎可能无
法完全屏蔽底层操作系统。一旦对主机攻击成功，那么整个容器集群就会受到严重威胁，并
可能会让攻击者有足够的访问权限来转移到其他系统。底层操作系统的安全性一直是一个重
要问题，比如，是否进行了正确的配置，来限制每个容器对其所需资源的访问。
 101 文档：容器安全的关键指标
Document 101：The key Indicators of Container Security

1.4 编排管理安全

随着容器成为应用程序交付的标准工具，各个组织开始将注意力转移到容器管理上，例如
Kubernetes 就是典型代表。但是大多数工具都非常复杂，编排工具的重点在于支持可扩展
性和易于管理，但不能确保安全性。编排工具带来了一系列全新的安全问题，包括不安全的
默认配置、权限升级、代码注入漏洞等。此外，大多数组织在启动容器时会通过编排管理工
具颁发证书、身份令牌和密钥。

第 2 章：确保构建环节安全

越来越多的基础设施被定义为代码，传统意义上的构建环境安全由开发人员负责，但他们不
会与安全团队分享过多细节。通过 CI/CD，可以将代码批量投入生产环境。攻击者入侵应用
程序最简单的方法是进入其开发或构建环境（通常远不如生产环境安全），更改代码或向容
器添加新代码。DevOps 迅速打破了不同部门之间的障碍，运营和安全团队获得了更多访问
权限，可以为安全流程做出更多贡献。因此，需要更好的安全控制措施来限制谁可以更改构
建环境和更新代码，任何变更都需要经过审计验证。

正如上文所说，开发人员倾向于使用容器，是因为其带来了诸多便利性，任何安全控制措施
都不能影响这些优势。首先，容器简化了应用程序代码的构建和打包，将应用程序从其物理
环境中抽离出来；其次，容器提倡轻量级服务，将大型应用程序分解成小块，以简化修改和
扩展，尤其是在云和虚拟环境中；最后，容器启动几乎是即时的，允许根据需求灵活地扩容
和缩容。在考虑安全控制时牢记这些特性很重要，而任何影响这些优势的安全控制措施都有
可能被开发人员所忽略。

构建管道的安全分为两个基本方面：第一个是应用程序安全性，本质上是测试代码及其容器，
以确保符合安全合规性要求，包括诸如静态分析、动态分析、组合分析、IDE 内置的扫描工
具以及监控运行时行为的工具等。第二个是用于构建部署应用程序的工具安全性，包括源代
码控制、构建工具、构建控制器、镜像仓库等，通常将其称为“管理面”，因为这些接口（无
论是 API 还是 GUI）用于设置访问策略、自动化行为和审计活动。

2.1 构建安全

从概念上来说，构建安全相对简单。但是，有很多工具用于构建软件，而且大多数都有几个
插件可以更改数据的流动方式，因此整体环境变得复杂，包括安全软件交付、软件供应链管
理以及构建服务器的安全性。
 101 文档：容器安全的关键指标
Document 101：The key Indicators of Container Security

图 2：构建环节的安全

以下是在构建环境中，确保容器构建安全的建议，包含来自 Docker 和其他平台的工具，用

于自动化和编排源代码、Docker 引擎和镜像仓库等。针对每个工具，可以选择身份管理、
角色、平台隔离、敏感数据的安全存储、网络加密和事件日志的组合。

⚫ 源代码管理工具：Stash、Git、GitHub 等源代码管理工具拥有广泛的受众。无论是否
使用容器，这都是很好的管理工具，但是容器缺乏透明度，加上将它们推入生产的自动
化流程，更加放大保护了容器构建安全的需求。

⚫ 构建工具和控制器：绝大多数开发团队都使用 Bamboo 和 Jenkins 等平台，这成为用

户自动化构建过程的重要组成部分。它们提供了许多构建前、构建后和内部构建选项，
并且可以链接到其他平台，非常便于集成，但这会让安全更难以实现。针对这类集中管
控平台需要进行完全网络隔离，限制网络连接。如果可以将构建服务器部署为没有管理
访问权限的按需容器，以确保构建环境的标准化和新容器的一致性，要尽可能严格地限
制对构建环境的访问，并在开发人员需要访问时利用内置功能来进行限制。根据需要提
取凭据以确保敏感数据处于受保护状态，包括 SSH 密钥、API 访问密钥、数据库凭证
等。最后，启用构建控制器的内置日志记录工具或日志记录附加组件，收集相关日志进
行审计。

⚫ 镜像仓库：关于镜像仓库的安全，开发人员和运维人员经常犯同样的错误。第一个是允
许将未经审查的容器镜像添加到仓库中；第二个是开发人员通常会利用开源工具或平台来加
快开发速度，但这些工具自身也可能存在诸多安全问题。因此，需要确保镜像仓库只接收来
自可信来源的容器镜像。确保容器经过审查，并且只有使用可信密钥签名的容器才能启动，
还需要确保镜像仓库和客户端需要 IAM 凭证，以限制谁可以控制构建或添加镜像，并且加
载到生产环境中的镜像必须是已通过检测的镜像仓库。

2.2 容器验证和安全测试

对容器内执行代码和扩展组件进行测试，验证是否符合安全和运营实践，是确保容器安全的
核心，尤其是供应链安全，覆盖容器打包和运行时环境，包括 Docker、CoreOS 的 Rocket、
 101 文档：容器安全的关键指标
Document 101：The key Indicators of Container Security

OpenShift 等。当前许多容器供应商在容器部署前和部署后可以帮助验证容器内容，但是每
种解决方案有所侧重，例如 Docker 提供了数字签名功能来验证容器已通过流程审核并且没
有被修改，第三方安全工具往往会专注容器服务商不能提供的安全服务，例如检查常用的开
源库是否存在已知威胁、分析资源使用情况、分析静态代码等。

⚫ 安全单元测试：单元测试是针对特定代码模块进行重点测试，通常是在开发团队发现安
全性问题或其他错误时，避免了每次都对整个产品进行测试。单元测试通常包括 XSS
和 SQLi 测试等内容。随着不断进行测试，打造了一个不断扩展的回归测试平台，确保
漏洞不会再次出现。在研究过程中，发现许多团队会选择在 Jenkins 上运行单元安全测
试。因为在应用早期进行安全测试更容易，为此，特别建议在构建环节就进行单元测试，
以验证容器中的代码是否安全。

⚫ 代码分析：许多第三方产品能够执行自动化的白盒测试，一旦发现代码存在关键问题将
阻止后续的构建过程。此外，还有一些新工具可以以插件的形式集成到开发环境 (IDE)
中使用，在把代码迁入服务器前检查是否存在安全问题。建议在实施容器化之前，进行
代码扫描以验证构建到容器中的代码是否安全。此外，一些新工具在软件交付中提供了
完整的 RESTful API 集成，这些测试通常需要比较长时间运行才有效果，但仍然适合
CI/CD 部署框架。

⚫ 漏洞分析：另一种有用的安全技术是根据 CVE（常见漏洞和暴露）漏洞库，检查各类
库和所有代码，以确定是否正在使用易受攻击的代码。Docker 和许多第三方（包括一
些开源发行版）提供了根据 CVE 检查通用类库，并且可以集成到构建管道中。因为容
器是分层构建的，包含了许多开源库、工具以及专有应用程序代码。开发人员通常不是
安全专家，但每周都会在常见的开源库中发现新漏洞，因此使用独立检查工具来验证容
器堆栈的组件必不可少。

⚫ 加固：除了确保使用的代码没有已知漏洞外，还有其他技巧可以在部署之前保护容器，
一种加固技术是删除库和不必要的包来减少攻击面。此外，还需要检查容器中未使用的
项目，积极与开发团队合作验证和删除不需要的项目。采取“极简基础镜像”的原则，
只保留应用程序运行所需的最低权限要求，减少攻击面。另一种加固技术是检查容器中
的硬编码密码、密钥和其他敏感项目，毕竟这些内容极大降低攻击者难度。

第 3 章：确保运行时安全

前面的章节主要分析了构建环节的安全，后面章节将主要关注生产运行环境中的容器安全，
包括将哪些镜像推送到镜像仓库，容器运行时以及底层主机系统的安全性。

3.1 运行时安全

⚫ 控制面：确保控制面的安全，包括管理主机操作系统、调度程序、容器客户端、引擎、
镜像仓库和其他部署工具等。建议限制对特定管理帐户的访问权限，包括容器编排系统、
补丁和配置管理系统。一些第三方工具提供了跨系统的完整身份和访问管理、LDAP/AD
集成和基于令牌的 SSO（即：SAML）
。
 101 文档：容器安全的关键指标
Document 101：The key Indicators of Container Security

⚫ 资源使用分析：容器是否允许访问端口 22（用于 SSH 登录）？容器是否支持自我更

新？容器依赖于哪些外部系统和实用工具？任何对外的开放资源都可能是攻击者的潜
在攻击点，因此限制访问入口和出口是一个良好的安全对策。为了管理容器可以访问的
范围，利用第三方工具可以监控运行时环境中的资源访问，包括容器内部和外部，对资
源需求进行自动审查。将单体应用架构转向微服务架构，可以帮助开发人员了解可以从
代码中删除哪些应用，帮助管理员缩小角色和访问权限。

⚫ 建立可信的镜像：建立受信任的镜像仓库，确保生产环境中的镜像只能从受信任的仓库
中拉取。通过脚本进行部署以避免人工干预，确保始终选择最新的认证容器，这意味着
将容器投入生产之前，需要检查脚本中的应用程序签名，受信任的镜像仓库服务可以拒
绝未正确签名的镜像进入容器生产环境，以确保镜像安全。

图 3：生产环境中确保镜像安全

⚫ 不可变镜像：开发人员通常会为容器镜像预留后门，以便他们可以登录到生产中运行的
容器，起初的动机通常是调试和更改动态代码，但这不利于一致性和安全性。不可变容
器不允许 SSH 连接，并且阻止交互式的实时操作。因此要求开发人员修复开发管道中
的代码，并删除主要攻击路径，这并不会丢失生产中容器的更改跟踪或版本控制。从特
定威胁的角度来看，攻击者通常会扫描 SSH 访问以入侵容器，并利用它们来攻击底层
主机和其他容器。建议使用没有“端口 22”访问权限的不可变容器，确保所有容器更
改都发生在构建过程中（带有日志记录） ，而不是在生产过程中。

⚫ 容器存活时间：多久前构建了这个容器镜像？这个容器运行了多久？一旦碰到容器受
攻击的情况，一个非常实际的问题是：多少容器正在运行此软件包？建议容器“存活”
时间不要太长，因为在长时间的运行过程中完全有可能出现一个新漏洞。建议可以为生
产环境中的容器设置最长的“生存时间”，限制在几个小时或几天之内进行更换。实际
上，一个镜像可以实例化为一千个正在运行的容器。要解决问题，更新镜像并替换那些
 101 文档：容器安全的关键指标
Document 101：The key Indicators of Container Security

正在运行的容器（使用旧镜像），养成定期更换正在运行的容器的习惯，定期修补和更
换，以保持容器与当前版本同步。

⚫ 输入验证：容器启动时接收参数、配置文件、凭据、JSON 和脚本。在一些特殊的场景
中，有人将新代码作为输入变量置于容器中，让现有容器以新的方式运行。因此，必须
要手动或使用第三方安全工具验证所有输入数据是否正确并符合要求，确保每个容器都
收到正确的用户和组 ID。

⚫ 容器组隔离：容器管理系统的一个重要优势是实现跨共享服务器资源池的各类管理。每
个管理平台都提供模块化架构，在 node/minion/slave 上执行扩展并形成一组容器。每
个 node 形成自己的逻辑子网，限制容器组之间的网络访问。应用程序架构师和安全团
队可以利用这种结构来提高安全性。容器云服务商可以提供容器隔离能力，第三方容器
安全工具也可以提供此类安全服务。

3.2 平台安全

当有人谈论容器安全时，他们真正谈论的是如何保护虚拟机管理程序和底层操作系统的安
全。运行时安全包含更多内容，比如主机操作系统加固、命名空间隔离和按信任级别隔离工
作负载。

⚫ 主机操作系统/内核加固：加固是保护主机操作系统免受攻击和滥用的主要方式。 首先
需要选择一个加固过的操作系统。虽然这些加固操作系统版本带有库和安全功能，但仍
然需要利用基线配置并删除不需要的功能。例如 CIS Docker Benchmark 提供了一个
检查列表，为系统加固提供了良好参考基准，比如确保设置了基于用户身份验证和访问
角色管控规则、正确设置二进制文件访问权限、启用日志数据审计、完成操作系统补丁
修复、检查容器的虚拟化库，比如 libcontainer、libvirt 和 LXC 的补丁和配置状态等。

⚫ 访问隔离和资源控制：容器安全的一个关键点是限制容器对底层操作系统资源的访问，
特别是防止容器窃取其他容器的数据。第一步是确保按角色分配容器权限。容器引擎必
须在主机操作系统的 root 用户下运行，但其他容器不能拥有 root 权限。接下来是容器
的资源隔离模型，它建立在两个概念上：Cgroups 和 Namespace。Namespace 基于
不同任务构建虚拟的资源映射，其原理是针对一类资源进行抽象，并将其封装在一起提
供给一个容器使用。因为每个容器都有自己的抽象，而他们彼此之间是不可见的，所以
就可以做到访问隔离。例如，它将特定用户和组映射到其命名空间内的资源子集（网络、
文件、IPC 等）
。建议入栈请求设置为默认拒绝，并且只允许具有合法需求的容器在开
放网络通道上进行通信。通常情况下，不会在一台服务器上混合容器和非容器服务。为
容器创建特定的用户 ID 或为不同类别的容器创建组 ID，然后在运行时为容器分配 ID。
容器会受到控制组（即：Cgroup）分配的资源量的限制。Cgroup 将一组进程放在一个
控制组里，通过给这个控制组分配指定的可用资源，例如内存或 CPU 资源，有助于保
护一组容器免受另一组容器资源匮乏的影响。
 101 文档：容器安全的关键指标
Document 101：The key Indicators of Container Security

图 4：分配容器权限

⚫ 工作负载隔离：除了上文讨论的内核级别的资源隔离，还需在网络层隔离容器引擎、操
作系统组及容器。对于容器隔离，建议将相互信任的容器组映射到单独的服务器或网络
安全组。对于运行关键服务或管理工具的容器，考虑为每个 VM 运行有限数量的容器，
并按信任级别或工作负载将它们分组或放入专用的云 VPC，以最大限度地减少攻击者
在入侵服务或容器情况下横向移动。对于编排管理工具，至少要确保关键应用程序在其
自身的节点中运行，若无法确做到，也要确保在其自身的集群中运行。

3.3 编排工具安全

目前市场上有许多编排管理工具，包括 Kubernetes、Mesos、Swarm 等，其中 Kubernetes

是管理容器集群的主要代表工具。随着编排工具的迅速普及，一系列的容器安全问题也随之
产生。

⚫ 管理面安全：无论使用 Swarm、Kubernetes 还是 Apache Mesos/Maratho，都将通过

命令行和 API 进行处理。例如，etcd 键值存储和 kubectl 控制器是管理 Kubernetes
集群的基础，但攻击者也可以通过多种方式恶意利用这些工具。事实上，某些平台上的
用户界面不需要用户身份验证，禁用该功能是一种常见的做法。虽然可以限制访问管理
功能的人员，但开发人员或攻击者可以导入他们自己的命令行工具，所以简单的访问控
制是不够的。某种程度来说，网络隔离有助于保护编排管理服务器并控制可以运行管理
命令的位置。使用网络隔离，利用内置于集群管理工具（Kubernetes 的 RBAC）中 IAM
服务为节点服务帐户设置最低权限。
 101 文档：容器安全的关键指标
Document 101：The key Indicators of Container Security

图 5：管理面安全

⚫ 限制发现：集群管理工具收集有关集群配置、容器和节点的各种元数据。这些数据对于
集群管理至关重要，但也为攻击者攻击系统提供了机会。限制哪些服务和用户可以访问
元数据，并确保请求方获得完全授权，有助于减少攻击面，比如许多平台提供元数据代
理来过滤和验证请求。

⚫ 升级和补丁：新版本往往更安全，虚拟化是任何容器集群的关键，这些可扩展的平台构
建了冗余，因此可以利用集群管理功能快速修补和替换集群服务和容器。

⚫ 日志记录：从所有容器和节点收集日志。许多攻击侧重于提权和获取证书，建议监控 API
调用。

3.4 Secrets 安全

当启动容器编排管理工具时，它需要有权限与其他容器、节点、数据库或网络资源进行通信。
在高度模块化的面向服务的容器架构中，没有凭据将无法进行 API 调用、无法真正完成大
量工作。但是不能将 Secrets 硬编码到容器中，也不能将 Secrets 存在于服务器文件中。按
需大规模地提供临时身份信息很麻烦，因此在容器需要时安全地向它们提供 Secrets，能够
解决这个问题的产品被称为“Secrets 管理”平台。随着云服务、容器和 Kubernetes 和
Swarm 等编排框架的使用，开始通过 Secrets 管理产品来存储内容，包括加密秘钥、API
证书、身份令牌、SSL 证书和密码。他们可以在受信任的服务和用户组之间共享 Secrets，
利用现有的目录服务来确定谁可以访问什么。许多编排管理工具和容器生态系统提供商，例
如 Docker，提供了内置的 Secrets 管理工具。但大多数内置的 Secrets 管理工具都有一些
严重的缺陷，其中一些迫使选择特定的技术。

第 4 章：容器监控和审计

本章重点强调容器的两个关键功能：监控和审计。由于大多数开发和安全团队尚不了解监控
和审计的多样性，下文我们将详细阐述相关内容。
 101 文档：容器安全的关键指标
Document 101：The key Indicators of Container Security

4.1 监控

前面章节所讨论的每项安全控制措施都是预防性安全。本质上，这些是消除漏洞或让攻击者
难以实现漏洞利用。通过正常响应来解决已知的攻击向量，例如打补丁、安全配置和加密，
但是如果面临的新的攻击变体绕过了安全控制，或者受信任的员工犯了错误该如何解决？这
时就需要监控，用来了解什么是有效的，实时跟踪环境中真正发生问题以及检测出问题的方
式。

监控的第一步是收集事件，然后根据安全策略进行实时检测。收集的事件数据包括对硬件资
源的请求、基于 IP 通信、API 请求或与其他容器共享信息。安全策略有些是提前制定的管
控措施，例如哪些用户和组可以终止资源，禁止哪些容器对外发出 HTTP 请求，或者允许容
器运行哪些服务。也有一些安全策略是动态变化的，即“基于行为的策略”，阻止一些异常
行为。例如，容器调用异常端口，容器内容占用超过了常规数值 50%等问题。基于确定性黑
白名单策略与动态行为检测相结合是实施容器监控的最佳实践方法，能够检测简单的已知的
不合规行为，也能够发现未知的异常行为。

面对众多的容器运行时入侵行为，青藤蜂巢•云原生安全平台采用多锚点的分析方法，实时
检测容器中的已知威胁、恶意行为、异常事件。

首先，青藤蜂巢能对容器内的文件、代码、脚本等进行已知特征的检测。以 Webshell 检测
为例，青藤蜂巢内置了 Webshell 检测引擎——青藤雷火引擎，该引擎不依赖正则匹配，可
以根据 AI 推理发现 Webshell 中存在的可疑内容。即便是在实战化对抗环境下，Webshell
检测率高达 99.54%。

其次，青藤蜂巢基于对恶意行为模式的定义，可对容器及编排工具内的黑客攻击行为进行实
时检测。例如，通过比对攻击链路上的关键攻击路径，针对黑客的每一步探测，系统均会进
行持续性的检测。

最后，由于容器不可变基础设施的属性，其运行时行为模式相对固定。青藤蜂巢，通过对其
进程行为、网络行为、文件行为进行监控和学习，建立稳定的容器模型。只要对异常偏离的
行为进行分析，就能发现未知的入侵威胁，包括 0day 等高级攻击。

衡量一个容器安全监控方案常见指标包括：

⚫ 部署模型：容器安全监控类产品有两种部署模型，即在主机操作系统中嵌入 Agent 或以
平行容器方式进行监控。需要评估判断不同产品方案是如何收集事件，可以收集哪些事
件，是否支持 API 调用进行检查以及部署难度等。例如国内云原生安全领导者青藤的蜂
巢产品通过收集容器相关行为数据，包括容器进程启动日志、API 调用行为日志等，结
合 ATT&CK 框架模型，通过大数据工具来进行安全威胁分析，确定攻击的影响范围和入
侵路径，通过威胁狩猎主动发现内部潜在的其它威胁。

⚫ 策略管理：需要评估在整个生命周期内中构建新策略或修改现有策略的难易程度。

⚫ 行为分析：供应商提供的方案有哪些行为分析能力？行为分析需要从系统监控开始，以
 101 文档：容器安全的关键指标
Document 101：The key Indicators of Container Security

确定“正常”行为，例如用户 ID 或 IP 地址。更高级的工具可以提供十几种或更多选择，
拥有的可用资源越多（例如系统调用、网络端口、资源使用情况、镜像 ID 等），行为分
析的覆盖范围就越广、越灵活。

⚫ 管控能力：供应商是否提供阻止请求或启动行为的能力？阻止违反策略并确保容器按预
期运行非常有用，这意味着有权丢弃应用程序请求，甚至暂停容器以确保请求不被处理。
以青藤蜂巢为例，在检测到异常入侵事件之后，对于失陷容器，可进行快速的安全响应，
把损失降到最低。青藤蜂巢能够实施不同细粒度的管控措施，在容器层面可以直接隔离、
暂停、查杀容器，在容器行为层面可以阻断进程、隔离文件、封禁 IP，不允许有问题的
工作负载进行访问或被访问。

⚫ 平台支持：需要验证监控工具是否支持使用的操作系统平台（CentOS、CoreOS、SUSE、
Red Hat，甚至 Windows）和编排工具（例如 Swarm、Kubernetes、Mesos 或 ECS）
。

4.2 审计和合规

开发人员关注构建过程，而安全人员可能想知道 sshd 服务是否已从新容器中删除，或者是

否已通过特定的安全测试，运维人员想知道镜像仓库中最新构建的版本，审计和合规团队对
这些问题不感兴趣，他们想知道哪些管理员可以访问管理功能，哪些容器可以访问受监管的
数据，这些容器如何与其他容器隔离。要解决此类问题，需要操作日志、配置数据和流程文
档。

大部分企业已经制定了控制措施和报告来支持监管和审计。当前最主要的挑战是将这些内容
映射到容器和编排管理工具等新环境中。在这些环境中，应用程序作为微服务存在于数十台
定期出现和消失的服务器上。

幸运的是，绝大多数代码存储库、构建控制器和容器管理系统，特别是 Docker 运行时和

Docker Trusted Registry 生成事件日志，可以供各种日志管理、安全信息和事件管理使用
（SIEM) 系统使用。