CRD实现自动化容器安全

CRD的优势

为了利用容器工具所提供的各项优势，我们的团队使用了NeuVector CRD，并在NeuVector容器安全平台内定义了各种安全策略。

• 首先通过CRD，我们让这些策略能够捕获应用程序最初的正常与合法行为，并以此建立一个完整的配置档案(profile)。
• 接着，CRD将这些行为列入白名单，其中包括：与应用程序的标准操作相一致的所有网络规则、流程、协议、以及文件活动。
• 最后，在应用程序的容器环境内，CRD通过只允许那些获批的网络连接(使用ISO第7层的应用协议，进行识别与检查)来提供安全性，并拒绝任何异常的外部连接。

据此，我们的策略便能够防止攻击者试图利用内部或外部的通信连接，进入应用程序所在的生产环境。

CRD既允许我们基于全局或每一个服务，来定义不同的规则;又通过支持RBAC，使我们能够利用本地的Kubernetes服务帐户与角色，来实施各项安全策略。同时，它的版本控制功能也有助于我们跟踪每一个应用程序修订版的策略。另外，诸如Open Policy Agent之类的安全策略管理工具，也能够按需支持各类集成。

创建NeuVector CRD

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和安全策略即代码的定义能力，应该能够为DevOps、DevSecOps、以及开发团队带来更好的安全性。我们可以从如下四个方面着手进行实践：

将开发和测试清单尽早导入应用的生命周期中

通过为应用程序创建部署与安全清单，开发人员能够在开发的初期尽早的利用CRD来保障安全性。在完成镜像的构建、自动化漏洞扫描、以及DevOps的审查之后，DevOps人员可以通过测试这两份清单，来为开发人员提供有效的安全性反馈。

因此，从最初到被部署到生产环境中，有效的安全策略始终伴随着新的应用程序。

使用行为学习来创建安全策略。

DevOps团队可以在测试环境中使用NeuVector的行为学习功能，来定义安全策略，并创建针对NeuVector CRD的YAML格式文件。通过如下的工作流(从图的右下角开始)，DevOps和QA团队就能够将应用程序顺利地部署到测试与QA环境之中。也就是说，应用程序在此将完成全部与行为相关的配置文件，其中包括：产生适当的网络、流程、以及文件访问的安全性规则等。

在部署到生产环境之前，开发人员可以将新创建的规则导出为YAML格式，以便进行检查、编辑、以及开展DevOps的相关测试。

（编辑：三门峡站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!