实践分享：基于DevOps流程的容器安全看板

容器作为实现云原生的核心技术，凭借其轻量化、便捷性、高弹性的特点成为释放了云计算效能红利的重要技术之一。但容器作为新的防护对象，也面临着诸多安全风险。要确保容器安全，不仅要保护容器构建、分发和执行过程中涉及的组件堆栈，而且要涵盖容器开发、分发、执行、入侵检测和事件响应等不同阶段。基于此，青藤云安全总结得出了适用于 DevOps 工作流程的 14 个容器安全最佳实践。

文末可下载完整版的《DevSecOps 发展与解决方案》

防御阶段：安全左移的 6 个步骤

1. 在 CI/CD 过程中集成代码扫描工具

在分发应用程序之前甚至构建应用程序时，可以通过扫描代码来检测错误或是否存在潜在的可利用漏洞。用户可以在开发者机器上运行 IAST、DAST、SAST 工具，也可以在 CI/CD 过程中整合代码扫描工具可以确保代码质量得到保证。例如，如果某些检查不合格，就可以默认阻止拉取请求。

2. 通过依赖项扫描减少外部漏洞

只有非常小的应用程序才不需要第三方库或框架。但在代码中重复使用外部依赖项意味着这些依赖项中存在的错误和漏洞也会成为应用程序的一部分。因此，在应用程序构建过程中，应该整合依赖项扫描。软件包管理工具，如 npm、maven、go 等，可以将漏洞数据库与应用依赖关系相匹配，并提供有用的警告。

3. 使用镜像扫描工具来分析容器镜像

应用程序构建完成后，通常会被打包成为容器镜像。用户可以使用镜像扫描工具来分析容器镜像，以此来发现操作系统包（rpm、dpkg、apk 等）中的漏洞，以及 Java、Node、Python 等软件包依赖项中的漏洞。

镜像扫描很容易实现自动化，并进行强制执行。可以将镜像扫描纳入 CI/CD 过程中，当新的镜像被推送到镜像仓库时会触发镜像扫描，或者在集群准入控制器中进行验证，以确保不符合要求的镜像不允许运行。

4. 避免常见的配置错误

如果主机、容器运行时、集群或云资源配置错误，很可能会导致攻击。一些常用基准、最佳实践和加固指南为我们介绍了如何发现这些错误配置，其中，CIS 基准是一个非常重要的基准。CIS 是一个非营利组织，为许多不同的环境发布免费基准，目前已经成为事实上的安全基准标准。为了确保高效检查此类容器安全配置，可以进行自动化检查。青藤蜂巢基于 CIS Benchmark 的 Docker 和 Kubernetes 基准要求，涵盖多版本主流操作系统、Web 应用、数据库等，可以自动化检查一些常见安全配置错误。

5. 整合 IaC 扫描

云资源管理起来纷繁复杂，而像 Terraform 或 CloudFormation 这样的工具有助于缓解这一重担。基础设施即代码（IaC）存储在存储库中并在存储库中进行版本更新，通过自动化功能实现规定的变化更新，让现有基础设施与声明保持一致。如果用户使用了基础设施即代码，可以结合 IaC 扫描工具，如 Apolicy、Checkov、tfsec 或 cfn_nag，在创建或更新基础设施之前验证其配置。

6. 通过主机扫描来确保主机安全

保护主机安全与保护容安全同样重要。运行容器的主机通常是由含有 Linux 内核的操作系统、存储库、容器运行时以及其他在后台运行的公共服务组成。这些内容中的任何一个组件都可能存在漏洞或配置错误，并可能被用作访问正在运行的容器的入口点或造成拒绝服务攻击。通过主机扫描工具可以检测出内核、标准库、甚至是在主机上运行的容器中的已知漏洞。

保护阶段：安全运行容器

7. 资源保护

容器和主机都可能含有漏洞，而且不断有新的漏洞被发现。然而，危险不在于主机或容器漏洞本身，而在于攻击向量和可利用性。因此，限制可以访问主机、云账户和资源的用户数量，并通过使用不同的机制阻止不必要的网络流量。

● 通过云提供商的 VPC、安全组、网络规则、防火墙规则等，限制虚拟机、VPC 和互联网之间的通信。

● 通过主机层面的防火墙，只暴露最小服务集。

● 集群中的 Kubernetes 网络策略和其他工具，如服务网或 API 网关，可以增加一个额外的安全层来过滤网络请求。

8. 限制运行时的容器权限

容器内可利用的漏洞的影响范围主要取决于容器的权限，以及与主机和其他资源的隔离程度。运行时配置可以通过以下方式减轻现有和未来漏洞的影响。

● 有效用户。 不要以 root 身份运行容器。最好是使用随机 UID（如 Openshift），不映射到主机中的真实用户，或者在 Docker 和 Kubernetes 中使用用户命名空间功能。

● 限制容器权限。Docker 和 Kubernetes 提供了删除 Linux Capabilities 的方法，不允许存在特权容器。Seccomp 和 AppArmor 可以对容器的可执行操作范围添加更多限制。

● 增加资源限制。 避免容器消耗所有的内存或 CPU，导致其他应用程序饿死。

● 要小心共享存储或卷。 特别是像 hostPath 这样的东西，以及从主机上共享文件系统。

● 其他选项如 hostNetwork、hostPID 或 hostIPC：Kubernetes 让容器与主机共享一个命名空间，减少隔离，很容易造成容器逃逸。

● 定义 Pod 安全策略（PSPs）和安全上下文约束（Openshift 的 SCCs）。 在集群中设置护栏，防止容器配置错误。PSP 和 SCC 是准入控制器，在安全上下文不符合定义的策略时，拒绝创建 Pod。

9. 有效管理容器漏洞

不是所有的漏洞都有修复措施，也不是所有的漏洞现在就能轻易被利用，此外，有些漏洞可能需要对主机进行本地甚至物理访问才能被利用。这时就需要良好的漏洞管理策略，包括：

● 优先考虑需要修复的内容。 我们应该专注于分数或严重程度较高的主机和容器漏洞，这通常意味着它们可以远程利用，并且有公开的利用方法。如果是旧的、众所周知的漏洞，那么它们被利用的可能性就很大。

● 评估环境中漏洞的严重程度。 供应商或 Linux 发行版提供的分数或严重程度具有很好的参考价值。但是，如果一个漏洞可以被远程利用，并且存在于暴露于互联网的内部主机的软件包中，那么应该给这个漏洞一个较高的评分。评估上下文中的影响，并制定相应的漏洞评估计划。

● 规划好修复措施，以保护容器和主机。 创建和跟踪工单系统，将漏洞管理纳入标准开发工作流程之中。

● 在确定没有受到影响时，可以忽略该漏洞。 这会减少噪音。可以考虑短期内忽略该漏洞，而不是永久性地忽略，这样就可以在以后进行重新评估。

检测阶段：异常行为告警

防御和保护阶段的安全措施可以有效限制攻击者的行动范围，但攻击总是会发生，问题只是何时会发生。因此，我们需要检测异常和意外行为，以便采取纠正措施，防止安全事件再次发生。MITRE ATT&CK 提供了一个广泛的 " 基于现实世界观察 " 的战术和技术清单，既可以用来采取预防措施，也可以用来分析活动以检测异常行为。而且，MITRE ATT&CK 容器矩阵涵盖了专门针对容器的攻击技术。《云原生安全技术实践指南》对针对容器和 K8S 的攻击技术进行了详细解析。

10. 设立实时事件和日志审计

通过审计不同来源的日志和事件，并分析异常活动，可以发现对容器安全的威胁。事件的来源包括：

● 主机和 Kubernetes 日志

● 云日志（AWS 的 CloudTrail、GCP 的 Activity Audit 等）

● 容器中的系统调用

11. 监控资源

资源使用量过大（CPU、内存、网络）、可用磁盘空间快速减少、错误率超过平均水平或延迟增加，可能表示系统中正在发生一些异常情况。可以利用 Prometheus 工具等收集指标。配置警报，在数值超过预期阈值时迅速收到通知。使用仪表盘来观测指标的演变，并与系统中发生的其他指标和事件的变化关联起来。

响应阶段：事件响应与取证

12. 隔离和调查

在检测到系统中发生了安全事件后，就要采取行动阻止威胁并限制进一步造成损害。不要只是杀死容器或关闭主机，而是考虑隔离、暂停、拍摄快照。通过取证分析，我们可以通过很多线索来搞清楚发生了怎样的入侵、何时发生的、如何发生的。

13. 解决配置错误问题

导致主机、容器或应用程序被攻击的原因可能是配置不当，如权限过高、暴露了端口或服务，或漏洞利用。如果是错误配置引起的，则可以修复错误的配置以防止再次发生此类攻击。如果是漏洞利用，也许可以通过改变配置来防止漏洞被利用（或至少限制其范围），如防火墙、增强用户限制、用额外权限或 ACL 保护文件或目录等。

14. 漏洞补丁

虽然漏洞数量非常大，但用户还是要尽可能修复漏洞：

● 对于操作系统软件包（dpkg、rpm 等）。 首先检查发行商提供的更新版本中是否包含了修复程序。如果有，要更新软件包或容器的基础镜像。

● 较旧的发行版本。 供应商有时会停止提供更新版本和安全修复，因此，用户需要提前确认使用的是供应商支持的版本。

● 对于语言包，如 NodeJS、Go、Java 等。 检查依赖项的更新版本。如果没有办法确认进行重大版本更新会给业务造成多大影响，可以先进行小版本更新，修复一些简单的安全问题。

● 发行版不提供补丁版本。 仍然有可能存在一个修复程序，可以手动应用或回传。这可能会麻烦一些，但对于那些对系统至关重要的软件包，以及还没有官方固定版本的情况下，还是有必要的。

总结

容器作为云原生时代一项新的基础设施，面临着新的安全风险，需要新的安全防护措施。本文提出的针对 DevOps 流程的 14 项容器安全最佳实践，是针对云原生时代容器的特定环境与风险提出的，对于确保容器安全运行发挥着重要作用。