基于身分的部署控制仰赖人的操作知识与信任，在容器微服务爆发的现在，特别是在企业自动化构建与发布的基础架构，数十个团队每天部署数百次。容器化的工作负载一般来说并不鼓励直接修改正在运行的软件，应该使用持续整合和持续部署（CI/CD），把改变应用到整个容器中，而这允许使用者定义精简的测试与验证，确保只部署受信任的代码。

但即使是这种基于身分的部署控制，内部人员仍可能绕过CI/CD的控制，恶意或是不小心部署了不受信任的代码，例如开发者可能意外地部署测试用程序到生产环境中，或是想要偷懒的员工，可能会绕过测试或整合验证程序，另外，也很有可能恶意的在软件构建过程中植入了挖矿代码。而Google新推出的这个二进制授权可以填补以上的安全漏洞。

二进制授权是Google内部用来保护生产部署的技术，已经使用了将近十年。二进制授权仅运行受信任的代码来建立预防性安全状态，从程序码开发到生产，采用单一结构化路径简化治理，并使用开源软件来维持CI/CD工具的可插拔性与互通性。

通过将企业部署要求整合到CI/CD各阶段，镜像通过这些阶段时便会取得该阶段签章，当镜像取得所有阶段的签章则获得部署授权，否则二进制授权会阻挡不符合标准的镜像。在Kubernetes中，是使用ImagePolicy授权控制器来实现，并以容器分析API（Container Analysis API）来验证这些镜像上的签章。二进制授权也与Cloud Audit Logging整合，纪录Pod失败创建供日后调阅。

除了基于签章的验证外，二进制授权也支援使用名称模式的白名单镜像，使用者可以通过路径指定特定的代码储存库，或是一系列允许部署的镜像。Google认为，这是另一个好选择，企业不只可以快速开始限制生产部署，还能控制那些未遵循内部工作流程的第三方镜像。

二进制授权使用标准加密PGP签章，而这将允许使用者轻易的整合CI/CD工具链，包括构建、测试与漏洞搜寻等各阶段。当然，除了使用者可以定制化整合外，二进制授权也提供了开箱即用的服务，用户可以直接使用Google或是合作伙伴开发的CI/CD和安全工具。

Google提到，使用者也可以自行实作二进制授权，只要使用开源项目Grafeas自订策略，并根据要求允许或是阻止Pod的创建。作为二进制授权测试版发布的一部分，Google更新了开源引擎Kritis，Kritis能使用授权控制器在任何Kubernetes部署中，强制遵循Pod创建策略。而Kritis与开源Grafeas整合，就可以在Google Kubernetes引擎部署中，使用容器注册表容器分析API和二进制授权，如此一来，使用者可以在自家机房中，使用开源软件建立一致的控制流程。

原文来自：

本文地址：//gulass.cn/google-kubernetes-ci-cd.html编辑：向云艳，审核员：逄增宝

Linux大全：

Linux系统大全：

红帽认证RHCE考试心得：