本文讲的是容器安全与DevSecOps：一些不再适用的旧规则【编者的话】如何保证容器环境的安全性，从根本上保证杜绝未授权的变更呢？作者认为，将安全控制流程的时间提前是一个不错的办法。
【深圳站｜3天烧脑式Kubernetes训练营】培训内容包括：Kubernetes概述、架构、日志和监控，部署、自动驾驶、服务发现、网络方案等核心机制分析，进阶篇——Kubernetes调度工作原理、资源管理及源码分析等。
有关容器环境的一个常见问题是，如何保证只有授权过的镜像才能作为容器运行呢？各种产品和开发团队在这个问题上花了不少心思，想要把软件和配置的那一套标准应用到容器管理中。
在传统的IT环境中，有两个进程可以并行：一个是软件开发（dev.），另一个是软件运行环境的基础设施运营（ops.）。针对这两个进程，已经有成熟的安全控制措施。
上述两个过程独立进行，只有当新开发的软件安装到基础设施上之后，二者才有交集。最重要的是，如果基础设施配置出了问题，基本上会在安全控制和运营过程中得到妥善处理，很少会影响到软件开发。
为了保证代码安全，第一步并不是简单的将其过渡到容器应用中，之后的控制步骤需要根据容器化环境进行调整。
这就是说，基础设施的安全方法唯一可以应用到的地方就是在镜像的创建过程中。因为一旦镜像完成部署，就没有改动的余地。
不用等到开发和一体化进程完成后再进行迭代评估、修补和配置调整，安全控制需要在第一时间进行，即在镜像创建之后，在进一步的CI/CD（持续集成和持续交付）过程之前。这就是“把安全控制挪到前面来”这句话表达的真正意思。
在此过程中，需要执行基础设施安全方针中的所有要素，这点非常重要，同时，还有一些针对容器镜像的方针：
理想情况下，这些方针与当前的物理、虚拟或者云上的主机中所应用的是对应的。例如，镜像不可接受的漏洞清单和评估服务器合规性的漏洞清单基本上是一样的。
容器化环境的实现看起来不太现实。它同时要求动态性和一致性。有了容器之后，主机不再是必须的，因为主机已经没有有效荷载或配置的意义了（容器引擎除外）。同时，对运行中的容器进行变更也不再是必须的，因为当编排或重新创建容器会覆盖掉这些变更。总之，以后再也不用进行传统意义上的变更了。
在需要进行变更的地方，只需要重新构建新的镜像来替代、增加或是修补想要改动的容器，使之切合预期。如果把安全控制引入这一过程并能够有效运作，之前觉得不可能的事情就会得以实现：在根本上创造了更多的安全应用，比以往更快更高效。
【深圳站｜3天烧脑式Kubernetes训练营】培训内容包括：Kubernetes概述、架构、日志和监控，部署、自动驾驶、服务发现、网络方案等核心机制分析，进阶篇——Kubernetes调度工作原理、资源管理及源码分析等。
有关容器环境的一个常见问题是，如何保证只有授权过的镜像才能作为容器运行呢？各种产品和开发团队在这个问题上花了不少心思，想要把软件和配置的那一套标准应用到容器管理中。
在传统的IT环境中，有两个进程可以并行：一个是软件开发（dev.），另一个是软件运行环境的基础设施运营（ops.）。针对这两个进程，已经有成熟的安全控制措施。
- 静态代码分析工具通过评估源代码，检查常见错误，规范编码标准来保证软件开发安全
- 服务器评估工具通过检查操作系统和其他组件的版本，扫描漏洞和补丁级别，规范配置标准来保证基础设施运营的安全
上述两个过程独立进行，只有当新开发的软件安装到基础设施上之后，二者才有交集。最重要的是，如果基础设施配置出了问题，基本上会在安全控制和运营过程中得到妥善处理，很少会影响到软件开发。
为了保证代码安全，第一步并不是简单的将其过渡到容器应用中，之后的控制步骤需要根据容器化环境进行调整。
容器：新的规则，新的安全流程
容器把所有的操作系统组件、必备组件和相关设置都嵌入到镜像当中。一旦镜像被建好和传输（ship），之后就不应该再有变动。运行状态的容器不允许调整配置、修补和替换组件。修改镜像内部环境的唯一方式就是重建新镜像。这就是说，基础设施的安全方法唯一可以应用到的地方就是在镜像的创建过程中。因为一旦镜像完成部署，就没有改动的余地。
安全问题需要引起重视
嵌入基础设施的安全控制在很大程度上，或者说是在根本上改变了创建流程。这种方式把当前的安全控制流程完全的转移了。不用等到开发和一体化进程完成后再进行迭代评估、修补和配置调整，安全控制需要在第一时间进行，即在镜像创建之后，在进一步的CI/CD（持续集成和持续交付）过程之前。这就是“把安全控制挪到前面来”这句话表达的真正意思。
在此过程中，需要执行基础设施安全方针中的所有要素，这点非常重要，同时，还有一些针对容器镜像的方针：
- 根据基准镜像（模板）创建镜像
- 服务器软件组件可以接受一定程度上的漏洞
- 服务器软件组件是满足条件的最低版本 镜像操作系统的配置满足组织标准
- 镜像元数据包括要求元素、用户环境设置和入口点设置。
理想情况下，这些方针与当前的物理、虚拟或者云上的主机中所应用的是对应的。例如，镜像不可接受的漏洞清单和评估服务器合规性的漏洞清单基本上是一样的。
是时候更新安全控制了
很久以来，安全组织都在关注未授权的变更。跳转服务器、特权身份管理、管理日志、变更窗口以及根因分析，这些手段都是为了检测和防止对软件组件及其配置进行未授权的变更。对主机进行内部和外部双重连续漏洞评估，是为了能及时衡量IT基础设施中不可避免的变更。容器化环境的实现看起来不太现实。它同时要求动态性和一致性。有了容器之后，主机不再是必须的，因为主机已经没有有效荷载或配置的意义了（容器引擎除外）。同时，对运行中的容器进行变更也不再是必须的，因为当编排或重新创建容器会覆盖掉这些变更。总之，以后再也不用进行传统意义上的变更了。
在需要进行变更的地方，只需要重新构建新的镜像来替代、增加或是修补想要改动的容器，使之切合预期。如果把安全控制引入这一过程并能够有效运作，之前觉得不可能的事情就会得以实现：在根本上创造了更多的安全应用，比以往更快更高效。
原文链接：Container Security and DevSecOps: The Old Rules No Longer Apply（翻译：马远征)
原文发布时间为：2017-04-24
本文作者：马远征
本文来自云栖社区合作伙伴Dockerone.io，了解相关信息可以关注Dockerone.io。
原文标题：容器安全与DevSecOps：一些不再适用的旧规则
