| 长久以来，安全一直是困扰着许多DevOps团队(包括我自己供职的加拿大保险和金融服务合作社)的症结所在。尽管在各种工具的帮助下，我们的CI/CD管道的绝大部分都已经实现了自动化，而且基于容器的自动化应用部署也是我们的常态，但是在安全方面的自动化程度仍然比较落后。与大多数DevOps团队一样，我们实施了自动化的漏洞扫描，但是在手动构建安全策略，以保护生产环境中的应用程序、及其工作负载方面仍存在着一定的问题。 |
可喜的是，如今Kubernetes的自定义资源类型(custom resource definitions，CRDs)，却能够使我们的团队通过自己的管道，尽早地将应用程序的安全策略声明融入代码，并将此类安全策略自动化地部署到生产环境中。
目前，我们通过CRD引入了各种全局安全策略。这些策略预定义了应用程序的允许行为，并在多个Kubernetes集群之间实施了不同的防护措施。通过使用CRD来自动化且集中化地管理安全策略即代码(security policy as code)，我们既可以加强与简化策略的执行，又能够以高效、容错且安全的方式部署和更新各种应用程序。
下面，我们将分享本企业是如何实现应用安全策略的自动化：
为了利用容器工具所提供的各项优势，我们的团队使用了NeuVector CRD，并在NeuVector容器安全平台内定义了各种安全策略。
- 首先通过CRD，我们让这些策略能够捕获应用程序最初的正常与合法行为，并以此建立一个完整的配置档案(profile)。
- 接着，CRD将这些行为列入白名单，其中包括：与应用程序的标准操作相一致的所有网络规则、流程、协议、以及文件活动。
- 最后，在应用程序的容器环境内，CRD通过只允许那些获批的网络连接(使用ISO第7层的应用协议，进行识别与检查)来提供安全性，并拒绝任何异常的外部连接。
据此，我们的策略便能够防止攻击者试图利用内部或外部的通信连接，进入应用程序所在的生产环境。
CRD既允许我们基于全局或每一个服务，来定义不同的规则;又通过支持RBAC，使我们能够利用本地的Kubernetes服务帐户与角色，来实施各项安全策略。同时，它的版本控制功能也有助于我们跟踪每一个应用程序修订版的策略。另外，诸如Open Policy Agent之类的安全策略管理工具，也能够按需支持各类集成。
NeuVector CRD允许您使用Kubernetes的本地YAML文件来创建各项安全规则。
首先，您需要创建一个NeuVector CRD。如下图所示，我们使用YAML代码创建了一个CRD。同时，我们为NvSecurityRule定义了一个namespaced域，并将NvClusterSecurityRule的域范围定义为能够跨集群进行操作
我们通过运行如下命令来创建CRD：
- 有了NeuVector CRD之后，所有由NvSecurityRule类型调用的自定义资源，现在都可以交由CRD来处理。因此，您可以继续创建各种自定义的资源，来定义更多的安全策略。不过在此之前，请参考NeuVector的相关文档，以添加所有必需的clusterroles和clusterrolebindings。
另外，CRD可以在Kubernetes内部部署原生的、启用了RBAC的NeuVector安全规则。那些由CRD为特定的名称空间所声明的安全策略，只能由具备部署到工作区权限的服务帐户来执行。同样地，服务帐户必须具有适当的群集管理员权限，才能够跨名称空间部署那些群集范围的CRD定义。
以下是demo-security-v1.yaml文件的代码片段。它使用HTTP协议，来限制demo名称空间中的nginx-pod容器，去连接同一名称空间中的node-pod容器。
除了上述代码段，yaml文件还应该继续指定demo名称空间中各个容器所允许的所有网络连接，使用Redis协议的网络连接，以及每个容器允许的进程与文件活动。在部署应用程序之前，您可以通过将它们部署到NeuVector中，以提前准备好安全规则。此举可让应用程序在开始运行之时，就已经激活了相应的安全属性。
请参照如下命令部署您的安全策略：
- NeuVector会在新创建的自定义资源中解析安全策略，并继续对NeuVector Controller进行REST API的调用。该Controller会按需在NeuVector中通过创建规则和配置，以实施各项策略。
另外，CRD可以在Kubernetes内部部署原生的、启用了RBAC的NeuVector安全规则。那些由CRD为特定的名称空间所声明的安全策略，只能由具备部署到工作区权限的服务帐户来执行。同样地，服务帐户必须具有适当的群集管理员权限，才能够跨名称空间部署那些群集范围的CRD定义。
以下是demo-security-v1.yaml文件的代码片段。它使用HTTP协议，来限制demo名称空间中的nginx-pod容器，去连接同一名称空间中的node-pod容器。
除了上述代码段，yaml文件还应该继续指定demo名称空间中各个容器所允许的所有网络连接，使用Redis协议的网络连接，以及每个容器允许的进程与文件活动。在部署应用程序之前，您可以通过将它们部署到NeuVector中，以提前准备好安全规则。此举可让应用程序在开始运行之时，就已经激活了相应的安全属性。
请参照如下命令部署您的安全策略：
- NeuVector会在新创建的自定义资源中解析安全策略，并继续对NeuVector Controller进行REST API的调用。该Controller会按需在NeuVector中通过创建规则和配置，以实施各项策略。
我个人认为：CRD和安全策略即代码的定义能力，应该能够为DevOps、DevSecOps、以及开发团队带来更好的安全性。我们可以从如下四个方面着手进行实践：
通过为应用程序创建部署与安全清单，开发人员能够在开发的初期尽早的利用CRD来保障安全性。在完成镜像的构建、自动化漏洞扫描、以及DevOps的审查之后，DevOps人员可以通过测试这两份清单，来为开发人员提供有效的安全性反馈。
因此，从最初到被部署到生产环境中，有效的安全策略始终伴随着新的应用程序。
DevOps团队可以在测试环境中使用NeuVector的行为学习功能，来定义安全策略，并创建针对NeuVector CRD的YAML格式文件。通过如下的工作流(从图的右下角开始)，DevOps和QA团队就能够将应用程序顺利地部署到测试与QA环境之中。也就是说，应用程序在此将完成全部与行为相关的配置文件，其中包括：产生适当的网络、流程、以及文件访问的安全性规则等。
在部署到生产环境之前，开发人员可以将新创建的规则导出为YAML格式，以便进行检查、编辑、以及开展DevOps的相关测试。
值得注意的是：通过启用全局安全策略的定义方式，NeuVector CRD既可以为那些未连接到任何特定应用的负载，又可以不针对集群中的某个特定负载予以分组。例如：安全、合规或运营团队可能需要定义网络出、入口的全局安全规则，以阻止某些进程横跨各个容器，或是允许某些进程对于整个集群中的监控与诊断。
因此，通过结合使用全局策略，和那些特定于某个应用的策略，整个团队就可以制定出本组织真正所需的精确规则。如下图所示，我们用如下规则来拒绝来自容器的SSH连接。
通过使用NeuVector CRD，您可以将全部或是某些选定的安全策略，从研发阶段自动化迁移到生产环境中。在NeuVector控制台中，您可以通过配置“New Services Mode”，来发现、监视或保护各种设置。通过选择“Monitor”或“Protect”，您可以确保所有新部署的、或更新的服务，在激活之前，都必须包含必需的安全规则。
综上所述，通过利用Kubernetes CRD、以及安全策略即代码，开发团队和DevOps团队能够确保从开发伊始到生产部署，都能够得到安全自动化的“加持”，进而为应用程序提供更好的保护。
来源：oschina
链接：https://my.oschina.net/u/3585265/blog/4327176