“裸奔”的容器，安全问题迫在眉睫

• 什么是容器

1. 容器是一种操作系统级虚拟化方法，用于在单个受控制的主机上运行多个隔离的Linux系统（容器），它允许多个隔离的用户空间实例和资源管理功能

1. 容器从底层操作系统中抽象出应用程序，以实现更快的开发和更轻松的部署

• 容器安全定义

容器安全防护就是运用流程来设置一些安全工具和政策以确保容器内的一切都依照提前的规划来运作，包含基础架构、软件供应链、运行时环境以及期间中各个环节的所有防护。

在这样的概念下，容器安全防护是一个持续不断的过程，而且应该整合到您的开发流程中，并通过自动化的方式来减少手动工作，并延伸到基础架构的维护与运营。这意味着，您不仅必须保护建构流程的容器镜像，还要保护运行时期的主机、平台与应用程序层。将防护融入不断循环的软件生命周期持续性交付，能协助您降低企业风险，减少日益扩大的受攻击面所潜藏的漏洞。

• 容器存在多久时间了？

容器技术已经存在了10多年，最近由于云计算的普及而爆发

• 有哪些不同类型的容器解决方案？

1. LXC(Linux Containers)
2. Docker
3. Podman
4. CoreOS AppC
5. Solaris Zones
6. FreeBSD Jails
7. AIX Workload Partitions
8. Kubernetes

• 容器安全开发原则
  • 容器安全成为云安全第一战场

尽管当前市场上充斥着各种开源和商业化的容器安全解决方案，但许多此类产品仅针对容器安全的特定维度提供防护，并未全面覆盖整体的安全态势。例如，在容器上构建的大量应用程序通常依赖于多种开源及商业化的基础设施即服务（IaaS）与平台即服务（PaaS）环境。然而，由于对底层IaaS和PaaS环境的洞察力匮乏，企业在云端运营时难免会遭遇一些安全隐患。

具体来说，若缺乏深度且全面的环境可视性，以及对横向移动的有效管控机制，则在检测攻击者如何在容器内部进行横向渗透活动方面将面临显著挑战。换句话说，对于攻击者在容器生态系统中实施的潜在横向移动行为，没有一个全方位、端到端的安全视图和相应的控制手段，很难做到及时准确地识别与阻止。

全面掌握容器技术栈的整体架构对于有效管理和减轻风险至关重要，而仅依赖于针对容器安全某个特定维度的点解决方案，可能会由于缺乏全局视角而无法全面洞悉并应对潜在风险。例如，当CVE最新公告揭示了容器环境中的新漏洞时，拥有对整个容器堆栈深入的理解和透视能力，则能够全方位地应对这一安全威胁，包括但不限于识别受影响资产的具体范围、精确追踪与评估镜像补丁的修复进度及状态等关键信息。

• • 安全左移和自动化是全生命周期容器安全的前提

鉴于容器和云技术所实现的极高运行效率，DevSecOps成为了安全团队应对挑战的核心策略。这一方法论将DevOps与安全运维无缝整合，旨在从容器生命周期的源头——构建阶段起就贯彻安全性原则，进而贯穿部署及运行全过程。

在当前快节奏的容器DevOps环境下，在部署容器时，安全团队必须对由容器共享操作系统内核所带来的潜在安全隐患、镜像漏洞、配置缺陷以及容器间网络通信问题保持高度警觉。值得注意的是，传统防火墙及入侵防御系统并不完全适用于容器化环境的安全管控场景。

此外，随着现代信息技术环境日益向软件定义和自动化方向演进，暂停生产流程以进行安全审查的传统做法已无法适应现实需求。因此，行业最佳实践是将安全防护深度融入生产流程之中，并通过微服务架构实现快速迭代与持续安全保障。

1. 安全左移

当前，容器镜像的构建工作已逐渐由开发人员接手，从而使得他们在传统上由其他职能团队主导的活动领域中承担了更多责任，如部分测试与运营任务。在不同部署环境中，无论是测试环境还是生产环境，由开发人员构建的容器镜像均需保持一致的行为表现，确保其具备跨环境的一致性和自包含性。为此，容器镜像应独立且适应性强，通过预先配置与容器紧密相关的安全策略及强化措施，并对基础操作系统进行适当调整以实现与生产资源的有效对接。

因此，容器安全的把控必须向左移至更早阶段，即从代码编写和编译阶段就开始实施全面的安全保障。若将安全问题留待生产过程中解决，则可能导致创新流程中断，带来不必要的资源浪费，因为修复发现的问题会迫使容器退回开发阶段，影响交付效率与质量。为确保容器安全的无缝集成，须在软件开发生命周期早期就嵌入安全实践，实现安全左移，以期达到持续、高效的DevSecOps流程优化。

1. 自动化

容器技术作为DevOps实践的核心载体之一，极大地推动了微服务架构的广泛应用。这种基于容器化的微服务设计允许各个开发团队通过为每个独立微服务构建并行开发流水线，从而实现创新速度提升十倍以上的显著效果。

当这些微服务进入生产阶段时，容器编排软件则承担起部署和管理的关键角色。此类编排工具遵循预设策略进行操作，能够以超越人工所能达到的效能对容器化部署进行精细化管控。这一机制有效地将运维人员从繁琐的容器化生产环境运营工作中释放出来，使他们能更专注于策略规划与异常行为监控层面的工作。

换句话说，容器编排系统的核心价值在于支持自动化运维流程、API驱动以及策略导向的操作模式，赋予容器自我评估及采取相应行动的能力，从而实现高效且智能的容器资源管理与服务交付。

• • 全生命周期解决方案
    1. 构建阶段

安全镜像扫描：容器镜像构建始于基础根镜像，该镜像预置了操作系统内核、核心组件以及诸如Node.js或Apache Tomcat等应用程序中间件。开发人员在此基础上通过叠加自身业务代码实现对根镜像的扩展和定制，从而构建出符合微服务架构的应用程序镜像。通常情况下，对于Kafka或Vertica等标准应用中间件，开发者可以直接采用而无需进行深度定制。

然而，在从Docker Hub等公共镜像仓库获取并使用这些根镜像时，开发团队可能难以洞察这些未经严格安全测试与验证的镜像所潜在的安全隐患。为应对这一挑战，必须执行容器镜像扫描操作，旨在全面检测镜像中是否存在已知漏洞，并通过及时修复来最大程度地缩减最终部署容器的攻击面，以提升其整体安全态势。

正确的镜像扫描应包括以下几个级别：

1. 进行镜像扫描，检查根镜像，检测开源镜像库中是否有已知的第三方漏洞。

1. 对配置和部署脚本进行静态扫描，及早发现错误配置问题，并对已部署的镜像进行动态基础架构加固扫描。

对受信镜像进行签名和注册：在审查容器镜像时，确保进行全面的漏洞扫描和深度安全测试至关重要。这是因为在将其部署到生产环境之前，它会直接影响合规性检查的结果。如果镜像成功通过了安全扫描，并生成了一份详细的安全评估报告，那么我们可以采用权威的重新签名流程，将安全评分和完整的测试结果添加到元数据中。这么做是为了清楚地表明这个容器镜像已经经过了严格的质量和安全性验证，达到了特定的安全等级标准。这样一来，就能提升该镜像在整个软件供应链中的可信度和可追溯性，让人一目了然。

观察应用程序行为：在微服务架构中，开发团队使用容器化的微服务来构建应用程序。这意味着网络就像一个灵活的骨架，将各个独立运行的服务连接起来。与传统单体应用不同，微服务间的逻辑关系不是预先设定好的，而是在运行时按需动态连接。

但微服务架构也带来了新的挑战：由于服务被拆分得很细，且在多个业务场景下交互，识别正常行为和异常行为变得困难。因此，在开发阶段，我们需要深入了解并持续监控微服务的运行模式，明确什么才是它们应有的正常表现，这样才能更好地进行威胁建模。

简单来说，在实际运营环境中，基于前期完善的威胁模型，我们可以更准确地发现微服务中的异常行为，并能迅速隔离问题，以确保整个系统的安全稳定。

1. 1. 1. 分发阶段

审核已知内容：在容器镜像从一个仓库转移到另一个仓库时，无论是内部转移还是外部迁移，都可能带来未知漏洞的安全风险。因此，在镜像通过仓库时，必须对其进行严格的安全检查。就像安检一样，安全框架需要审核镜像的合规性，一旦发现镜像不合规，就应立即阻止并隔离。

当容器在不同的环境（比如从开发、测试到生产）中升级和更新时，我们需要实施更严格的管理措施。确保在早期阶段为了调试、监控或基准测试而临时添加的所有配置元素，在容器进入下一阶段前被彻底清理掉，以消除潜在的安全问题和非必要组件对生产环境的影响。简单来说，就是在容器进阶过程中，我们要确保其“轻装上阵”，只保留必要的、安全的部分。

审核风险评分：容器和镜像的安全管理非常复杂，手动制定并保持统一、易维护的安全规则很困难。为解决这个问题，我们可以将安全策略自动化，就像给每个重要环节的容器镜像打分一样，评估其风险程度。这样不仅能确保容器在全生命周期内的标准化安全管理，还可以设定最低安全标准。一旦某个评估结果低于预设的安全标准，系统会立即介入并控制相关进程。

此外，这种基于评分的风险评估方式有助于Dev（开发）、Sec（安全）和Ops（运维）团队更好地协同合作。因为这个评分机制提供了一个大家都看得懂、跨职能的风险衡量标准，不仅有助于各团队理解和遵守统一的安全要求，也能让大家在保障容器安全性上有一致的工作行为和决策依据，形成共同的合作规范。

1. 1. 1. 部署阶段

自动部署：开发团队正以前所未有的速度采用容器化技术构建微服务架构，这使得DevOps流程的复杂性与日俱增，尤其在生产环境下的调度与编排层面，人力操作逐渐让位于自动化手段。高效的容器编排与调度工具能够实现微服务的自动化部署，它们凭借优化的布局策略和智能扩展决策，显著超越人工操作，并确保安全策略的一致性和稳定性执行。

为了始终保持基础设施的安全状态处于可控阈值内，我们需要将容器安全解决方案深度集成到部署系统中，以标准化、统一化的方式实施并遵循预设的安全策略。基于基础架构即代码（Infrastructure as Code,IaC）原则，应当对用于驱动自动化部署任务的配置代码进行严格的扫描和验证过程，在应用代码层面深入挖掘潜在漏洞，从而确保整个应用程序生命周期内的安全性得到持续改进与强化。

安全基础架构：尽管在服务器上使用了经过严格检查、看似没有安全问题的容器，但仍然存在一些隐藏的安全风险。为了防止针对不良分子攻击或异常容器行为，我们需要采取全面且严谨的安全措施和行业最佳实践。例如，我们可以参考CIS（互联网安全中心）制定的标准或公司特定的安全强化策略，对当前的容器环境进行全面细致的安全合规性检查，找出并明确指出与推荐安全配置之间的差异。

此外，系统应具备智能化的监控和警报功能，一旦发现安全配置出现偏差，能立即通知管理员。系统会根据预设的安全基准，持续评估整个容器基础设施的综合安全性，并给出评分。这样，我们就能及时发现问题，采取相应措施提升整体的安全水平。

用户和机器审计：为了找出安全问题的根本原因并采取有效的解决措施及部署新的安全策略，团队需要建立一个全面的审核跟踪系统。这个系统能够详细记录和追踪每个操作步骤，例如具体用户的操作行为、容器编排系统如何将特定镜像部署到实际或虚拟服务器上，以及为何阻止了某个容器镜像的部署或者限制了其访问某些资源的权利。

简单来说，就是要让容器安全体系与人类和机器操作系统紧密结合，从而在容器设施的所有层级形成一条清晰、详尽的审查记录。此外，这套系统还需能自我记录运行时的所有活动，确保容器生态系统内发生的任何事件都能得到透明、可追溯的管理和控制，让大家一看就明白。

1. 1. 1. 运行阶段

密钥管理：在众多安全架构中，密码与安全令牌等密钥元素构成了关键的安全控制基础。当在主机环境中部署容器镜像或访问网络资源时，这些密钥的运用必不可少。然而，若将密钥直接存储于容器内部或者以环境变量形式暴露，那么所有具备容器访问权限的实体都可能窥探到这些敏感信息。

在执行诸如容器部署等操作过程中，系统要求严格控制并使用密钥。因此，先进的容器安全体系结构通常需要与密钥管理系统进行深度融合，确保在执行容器命令时能够安全地注入并使用恰当的密钥以实现部署和运行过程中的授权验证。

因此，针对容器环境下的密钥管理问题，有必要采用专门且高效的安全解决方案。例如，通过集成如HashiCorp Vault这类权威密钥管理系统，可以实现对密钥访问的精细化管控，确保只有特定用户及容器在获得授权后，才能按需获取并使用与其权限相符的密钥，从而有效提升了整体的安全性和合规性。

与主机隔离：在宿主机上运行的容器有可能访问到诸如计算资源、存储资源以及网络资源等核心基础设施。鉴于容器通常承载着微服务，其设计原则是实现单一职责化，即每个容器应专注于执行一项特定任务。然而，当不良行为的容器未经授权而获取了对主机资源尤其是网络资源的访问控制权时，它就有可能在网络环境中进一步横向渗透，进而侵入其他主机及系统。

为防止此类安全风险的发生，应当对运行中容器的权限进行严格限制，并确保这些容器仅能使用经过授权和明确界定的宿主机资源。这一举措旨在通过量化和隔离容器对宿主机及其关联网络环境的影响，从而强化整体的安全性和可控性。

容器网络安全：在一台主机上同时运行多个容器时，它们之间以及与主机或其他容器的网络互动频繁。但是，传统的网络安全措施无法全面监控和保护这些内部通信，因为它们看不清主机内部的具体活动。

为解决这个问题，我们需要在更接近主机层面实施针对容器的安全策略，例如使用专门的容器安全代理技术。这种智能代理能实时监控主机上所有容器的网络流量，包括它们之间的数据流入流出，并全面检查容器与其他网络实体的交互行为。

通过深入理解并分析容器间的网络交互规律，我们可以精确地强化网络流量控制，有效拦截任何异常或潜在的威胁行为。此外，在创建容器环境之初，应结合威胁建模方法，提前规划并实施合理的网络隔离策略，并进行严格的验证测试。

这样做是为了确保一旦某个容器遭受安全攻击，其影响可以被限制在一个小范围内，不会波及到整个网络环境，防止引发全局性的系统风险。

应用程序配置文件加固：在现代应用设计中，系统被拆分成许多独立且灵活的微服务，每个微服务都有多个可随时增加或减少的实例来应对不同负载。这种架构的变化和管理主要依靠容器编排工具进行细致调整和部署。但随着系统变得愈发复杂，理解和确保每个部分正常运行变得更加困难。问题可能源自开发阶段未发现并修复的软件错误，在实际使用时暴露出来；也可能是因为引入了带有恶意代码的第三方开源组件。

为了及时发现这些问题，一个方法是在开发阶段详细记录并明确微服务应有的结构和标准运行行为，然后将这些作为参照，在实际运行时进行比对检查。另外，还可以让应用在生产环境中长时间稳定运行，观察并总结出其应有的常规行为模式，形成一份标准的应用程序正常行为参考档案，以便后续用来监控和识别异常情况。

• 镜像应对措施
  • 镜像漏洞

需要使用专用的容器漏洞管理工具和流程。传统的漏洞管理工具在主机持久性和应用更新机制和频率方面做出很多假设，但这与容器化模型完全不相符。这些工具往往无法检测容器内部漏洞，从而产生虚假的安全感。

组织机构使用的工具应采用基于管道的构建方法，并将容器和镜像的不变性融入其设计中，从而提供更可行、更可靠的结果。有效工具和流程的关键内容包括：

1. 与镜像的整个生命周期集成，从构建过程初期开始，到组织机构使用的镜像仓库，到运行时。

1. 对镜像所有层的漏洞均实现可视化，而不只是根镜像层，还包括组织机构正在使用的应用框架和自定义软件。应在整个组织机构范围内统一提供这种可视化功能，并提供符合组织机构业务流程的灵活报告和监控视图。

1. 策略驱动的执行：组织应能够在构建和部署过程的每个阶段创建“质量门户”，确保只允许继续执行符合组织机构漏洞和配置策略的镜像。

其他对镜像的安全使用手法：

1. 使用最小化基础镜像：选择最小化的基础镜像，只包含必要的组件，以减少潜在的漏洞和攻击面。如使用Alpine Linux作为基础镜像：FROM alpine:latest
2. 定期更新镜像：定期更新容器镜像，确保镜像中的组件和依赖项都是最新的，以修复已知的漏洞，更新容器镜像命令：docker pull my-image:latest
3. 使用非特权用户：在容器中使用非特权用户来运行应用程序，以减少潜在的特权升级攻击。如以下以非特权用户身份运行容器USER myuser
4. 配置安全策略：使用安全配置文件，如AppArmor、SELinux或Seccomp，来限制容器的系统访问权限。如配置Seccomp策略
5. 隔离敏感数据：将敏感数据存储在Docker数据卷中，确保只有授权的容器可以访问。创建Docker数据卷：docker volume create my-data
6. 监控和审计容器：使用容器监控和审计工具，如Sysdig或Falco，来实时监测容器的行为，检测异常活动。如使用Sysdig监控容器：sysdig -c containers

• • 镜像配置缺陷

为了确保组织机构遵循安全配置的最佳实践，我们需要使用专业工具和流程来检查并强制实施容器镜像的合规要求。具体来说：

1. 检查镜像安全性：系统全面地检查镜像的所有设置，包括供应商推荐的安全配置以及行业公认的最好做法。

1. 实时监控镜像合规性：建立一个能持续更新、集中报告并实时检测问题的机制，以便及时发现潜在的安全漏洞和风险。

1. 严格执行合规策略：利用技术手段阻止不满足合规标准的镜像运行，强化对合规性的硬性执行。

1. 选用安全可靠的基线镜像：只使用信誉良好的来源提供的，并经过充分验证的基础镜像，比如选择最小化攻击面的轻量级操作系统如Alpine Linux或Windows Nano Server作为基础镜像。

此外，强烈建议不要在容器内部启用SSH或其他任何提供主机远程访问功能的工具。为确保容器安全，应让容器以不可变的方式运行。开启这些工具会违反容器不可变原则，大大增加遭受网络攻击的风险。正确的做法是，通过容器运行时提供的API接口来进行所有远程管理任务，这可以通过编排工具间接实现，例如，通过连接到承载目标容器的主机创建远程shell会话来进行管理操作。

• • 嵌入式恶意软件

组织机构需要实施一项持续的镜像安全扫描策略，目的是及时发现并抵御潜在的嵌入式恶意软件威胁。

这个策略的关键步骤包括：运用最新的恶意软件签名数据库进行精确比对识别，并结合基于大量真实攻击案例分析的行为检测技术。

通过实时更新和智能化分析，要确保能全面、深入且高效地监控和应对所有可能的恶意活动。

• • 嵌入式明文密钥

在使用Docker Swarm和Kubernetes等主流容器编排工具时，我们可以将密钥安全地存储在镜像外部，并在运行时根据需要动态提供给容器。这些工具内置了专门的密钥管理功能，确保密钥既安全又恰当地注入到容器中，简化了密钥在整个构建、部署流程中的管理。

例如，在企业环境中，可以通过这类工具安全地将数据库连接密码传递给Web应用容器，这样只有Web容器能访问这个关键信息，而且不会将密钥写入永久存储，而是在启动应用时实时提供。

此外，组织还可以将容器部署策略与现有的企业级密钥管理系统进行整合，即使在非容器环境中也能实现。这类系统通常带有API接口，可以在部署容器时安全获取敏感数据，从而无需在镜像内部保存密钥。

无论选择哪种管理工具，组织都必须确保密钥是依据预设规则和管理员控制精确地分发给需要它们的特定容器，同时保证静态存储的密钥始终加密，传输过程则采用符合联邦信息处理标准（FIPS）140认证的安全加密算法来保障数据安全。

• • 使用不可信镜像

组织机构应运维一个权威的镜像集合及镜像仓库系统，并确保其环境中仅允许运行该集合内的镜像资源，以最大程度地降低部署不可信或恶意组件的风险。

1. 为了实现风险的有效管控，建议组织采用多层次的安全策略：

1. 实施集中化的镜像信誉管理机制，精准控制和界定在组织环境内允许信任及使用的特定镜像与镜像仓库资源。

1. 采纳NIST认可的数字签名技术，对每个镜像进行独一无二的身份标识与加密签名，确保镜像源的可靠性和内容的完整性。

1. 严格执行准入政策，确保所有主机系统仅运行经过严格审批流程并列入白名单的镜像资源。

1. 实施严格的镜像执行前验证措施，通过检验镜像签名来确认其来源可信且未被非法篡改。

1. 持续性地对镜像仓库进行严密监控与维护，随着安全漏洞披露和配置要求的演进，及时更新存储库中的镜像，确保其始终满足最新的安全标准与合规需求。

本次只针对镜像以及容器开发原则方面针对性说明，后续还将针对镜像仓库以及编排工具、容器、主机操作系统、硬件等方面详细说明，本章因为篇幅过长，将留到下个小节继续说明

• 总结

德迅蜂巢·云原生安全平台的核心架构理念：

在开发阶段（Dev），遵循“安全左移”原则，做到上线即安全

在运行阶段（Ops），遵循“持续监控&响应”原则，做到完全自适应

运用最新的安全审计解决方案和实时监控技术，对容器的运行状态进行持续性深度洞察，以确保及时探测并预警潜在的异常行为和安全威胁。通过集成化的监控仪表板，实现对容器环境的全方位、精细化运维监管，从而有效提升容器安全性及整体运行效能。