之前的文章中，我们提及了容器中的镜像五大风险。对于风险存在的可能性，都会有对应的解决措施。青藤云安全表示，只有掌握了这些应对措施，才能很好的了解掌握容器安全。

一、镜像漏洞

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

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

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

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

3.策略驱动的执行：组织应能够在构建和部署过程的每个阶段创建“质量门户”，确保只允许继续执行符合组织机构漏洞和配置策略的镜像。例如，组织机构应能够在构建过程中配置规则，防止继续执行那些超过安全漏洞评分系统(CVSS)[18]评级既定阈值的漏洞。

二、镜像配置缺陷

组织机构根据安全配置最佳实践要求采用对应工具和流程来验证并强制执行合规要求。例如，应将镜像配置为以非特权用户的身份运行。应采用的工具和流程包括：

1.验证镜像配置设置，包括供应商建议和第三方的最佳实践。

2.对镜像合规状态持续不断的更新、集中报告和监控，确定组织机构级别存在的薄弱环节和风险。

3.通过选择防止不合规镜像运行，以强制执行合规性要求。

4.只使用来自可信来源的根镜像层、常用更新版本、以及从极简技术(如Alpine Linux和Windows Nano Server)中选择根镜像层，减小攻击面的大小。

对镜像配置的最后建议是，在容器内决不能启用SSH和其它旨在向主机提供远程shell的远程管理工具。容器应以不可变的方式运行，以便从其使用中获得最大的安全效益。通过这些工具启用远程访问容器意味着一定程度的更改，这违反了该原则，并使容器面临更大的网络攻击风险。相反，所有容器的远程管理都应该通过容器运行时的API来完成，这可以通过编排工具，或者通过创建远程shell会话连接到运行容器的主机来进行访问。

三、嵌入式恶意软件

组织机构应持续监控所有镜像的嵌入式恶意软件。监控过程应包括使用恶意软件签名库，以及基于大量实际的非现场攻击的行为检测。

四、嵌入式明文秘钥

秘钥应存储在镜像之外，并在运行时根据需要动态提供。大多数编排工具，如Docker Swarm和Kubernetes，包含原生的秘钥管理方法。这些编排工具不仅安全存储秘钥并向容器“及时”注入，而且还使构建和部署过程中集成秘钥管理变得更加简单。例如，组织机构可以使用这些工具将数据库连接字符串安全地提供给Web容器。编排工具可以确保只有Web容器能够访问该秘钥，并且不会将其持久化到磁盘，而是在部署Web应用时提供该秘钥。

组织机构还可以将其容器部署与现有的在非容器环境中企业机密管理系统集成在一起。这些工具通常提供用于在部署容器时安全地取回机密的API，从而消除了将它们保留在镜像中的必要性。

无论选择什么工具，组织机构都应确保基于预先定义和管理员控制的设置，只将秘钥提供给需要它们的具体容器，并且秘钥在静止状态下总是加密的，在传输中使用联邦信息处理标准(FIPS)140批准的密码算法。

五、使用不可信镜像

组织机构应维护一组可信镜像和镜像仓库，并确保仅允许该组镜像在其环境中运行，从而降低部署不可信或恶意组件的风险。

为了降低这些风险，组织机构应采取多层次的方法，包括：

· 能够集中控制在其环境中需要信任哪些具体的镜像和镜像仓库;

· 使用NIST认可的措施，通过加密签名对每个镜像进行单独标识6;

· 强制执行，以确保环境中的所有主机仅运行已批准列表中的镜像;

· 在镜像执行前验证镜像签名，以确保镜像来自可信来源且未被篡改;

· 对这些镜像仓库进行持续监控和维护，确保随着漏洞和配置要求的变化维护和更新存储库中的镜像。

以上五点，详细的介绍了对于容器风险可做的应对措施。青藤云安全表示，掌握了如上几点，便可以更好的掌握容器技术。