基于DevOps的容器安全实践

导读	虽然云和容器的崛起,容器成了日常。容器的安全要求也随之而来，如何确定一个最适合业务的容器安全保障是大家最关注的问题。本文我们就来通过DevOps生命周期来全面考虑容器安全和各阶段的安全策略

每个安全计划都会受到可实施安全控制措施的限制，DevOps生命周期是以下各项的无限迭代：计划、编码、构建、测试、发布、部署、运维、监控

在应用程序中容器以Dockerfiles的形式来表达，但实际上Dockerfiles并不是容器的一部分(计划和编码)。从安全性的角度来看，容器安全主要涉及以下三部分，六个阶段：

构建时：构建，测试和发布

容器基础架构：部署和运维

运行时：监控

每个安全策略只有在可以实施的情况下才有效。每个部分中的各个步骤可以实施安全控制措施：

构建时：CI/CD基础结构，容器注册表

容器基础设施：容器编排器

运行时：生产环境

在容器构建时，输入了一堆源文件和一个Dockerfile，输出为Docker镜像。该阶段有很多安全和云厂商提供了很多安全方案和镜像安全扫描工具。容器安全扫描非常重要，是的，光镜像扫描还远远不够。本部分的安全目标是最小化供应链攻击的风险。

首先，检查镜像的基础，重点是检查要引入的依赖项：

允许开发人员使用的基本镜像。

固定软件依赖性，依赖所要拉取的源。

是否需要通过标签来简化治理和合规性?

整理Dockerfile。

所有这些检查都是静态的，可以很容易在构建管道编写检查语实现。

然后,下一步就是扫描容器镜像。

不要在构建管道中扫描镜像，而是在容器注册表中设置连续扫描。

漏洞可能早就存在，如果在构建时才检查有点迟了。其次，构建是叠加的：每个构建都会生成一个新镜像。因此，通过扫描信任注册表，发布的每个标签都可以信任，而无需重复在每次构建时候都检查。最后由于镜像扫描需要时间，如果在构建时候扫描会影响构建的性能。

也可以考虑定义补丁程序管理和保质期流程：

补丁程序管理：扫描结果提供补丁程序，从而产生新版本的镜像

保质期：对于超过期限未修补/旧/不安全的镜像从注册表中予以删除。

本阶段可参考的工具：开源工具有Anchore,Clair,Dagda，商业化软件有Atomic和Docker Cloud。

容器基础结构由所有移动部件组成，这些部件负责从注册表中提取镜像并将其作为容器在生产环境中运行。

主要是容器编排器有 kubernetes，Swarm。

本部分的目标有两个：避免由于平台配置错误带来安全隐患;最小化来自受感染容器的攻击扩展。

容器编排器非常复杂，特别是K8S。截至目前，它们还没有实现DevOps的承诺。每个复杂的平台都容易配置错误，这是我们要关注的部分。

必须对基础架构进行威胁建模，以确保其不会被滥用。这个特定的线程模型应该专注于每个角色，但容器除外。取决于运行情况。对于K8S而言，这进行威胁建模的一个很好的起点。

也可以使用托管平台，可以与(受信任的)供应商一起使用共享责任模型，则可以降低复杂性。

接下来，我们要将讨论容器被破坏时会发生什么。我们希望最大程度地减少攻击者横向扩展的能力，重点是两个方面：网络和身份和访问管理。

容器网络图省事而放通设置。可以先将所有内容严格划分为子网，然后逐步发展为完整的服务网络。

在IAM层上，朝着每个容器具有单一标识的方向进行操作，以微调授权授权。这在多租户平台中尤其重要：没有精细的身份，就不可能获得最低特权。

容器基础不变的，可以通过周期性关闭旧容器，新起容器的方法，避免长期运行的容器来减少攻击者横向扩展并获得持久性注入点。

本部分可以使用的开源工具有Habitat.sh，firejail等。

最后一方面是正在运行的工作负载的安全性。本阶段目标是尽量减少从受损的容器的攻击。

控制攻击影响的最佳方法是最大程度地减少从漏洞发生到安全团队收到警报的时间。

检测到持续的违规行为是有大量供应商大量解决方案的领域。有许多方法，其中大多数将需要边缘节点和守护程序集来主动监视pod的流量和系统调用。

建议是快速开始并反复进行迭代完善：使用现有的SIEM，提取平台，应用程序和审核日志。

肯定会有事件发生，然后对其进行响应处理，积累经验：

时常考虑这样的问题：”下次如何更快地检测到这种况?”这能使我们识别盲点，然后将其用于了解缺失的环节以及建立更完善的策略。

本部分可以使用的开源工具有Sysdig falco, OpenSCAP，Grafeas等。

容器安全性是一个广泛的问题，而不仅仅是扫描镜像。通过建立并用于推理容器风险和解决方案的模型才能全面完整的考虑到所有方面，当然和所有模型一样，需要不断实践迭代完善，才能建立完善的容器安全模型。