NeuVector部署、使用与原理分析

IronmanJay

于 2024-10-09 20:11:38 发布

阅读量1.2k

点赞数 38

分类专栏：应用漏洞检测工具网络安全文章标签： NeuVector 漏洞检测渗透测试应用漏洞检测靶机测试开源容器安全平台企业级零信任安全解决方案

本文链接：https://blog.csdn.net/IronmanJay/article/details/142674991

版权

网络安全同时被 2 个专栏收录

46 篇文章 14 订阅

订阅专栏

应用漏洞检测工具

10 篇文章 0 订阅

订阅专栏

文章目录

前言
1、概述
2、安装与使用
3、测试用例
- 3.1、Pod间通过网络策略相互隔离
- 3.2、行为监控
4、总结
5、参考文献
总结

前言

本博客的主要内容为NeuVector的部署、使用与原理分析。本博文内容较长，因为涵盖了NeuVector的几乎全部内容，从部署的详细过程到如何使用NeuVector进行漏洞检测，以及对NeuVector进行漏洞检测的原理分析，相信认真读完本博文，各位读者一定会对NeuVector有更深的了解。以下就是本篇博客的全部内容了。

1、概述

NeuVector是业界首个端到端的开源容器安全平台，唯一为容器化工作负载提供企业级零信任安全的解决方案。NeuVector可以提供实时深入的容器网络可视化、东西向容器网络监控、主动隔离和保护、容器主机安全以及容器内部安全，容器管理平台无缝集成并且实现应用级容器安全的自动化，适用于各种云环境、跨云或者本地部署等容器生产环境。具体来说，NeuVector的功能包括：

安全漏洞管理：
- 定义：安全漏洞管理涉及检测和处理容器镜像中的已知漏洞。这包括识别镜像中使用的软件包或库的已知漏洞，并提供修复建议。
- 功能：提供漏洞扫描工具，检查容器镜像中的软件组件，并通报已知的漏洞。管理员可以获得有关漏洞的详细信息，并采取措施修复或替代受影响组件。
合规性检查和机密性检查：
- 定义：合规性检查确保容器化工作负载符合相关的合规性标准和安全政策。机密性检查则涉及防止敏感信息泄露。
- 功能：提供工具进行合规性扫描，以确保容器环境符合特定的法规和标准。机密性检查则包括对容器内部的敏感信息进行审查，防止敏感数据泄露。
策略管理：
- 定义：策略管理涉及定义和执行安全策略，以规范和控制容器的行为和配置。
- 功能：允许管理员定义安全策略，例如网络策略、访问控制策略、运行时配置策略等。这确保容器按照规定的规则和标准进行操作。
准入控制策略：
- 定义：准入控制策略允许管理员在容器部署时定义和执行控制策略，以确保只有授权的容器可以运行。
- 功能：允许定义哪些容器可以部署，哪些容器可以访问特定服务，以及哪些容器可以与其他容器通信。这有助于限制容器的行为和减少潜在的攻击面。
动态安全响应：
- 定义：动态安全响应涉及在容器环境中及时识别并应对安全事件和威胁。
- 功能：提供实时监控和分析容器环境中的活动，以检测潜在的威胁。在发现异常或安全事件时，系统能够自动采取响应措施，例如隔离受影响的容器或阻止特定的网络流量。
行为监控：
- 定义：行为监控涉及监控容器的运行时行为，以便检测潜在的异常活动或恶意行为。
- 功能：实时监控容器的活动，例如进程启动、文件访问、网络通信等。通过分析这些行为，系统可以识别异常模式并采取相应的安全措施。

综合而言，NeuVector为容器化环境提供了全面的安全保护，涵盖了网络、运行时、威胁检测、防火墙等多个方面，帮助组织构建更安全、可靠的容器化应用环境。此外，NeuVector工具基于Go语言、C语言和Python语言开发。

以上内容是关于NeuVector的概述性内容，下面我们再来看一下NeuVector的架构。NeuVector本身包含Controller、Enforcer、Manager、Scanner和Updater五大模块，其架构图如下图所示：

在这里插入图片描述

Controller：整个NeuVector的控制模块，API入口，包括配置下发。高可用主要考虑Controller的HA，通常建议部署3个Controller模块组成集群。
Enforcer：主要用于安全策略部署下发和执行，DaemonSet类型会在每个节点部署。
Manager：提供Web-UI（仅HTTPS）和CLI控制台，供用户管理NeuVector。
Scanner：对节点、容器、Kubernetes和镜像进行CVE漏洞扫描。
Updater：用于定期更新CVE漏洞库。

2、安装与使用

软件环境	硬件环境	约束条件
Ubuntu-22.04.3-desktop-amd64（内核版本5.15.0-43-generic）	分配4个处理器，每个处理器有4个内核，处理器内核总数为16	Ubuntu 22.04.3系统的交换空间至少16GB
NeuVector部署在VMware Pro 17上的Ubuntu 22.04.3系统上，主机系统为Windows11	内存16GB	具体的约束条件可见“2.1、安装方法”章节所示的软件版本约束
具体的软件环境可见“2.1、安装方法”章节所示的软件环境	硬盘200GB	暂无
暂无	NeuVector部署在VMware Pro 17上的Ubuntu 22.04.3系统上，主机系统为Windows11	暂无

2.1、安装方法

2.1.1、部署NeuVector前的准备工作

2.1.1.1 扩容系统交换空间

由于后期部署的NeuVector工具对于内存空间要求非常高，故系统默认的交换空间完全不够我们使用，经常会出现NeuVector系统挂掉的情况。所以我们需要扩容系统的交换空间。关于扩容系统交换空间的具体做法如下所示：

首先生成交换文件：

$ sudo dd if=/dev/zero of=/swap bs=1M count=16384

然后激活交换空间：

$ sudo mkswap /swap

然后启用交换空间：

$ sudo swapon /swap

然后使用如下命令来查看内存空间是否扩容成功：

$ free -m

可以发现，内存空间已经扩容成功：
然后将“/swap”文件添加到“/etc/fstab”，以确保在每次系统启动时都会自动启用我们设置好的交换空间：

$ echo '/swap none swap sw 0 0' | sudo tee -a /etc/fstab

最后重启系统即可：

$ sudo reboot

2.1.1.2 Kubernetes单机部署

Kubernetes（通常简称为K8s）是一个用于自动部署、扩展和管理容器化应用程序的开源平台。它提供了一个容器编排和管理的完整解决方案，允许用户自动化容器的部署、扩展、缩减和运维操作。以下是一些关键的特性和概念：

容器化：Kubernetes主要用于管理和编排容器化应用程序。容器是轻量级、可移植且自包含的软件单元，可以在不同环境中运行
集群管理：Kubernetes支持在多个计算机节点上创建集群，这些节点可以是物理机器、虚拟机器或云实例。集群由Master节点和Worker节点组成
Master节点：Kubernetes集群的控制中心，负责管理和协调整个集群。包括以下主要组件：
- API Server：提供Kubernetes API，用于与集群交互
- Controller Manager：负责维护集群中的控制器（例如，ReplicaSet、Deployment等）
- Scheduler：负责将Pod调度到可用的Worker节点上
Worker节点：Kubernetes集群中的计算单元，负责运行应用程序容器。包括以下主要组件：
- Kubelet：负责在节点上运行容器，并与Master节点通信报告节点的状态
- Container Runtime：负责实际运行容器的软件，如Docker或containerd
- Kube Proxy：负责维护网络规则，允许Pod之间的通信
Pod：是Kubernetes中最小的可部署单元，通常包含一个或多个容器。Pod共享相同的网络和存储空间，可以共同协作完成一个应用程序的组件
控制器：控制器是Kubernetes中的控制单元，用于确保集群中的实际状态与期望状态一致。常见的控制器包括Deployment、ReplicaSet、StatefulSet等
服务发现和负载均衡：Kubernetes提供服务抽象，允许容器之间通过服务名进行通信。负载均衡器可自动将流量分发到运行相同服务的多个Pod
存储编排：Kubernetes支持不同类型的存储卷，并提供对存储的抽象，使得应用程序能够方便地访问存储资源
自动扩展：Kubernetes可以根据应用程序的负载自动扩展或缩减Pod的数量，以确保应用程序具有适当的资源

Kubernetes通过这些组件和概念提供了一个强大、灵活且可扩展的平台，适用于构建和管理容器化应用程序。它能够简化应用程序的部署、扩展和管理，提高开发和运维效率。

我们在部署NeuVector时需要利用Kubernetes，不过根据上面的介绍，可以发现Kubernetes适合于集群部署，不过我们本次的软硬件环境并不支持我们这么做（主要是因为太麻烦了，而且集群部署和单机部署没有区别，因为我们只是学习使用），故我们在本章节中将要部署单机版的Kubernetes，单机版的Kubernetes与集群部署的Kubernetes本质上没有区别，只是单机版的Kubernetes更适合我们学习，因为部署较为简单，且更为轻量。下面介绍一下Kubernetes的单机版。

Kubernetes的单机版通常指的是在单个计算机上运行的Kubernetes集群，这种配置通常用于开发、测试或学习目的。单机版的Kubernetes环境在一台机器上模拟了Kubernetes集群的基本结构，包括Master节点和Worker节点，以便用户可以在单机上体验Kubernetes的特性和功能
在单机版中，所有的Kubernetes组件（如API Server、Controller Manager、Scheduler等）以及应用程序的容器都运行在同一台机器上。这种配置在实际生产环境中并不常见，因为它缺乏高可用性和容错性，但在学习和开发阶段，它为用户提供了一个简便的环境
Minikube是一个常见的工具，它提供了在单机上运行Kubernetes的简便方式，通过在虚拟机中模拟整个Kubernetes集群。这种单机版配置使得开发者可以在本地机器上轻松测试和调试Kubernetes应用程序，而无需设置复杂的多节点集群。在生产环境中，通常会使用多节点的Kubernetes集群以满足可用性和性能的需求

经过以上介绍，可以发现Kubernetes的单机版已经足够我们使用了，故我们下面就会详细介绍如何部署Kubernetes的单机版。

2.1.1.2.1 部署Docker

首先顺序执行如下两条命令来下载安装Docker：

$ sudo apt-get update
$ sudo apt-get install -y docker.io

然后执行如下命令启动Docker：

$ systemctl start docker

执行完上面的命令后，需要输入当前用户的密码进行认证：
然后执行如下命令设置Docker开机自启动：

$ systemctl enable docker

执行完上面的命令后，需要输入当前用户的密码进行认证：
然后顺序执行如下几条命令来将当前用户（我测试使用的当前用户的名称为“iie-iisd”）添加到Docker用户组：

$ sudo groupadd docker
$ sudo gpasswd -a iie-iisd docker

然后关闭当前终端，再重新打开一个终端，最后重启Docker服务并更新用户组：

$ sudo systemctl restart docker
$ newgrp docker

然后执行如下命令来查看我们当前部署的Docker的版本：

$ docker --version

可以发现，我们当前部署的Docker的版本为24.0.5：

2.1.1.2.2 部署Kubectl

首先来到当前用户的根目录中下载安装curl，然后使用如下命令下载Kubectl的最新发行版。有读者可能就会问了，为什么我们要下载安装这个版本的Kubectl呢？这是因为我们在中国无法下载安装最新版的Kubernetes，能用到最新版本的Kubernetes版本只能到1.23.9版本（由阿里云仓库提供），而高版本的Kubectl又与1.23.9版本的Kubernetes不兼容，所以我们只能下载安装老版本的Kubectl（即1.23.9版本的Kubectl）以用来兼容1.23.9版本的Kubernetes：

$ cd /home/iie-iisd/
$ sudo apt-get update
$ sudo apt-get install curl -y
$ curl -LO "https://dl.k8s.io/release/v1.23.9/bin/linux/amd64/kubectl"

然后下载Kubectl校验和文件：

$ curl -LO "https://dl.k8s.io/v1.23.9/bin/linux/amd64/kubectl.sha256"

然后执行如下命令来验证Kubectl的可执行文件的完整性：

$ echo "$(cat kubectl.sha256)  kubectl" | sha256sum --check

出现如下图所示的内容，即代表Kubectl的完整性验证成功：
然后执行如下命令来安装Kubectl：

$ sudo install -o root -g root -m 0755 kubectl /usr/local/bin/kubectl

当安装完毕后，执行如下命令来查看Kubectl是否安装成功：

$ kubectl version --client

出现如下图所示的内容，即代表Kubectl安装成功，且表示我们当前安装的Kubectl版本为1.23.9：

2.1.1.2.3 部署Minikube

首先来到当前用户的根目录中，然后下载最新版本的Minikube的deb格式的安装包并将其安装：

$ cd /home/iie-iisd/
$ curl -LO https://storage.googleapis.com/minikube/releases/latest/minikube_latest_amd64.deb
$ sudo dpkg -i minikube_latest_amd64.deb

然后使用如下命令来查看当前部署的Minikube的版本：

$ minikube version

可以发现，我们部署的Minikube的版本为1.32.0：
然后指定Minikube使用Docker作为底层虚拟化技术的驱动程序：

$ minikube config set driver docker

然后执行如下命令来启动1.23.9版本的Kubernetes的单机版集群：

$ minikube start --image-mirror-country='cn' --image-repository='registry.cn-hangzhou.aliyuncs.com/google_containers' --kubernetes-version=v1.23.9 --memory 8192 --cpus 8

出现如下图红框和红箭头处所示的内容即代表1.23.9版本的Kubernetes的单机版集群部署成功：
然后执行如下命令来启用metrics-server插件。metrics-server是一个Kubernetes插件，用于收集和提供集群中各个Pod和节点的性能指标。它是Kubernetes仪表板等功能所依赖的一个重要组件：

$ minikube addons enable metrics-server

然后执行如下命令来查看当前Kubernetes的单机版集群的具体情况：

$ minikube dashboard

执行上面的命令后，会自动打开系统自带的浏览器，并来到如下图所示的界面。如果想关闭此界面，可以在打开此界面的命令行终端中按一下“Ctrl+C”并关闭打开的浏览器即可：

2.1.1.3 Helm部署

Helm是一个用于简化Kubernetes应用部署和管理的工具。它允许我们定义、安装和升级Kubernetes应用程序。以下是Helm的一些关键概念：

Chart（图表）： Helm使用图表来打包Kubernetes应用程序。一个图表是一个预定义的目录结构，其中包含了描述应用程序如何部署的文件
Release（发布）：当我们使用Helm安装一个图表时，将创建一个发布。发布是一个特定版本的图表实例，它在Kubernetes集群上运行
Repository（仓库）： Helm仓库是图表的集合，我们可以从中获取和共享图表。官方的Helm仓库包含了许多常见的应用程序图表，而我们也可以创建自己的私有仓库
Values文件： Helm允许我们使用Values文件来定制图表的配置。这些文件包含了应用程序特定的配置参数，允许我们在不修改图表的情况下自定义部署

使用Helm，我们可以更轻松地管理Kubernetes应用程序的生命周期，从而简化了部署、升级和回滚操作。此外，需要注意的是，我们之前部署的是1.23.9版本的Kubernetes，而Helm与Kubernetes之间是存在版本的对应关系的，而1.23.9版本的Kubernetes对应的Helm的版本为3.8.0，我们可以从此网站查看Kubernetes版本与Helm版本之间的对应关系。

首先来到当前用户的根目录中，下载3.8.0版本的Helm源码安装包：

$ cd /home/iie-iisd/
$ wget https://get.helm.sh/helm-v3.8.0-linux-amd64.tar.gz

然后解压3.8.0版本的Helm源码安装包，并进入解压后的目录：

$ tar -zxvf helm-v3.8.0-linux-amd64.tar.gz
$ cd linux-amd64/

进入解压后的目录后，将此目录中名为“helm”的二进制程序移动到“/usr/local/bin/”目录下：

$ sudo mv helm /usr/local/bin/helm

此时我们就完成了3.8.0版本的Helm的安装，我们可以执行如下命令查看当前安装的Helm的版本：

$ helm version

可以发现，我们当前安装的Helm的版本为3.8.0：

2.1.2、使用Helm部署NeuVector

首先来到当前用户的根目录中，并使用如下命令添加关于NeuVector的仓库：

$ cd /home/iie-iisd/
$ helm repo add neuvector https://neuvector.github.io/neuvector-helm/

然后使用如下命令来验证Helm存储库：

$ helm search repo neuvector

出现如下图所示的内容即代表关于NeuVector的仓库添加成功：
然后使用如下命令来安装NeuVector。此命令使用Helm来升级或安装名为“neuvector”的Helm Chart，该Chart位于名为“neuvector/core”的仓库，且此仓库中的该Chart的版本为2.6.6：

$ helm upgrade --install neuvector neuvector/core --version 2.6.6 \
--set tag=5.2.4 \
--set registry=docker.io \
--create-namespace \
--namespace neuvector

helm upgrade --install neuvector：这部分命令告诉Helm升级或安装名为“neuvector”的Helm Chart。如果名为“neuvector”的Helm Chart不存在，将创建它；如果存在，则将其升级。--install选项表示如果此Chart不存在，则安装
neuvector/core：这是Helm Chart的名称和存储库。在Helm中，Chart存储在仓库中，这里是“neuvector/core”
--version 2.6.6：指定要使用的Chart版本。在这里，我们要求使用版本号为2.6.6的Chart
--set tag=5.2.4：使用--set选项可以设置Helm Chart中的值。在这里，我们设置了Helm Chart中“neuvector”的版本号为5.2.4
--set registry=docker.io：同样，这是使用--set选项设置Helm Chart中的值，将registry设置为docker.io
--create-namespace：如果neuvector命名空间不存在，则创建它
--namespace neuvector：指定Helm Chart的命名空间为neuvector

执行完上面的命令后，可以得到如下图所示的输出内容，这里给我们提供了一些提示信息：
有的读者可能就会问了，就执行完这一瞬间难道就构建好了名为“neuvector”的Helm Chart吗？当然没有，我们使用如下命令来查看名为“neuvector”的命名空间中所有Pods的信息：

$ kubectl get pods --namespace neuvector

只有执行完上面的命令后，出现如下图红框处所示的内容后（或其STATUS为Completed也可以），才代表名为“neuvector”的Helm Chart已经构建成功了，否则就要继续等待，我们需要不停的执行步骤6的命令以查看名为“neuvector”的Helm Chart是否构建成功，当出现如下图红框和红箭头出所示的内容后（或其STATUS为Completed也可以），才代表名为“neuvector”的Helm Chart已经构建成功，我们才能继续向下操作：
只有当步骤7及其之前我们都成功完成后，才可以来进行当前的操作。我们只需要顺序执行如下三条命令，这三条命令就是步骤5的图片中的输出信息中给我们提示的命令：

$ NODE_PORT=$(kubectl get --namespace neuvector -o jsonpath="{.spec.ports[0].nodePort}" services neuvector-service-webui)
$ NODE_IP=$(kubectl get nodes --namespace neuvector -o jsonpath="{.items[0].status.addresses[0].address}")
$ echo https://$NODE_IP:$NODE_PORT

执行完上面的命令后，会打印如下图所示的内容（PS：其实我们现在就可以通过下图中的https://192.168.49.2:31912来访问NeuVector，不过为了介绍其它命令和知识，我们并不在这里访问NeuVector）：
然后执行如下命令来使用kubectl port-forward命令代理名为“neuvector”的Helm Chart与本地计算机的连接：

$ kubectl port-forward --namespace neuvector service/neuvector-service-webui 8443

当我们执行完上面的命令后，就会在终端中打印如下信息，这就代表我们已经成功使用kubectl port-forward命令代理名为“neuvector”的Helm Chart与本地计算机的连接，且将其映射到本地的8443端口：
然后我们只需要打开本系统自带的浏览器，来访问如下地址即可：

https://localhost:8443

执行完上面的操作后，在打开的浏览器中会出现如下图所示的内容，我们只需按照红箭头和红框处所示进行选择即可：
然后会出现如下图所示的内容，我们只需按照红箭头和红框处所示进行选择即可：
然后会出现如下图所示的内容，表示让我们输入用户名和密码才能登陆进去NeuVector平台（默认的用户名为“admin”，默认的密码为“admin”）：
然后就会来到如下图所示的界面，这就代表我们已经成功通过Helm安装好了NeuVector工具：
如果我们想退出已经安装并启动的NeuVector工具，只需要在刚才打开NeuVector工具的终端中按一下“Ctrl+C”，然后再关闭刚刚打开的关于NeuVector平台的浏览器即可退出NeuVector工具。不过此时NeuVector服务还在Minikube上运行，需要执行下面的命令后，才算彻底退出了NeuVector工具：

$ minikube stop

2.2、使用方法

2.2.1、启动与停止

在本章节中，我们将会介绍NeuVector工具/系统的启动方式。NeuVector工具/系统与我们以往学习的工具/系统都有所不同，因为其它工具/系统被我们部署好之后就可以直接使用了，而NeuVector工具/系统部署好后，每次都需要我们手动启动，稍微麻烦一些，而且步骤也比较琐碎，所以特在此章节介绍如何启动NeuVector工具/系统（以下简称NeuVector）。本章节的具体内容如下所示。

首先启动1.23.9版本的Kubernetes的单机版集群：

$ cd /home/iie-iisd/
$ minikube start --image-mirror-country='cn' --image-repository='registry.cn-hangzhou.aliyuncs.com/google_containers' --kubernetes-version=v1.23.9 --memory 8192 --cpus 8

然后执行如下命令来启用metrics-server插件。metrics-server是一个Kubernetes插件，用于收集和提供集群中各个Pod和节点的性能指标。它是Kubernetes仪表板等功能所依赖的一个重要组件：

$ minikube addons enable metrics-server

然后使用如下命令来查看名为“neuvector”的命名空间中所有Pods的信息：

$ kubectl get pods --namespace neuvector

只有当命令行终端中输出的信息如下图红箭头和红框处所示时（或其STATUS为Completed也可以），才能继续下面的操作，否则就要重复执行这条命令直到当前命令行终端中输出的信息如下图红箭头和红框处所示（或其STATUS为Completed也可以）：
然后顺序执行如下三条命令：

$ NODE_PORT=$(kubectl get --namespace neuvector -o jsonpath="{.spec.ports[0].nodePort}" services neuvector-service-webui)
$ NODE_IP=$(kubectl get nodes --namespace neuvector -o jsonpath="{.items[0].status.addresses[0].address}")
$ echo https://$NODE_IP:$NODE_PORT

然后执行如下命令来使用kubectl port-forward命令代理名为“neuvector”的Helm Chart与本地计算机的连接：

$ kubectl port-forward --namespace neuvector service/neuvector-service-webui 8443

然后我们只需要打开本系统自带的浏览器，来访问如下地址即可：

https://localhost:8443

执行完上面的操作后，在打开的浏览器中会出现如下图所示的内容，我们只需按照红箭头和红框处所示进行选择即可：
然后会出现如下图所示的内容，我们只需按照红箭头和红框处所示进行选择即可：
然后会出现如下图所示的内容，表示让我们输入用户名和密码才能登陆进去NeuVector平台（默认的用户名为“admin”，默认的密码为“admin”）：
然后就会来到如下图所示的界面，这就代表我们已经成功启动了NeuVector工具：
如果我们想退出已经启动好的NeuVector工具，只需要在刚才打开NeuVector工具的终端中按一下“Ctrl+C”，然后再关闭刚刚打开的关于NeuVector平台的浏览器即可退出NeuVector工具。不过此时NeuVector服务还在Minikube上运行，需要执行下面的命令后，才算彻底退出了NeuVector工具：

$ minikube stop

2.2.2、自定义配置

当我们成功启动NeuVector并进入系统主界面后，发现整个系统都是英文，这对我们后续的学习很不友好。此外，我们的登陆NeuVector系统时使用的用户名和密码都是系统默认的用户名和密码，这也很不安全。所以我们就有了修改系统为中文和修改用户名及其对应密码的需求，这也是本章节要介绍的内容。关于本章节的具体内容如下所示：

首先按照如下图红框和红箭头处所示进行选择：
此时我们就会来到用户配置界面，然后点击如下图红框和红箭头处所示的内容：
按照如下图所示进行配置，最后保存当前配置。需要注意的是，每个空都需要填写，否则系统不允许我们自定义配置（这是一个坑）：
然后会自动跳转到系统的登录界面，只需要输入我们刚刚修改后的用户名和密码后点击登录即可：
此时系统的语言就变成中文了，而且我们还成功的修改了当前用户的密码及其邮箱：

2.2.3、概览

概览部分的主要功能是提供整个容器环境的实时概览，包括当前运行的主机的健康情况（即检测到的漏洞）、Pod信息、安全事件和策略等关键信息。下面将对NeuVector的概览功能进行详细的介绍。

在NeuVector的主界面，我们按照如下图红框和红箭头处所示进行选择即可来到NeuVector概览功能的详细界面。在本页的最上面，我们可以看到当前NeuVector部署的主机中的漏洞情况和漏洞风险分数等信息，不过由于目前我们还没有进行任何漏洞扫描，所以此部分内容为空。此外，还记录了当前正在使用的Pod信息以及接入和接出的Pod信息，因为NeuVector工具正式建立在一个个Pod上，关于Pod的内容我们在此并不赘述，因为之前已有详细介绍。

在这里插入图片描述

在上面的页面中继续向下翻阅，我们可以看到当前NeuVector工具所记录的所有安全事件以及检测到的漏洞的详细情况，不过由于我们目前还没有使用NeuVector进行任何漏洞扫描，所以当前页面的内容为空。

在这里插入图片描述

在上面的页面中继续向下翻阅，我们可以看到关于服务得到策略模式、Pod的策略模式信息和七层网络规则侦测和保护的应用协议信息。

在这里插入图片描述

在这里我们要强调的是三种模式，即保护模式、监控模式和学习模式：

保护模式：NeuVector监视容器和主机的网络和进程运行情况，遇到非学习模式下记录的行为直接拒绝
监控模式：NeuVector监视容器和主机的网络和进程运行情况，遇到非学习模式下记录的行为将在NeuVector中进行告警
学习模式：学习和记录容器、主机间网络连接情况和进程执行信息。自动构建网络规则白名单，保护应用网络正常行为。为每个服务的容器中运行的进程设定安全基线，并创建进程配置文件规则白名单。

此外，我们还要注意到七层网络规则侦测和保护的应用协议信息。七层网络规则通常涉及到OSI模型中的应用层，主要关注应用层协议的内容。这包括HTTP、HTTPS、FTP、SMTP等协议。七层规则通常允许NeuVector检测和阻止对这些协议的潜在攻击。

2.2.4、网络活动

网络部分的主要功能是展示容器之间的网络活动和通信，通过网络流量可视化功能，我们可以清晰看到容器集群内的网络连接关系和当前容器连接会话，并且可以轻松的过滤网络连接信息，以进行图标展示，还能够快速进行网络问题定位。此外这部分内容还包括网络连接、传入和传出的流量、容器间的通信路径等信息。这些信息有助于监控潜在的网络威胁和异常活动。我们可以按照如下图红框和红箭头处所示进行选择来查看当前的网络活动情况。可以发现，NeuVector以可视化的方式为我们展示当前各个容器以及各个节点之间的网络通信关系，因为我们是使用单节点集群的方式部署的NeuVector，所以当前展示的信息比较单调。

在这里插入图片描述

2.2.5、资产

资产部分的主要功能是提供对容器环境中的资产的可视化和管理。这包括平台、命名空间、主机和容器等。了解容器环境中的资产有助于更好地管理和保护这些资源。此外，资产部分还负责对以上内容进行漏洞扫描与检测的功能。

2.2.5.1、平台

可以使用NeuVector对当前部署的平台进行漏洞扫描，因为当前我们正在将NeuVector部署在Kubernetes上，所以本章节将会介绍如何使用NeuVector对Kubernetes进行漏洞扫描。

首先进入如下图所示的界面，选择当前NeuVector部署的平台，即Kubernetes，然后进行漏洞扫描：

在这里插入图片描述

然后稍等一下，会在当前页面显示扫描结果的详细信息，如下图所示，可以发现，扫描到6个高危漏洞，2个中危漏洞。此外，针对不同的漏洞，NeuVector有不同的风险级别提示、对应的组件版本提示和修复版本提示：

在这里插入图片描述

需要注意的是，NeuVector集成了CVE漏洞库，每天自动更新，以支持对平台（Kubernetes）、主机、容器、镜像仓库等进行安全漏洞扫描。此外，在当前页面我们还可以配置自动扫描，当平台漏洞库有更新，或有新的节点和容器加入时，NeuVector会自动对平台（Kubernetes）、主机、容器、镜像仓库等进行漏洞扫描。关于这两点注意点后续不再赘述，因为都同理。

2.2.5.2、命名空间

我们还可以通过NeuVector系统查看当前系统中Kubernetes中存在的命名空间，这个过程如下图红箭头和红框处所示：

在这里插入图片描述

可以发现，当前系统中Kubernetes中存在的命名空间一共有4个，其中名为“kube-system”的命名空间中一共存在16个容器，当前系统中正在运行其中15个容器，共有8个Pod正在运行。

在这里介绍一下关于命名空间的概念。Kubernetes中的命名空间（Namespace）是一种用于将集群中的资源划分为不同逻辑组的机制。它允许在同一集群中运行多个团队或项目，每个团队或项目都可以在相同的物理集群上独立地使用相同的资源，而不会互相干扰。以下是有关Kubernetes命名空间的一些关键概念：

逻辑隔离：命名空间提供了一种逻辑隔离的方式，使得在同一Kubernetes集群中运行的多个团队或应用可以在相同的集群上操作而不会相互影响。
资源隔离：每个命名空间都有自己的资源配额和限制，这样可以确保一个命名空间中的资源使用不会影响其它命名空间。这包括Pod、Service、Volume等资源。
命名空间切换：Kubernetes提供了一些命令和配置选项，使管理员和开发人员可以轻松地在不同的命名空间之间切换，以便查看和操作各自的资源。
默认命名空间：当我们创建资源时，如果没有显式指定命名空间，它们将被放置在默认命名空间中。默认命名空间通常是整个集群的全局范围。
系统命名空间：Kubernetes还包含一些系统级别的命名空间，例如kube-system，其中包含了集群的核心组件，如kube-dns、kube-proxy等。
多租户支持：通过使用命名空间，Kubernetes支持多租户模型，使得不同团队、项目或用户可以在同一集群上独立工作，而不会相互干扰。

总的来说，命名空间是Kubernetes中用于组织和隔离集群资源的一种灵活而强大的机制。

2.2.5.3、主机

可以使用NeuVector对当前部署的主机进行漏洞扫描，因为当前我们将NeuVector部署在Minikube上，所以本章节将会介绍如何使用NeuVector对Minikube进行漏洞扫描。

在NeuVector系统中可以按如下图红框和红箭头处所示进行选择，在打开的页面中可以查看当前NeuVector部署的主机的详细信息，这些详细信息保存了当前主机部署的操作系统、内存和CPU核数等：

在这里插入图片描述

然后选择当前NeuVector部署的主机，即Minikube，然后对其进行漏洞扫描：

在这里插入图片描述

稍等一下，会显示漏洞扫描完成。然后可以按照如下图红箭头和红框处所示进行选择以查看详细的漏洞扫描结果：

在这里插入图片描述

可以发现，本次漏洞扫描共扫描到31个高危漏洞，62个中危漏洞。此外，针对不同的漏洞，NeuVector有不同的风险级别提示、对应的组件版本提示和修复版本提示：

在这里插入图片描述

2.2.5.4、容器

可以使用NeuVector对当前部署的容器进行漏洞扫描，因为当前我们将NeuVector部署在Minikube上，而Minikube又是由很多容器构成的，所以本章节将会介绍如何使用NeuVector对这些容器进行漏洞扫描。

在NeuVector系统中可以按如下图红框和红箭头处所示进行选择，在打开的页面中可以通过点击某一个容器来查看当前NeuVector部署的某一个特定的容器的详细信息，这些详细信息保存了当前部署的容器的ID、服务和网络模式等：

在这里插入图片描述

然后我们可以选择某一个特定的容器，对其进行漏洞扫描，这个操作过程如下图红框和红箭头处所示：

在这里插入图片描述

稍等一下，会显示漏洞扫描完成。然后可以按照如下图红箭头和红框处所示进行选择以查看详细的漏洞扫描结果：

在这里插入图片描述

可以发现，本次漏洞扫描没有扫描到任何漏洞，这也就说明当前使用的这个容器中并不存在任何漏洞，不过我们可以按照上面的方法来检测其它容器中是否存在漏洞：

在这里插入图片描述

2.2.5.5、镜像库

NeuVector对镜像库进行漏洞扫描是指NeuVector提供了一种功能，可以检测和识别存储在容器镜像中的潜在安全漏洞。容器镜像是包含应用程序和其依赖项的可执行软件包，通常以容器形式部署到Kubernetes集群或其他容器编排平台中。

漏洞扫描的目的是发现镜像中可能存在的已知漏洞，这些漏洞可能导致安全风险，例如未经授权的访问、数据泄漏或远程执行代码等问题。在容器生命周期的不同阶段，从开发到部署，漏洞扫描都是一种重要的安全实践，以确保镜像的安全性。

NeuVector的漏洞扫描功能可能包括以下方面：

漏洞数据库：使用已知漏洞数据库，例如Common Vulnerabilities and Exposures (CVE)数据库，NeuVector可以检查容器镜像中是否存在已知的安全漏洞。
基础设施组件：对于容器镜像中包含的操作系统和基础设施组件，NeuVector可能会检查它们是否有未修补的漏洞。
应用程序依赖项：检查镜像中包含的应用程序及其依赖项，以确保它们没有已知的漏洞。
安全策略检查：检查是否存在配置错误或不安全的设置，例如默认凭据、开放的端口或权限配置问题。

通过定期进行漏洞扫描，团队可以及早发现和纠正潜在的安全问题，提高容器化环境的整体安全性。这对于确保生产环境中运行的容器镜像符合安全最佳实践非常重要。NeuVector目前支持对接多种镜像仓库如docker-registry（harbor）、JFrog Artifactory、Nexus等。我们可以按照如下图红框和红箭头处所示进行选择以来到NeuVector对镜像库进行漏洞扫描的界面：

在这里插入图片描述

然后添加目标镜像库，填写相应信息后保存即可：

在这里插入图片描述

当我们添加了某一个目标镜像库之后，就可以使NeuVector对其进行漏洞扫描了：

在这里插入图片描述

2.2.5.6、Sigstore校验器

Sigstore校验器通常是指用于验证Sigstore签名的工具或服务。Sigstore是一个开源项目，旨在提供一种透明、开放和易于验证的方式，以证明软件包的真实性和完整性。Sigstore使用数字签名来确保软件包的来源和内容未被篡改。Sigstore校验器可能包括以下功能：

签名验证：Sigstore校验器用于验证软件包的数字签名，以确保签名是由合法的签名者创建的，且软件包的内容未被篡改。
时间戳验证：Sigstore通常使用时间戳来记录签名的时间，以确保签名的时效性。校验器可以验证时间戳，确保签名在合适的时间内进行。
透明性日志验证：Sigstore通常使用透明性日志（Transparent Log）来存储签名数据，以确保签名的透明性和公开性。校验器可能会验证签名是否被正确地记录在透明性日志中。
证书链验证：如果使用X.509证书进行签名，校验器可能会验证证书链，以确保证书的有效性和合法性。

Sigstore校验器的主要目标是提供一种可信的方式，使用户能够验证软件包的真实性，并确保软件包在整个供应链中的完整性。这对于防止恶意软件注入、确保安全升级和维护软件的透明性非常重要。

我们可以按照如下图红框和红箭头处所示来打开NeuVector的Sigstore校验器页面。可以发现，当前我们没有添加任何Sigstore校验器：

在这里插入图片描述

如果我们想添加Sigstore校验器，可以按照如下图红框和红箭头处所示进行选择：

在这里插入图片描述

填写完Sigstore校验器的相关信息后，即可将其添加：

在这里插入图片描述

2.2.5.7、系统组件

我们还可以按照如下图红框和红箭头处所示查看当前部署NeuVector所使用的系统组件。这些系统组件主要包括三大类，分别是控制器、扫描器和代理端：

在这里插入图片描述

我们可以点击某一个控制器的系统组件以查看其详细信息，这些详细信息包括ID、主机和命名空间等：

在这里插入图片描述

不仅可以查看某一个控制器的系统组件的详细信息，还可以查看其控制器统计信息，控制器统计信息主要针对的是当前这个控制器的CPU占用和内存占用情况：

在这里插入图片描述

同样，我们也可以点击某一个扫描器的系统组件以查看其详细信息，这些详细信息包括ID、CVE数据库版本和DB创建时间等，这些详细信息和控制器的系统组件的详细信息有所不同。另外，扫描器的系统组件并不包括扫描器统计信息，即不包括CPU占用和内存占用信息：

在这里插入图片描述

同样，我们也可以点击某一个代理端的系统组件以查看其详细信息，这些详细信息包括ID、主机和命名空间等：

在这里插入图片描述

不仅可以查看某一个代理端的系统组件的详细信息，还可以查看其代理端统计信息，代理端统计信息主要针对的是当前这个代理端的CPU占用和内存占用情况：

在这里插入图片描述

2.2.6、策略

策略的主要功能是允许管理员定义和配置安全策略，包括网络策略、访问控制策略、运行时配置等。这有助于确保容器按照指定的规则和标准进行操作。具体来说，NeuVector提供的关于策略的功能包括：

准入控制
组
网络规则
应对规则
DLP探测器
WAF探测器

2.2.6.1、准入控制

准入控制（Admission Control）是Kubernetes中一种用于限制对集群资源进行创建、修改或删除的策略机制。它是一种强大的安全机制，允许管理员在资源被持久化到etcd之前对其进行审查和修改。

在Kubernetes中，用户和服务账户通过API请求创建、修改或删除集群资源，例如Pod、Service、Deployment等。准入控制器是Kubernetes API服务器的一部分，用于在资源持久化到etcd之前拦截这些请求，执行预定义的策略和验证操作。准入控制的主要作用包括：

验证：验证请求是否符合集群策略和安全标准。这可以包括检查用户身份、请求中包含的信息是否正确等。
转换：修改请求或资源的定义，以满足集群中的特定需求。例如，可以自动添加标签、注释或修改资源的配置。
拒绝：根据策略拒绝不符合规范的请求，防止不安全的操作或配置。

常见的准入控制器包括：

NamespaceLifecycle：确保命名空间的生命周期管理，防止删除被禁用的命名空间。
ResourceQuota：根据资源配额限制确保对集群资源的合理使用。
MutatingAdmissionWebhook：允许对请求中的资源进行修改，通常用于自动化配置或添加额外信息。
ValidatingAdmissionWebhook：对请求进行验证，确保其符合集群中的策略和标准。
PodSecurityPolicy：强制对Pod的安全配置进行检查，以防范容器的恶意使用。

通过配置和使用准入控制器，管理员可以定制和强化集群的安全性、合规性和可管理性。这些控制点可以确保在资源被永久持久化到etcd之前对其进行了审查和适当的操作。

NeuVector支持与Kubernetes准入控制（Admission Control）功能对接，实现UI配置准入控制规则，对请求进行拦截，对请求的资源对象进行校验。NeuVector支持多种准入控制策率配置，如镜像CVE漏洞情况限制、部署特权模式、镜像内使用root用户、特定标签等。我们可以按照如下图红框和红箭头处所示来到NeuVector的准入控制页面。我们可以在打开的这个页面中开启准入控制功能。注意：需要Kubernetes集群提前开启Admission Control功能：

在这里插入图片描述

我们还可以使用NeuVector提供的配置评估功能。准入控制中的配置评估是指对资源对象的配置进行检查和评估，以确保其符合定义的策略和规范。这包括了对于创建、修改或删除资源对象的请求进行实时的配置检查，以确保这些操作符合集群中定义的安全和运维规则。我们可以将资源对象的配置直接添加进如下图所示的界面中，以对其进行配置评估：

在这里插入图片描述

此外，还可以将当前的准入控制信息导出到本地，或者将本地的准入控制信息导入到NeuVector系统中：

在这里插入图片描述

我们还可以添加新的准入控制，以对指定的资源对象的配置进行检查和评估，我们可以按如下图红框和红箭头处所示来添加新的准入控制：

在这里插入图片描述

我们在打开的页面中添加我们的目标准入控制的相关信息即可。需要注意的是，NeuVector准入策略控制支持两种模式：监控模式和保护模式，对应的含义和组的模式一样的。关于监控模式和保护模式我们在此不再赘述，因为之前已经详细解释过：

在这里插入图片描述

2.2.6.2、组

NeuVector通过组的方式对容器和主机进行管理，对组进行合规性检查、网络规则、进程和文件访问规则、DLP/WAF 的检测配置。NeuVector会自动将当前集群主机加入到nodes组，对于集群内容器会自动创建以“nv.”开头的组。我们可以按照如下图红框和红箭头处所示来查看NeuVector的组：

在这里插入图片描述

新建的容器业务被自动发现默认为学习模式，也可以通过设置将默认模式设置为监控模式或保护模式。不同组策略冲突情况下，适用的有效模式如下表：

源组模式	目的组模式	有效模式
学习模式	监控模式	学习模式
学习模式	保护模式	学习模式
监控模式	学习模式	学习模式
监控模式	保护模式	监控模式
保护模式	学习模式	学习模式
保护模式	监控模式	监控模式

为了保证业务的稳定运行，当出现模式不一致时，有效模式以限制最小的模式运行。生产环境最佳实践使用路径可以是：

上新业务时，先学习模式运行一段时间，进行完整的功能测试和调用测试，得到实际运行此业务的网络连接情况和进程执行情况信息。
然后切换到监控模式运行一段时间，看看有没有额外的特殊情况，进行判断，添加规则。
最后全部容器都切换到保护模式，确定最终形态。

对于某个特定的组，我们可以点击其以查看这个特定组的详细信息，这些详细信息包括成员、自定义检查和进程规则等：

在这里插入图片描述

同时，我们也可以导入自定义的组策略以对容器和主机进行更具针对性的管理，只需要按照如下图红框和红箭头处操作，并填写所需要的信息然后保存即可。当然，对于NeuVector组的操作还有其它内容，不过我们在此并不做过多介绍，因为那些目前看来并不重要，我们只需要掌握基本的用法足矣：

在这里插入图片描述

2.2.6.3、网络规则

在NeuVector中，网络规则描述的是容器安全和防火墙方面的规则。以下是其包含的重要信息：

来源（Source）：规定了允许访问的源。这可能是一个容器、一个IP地址、一个服务等。
目的（Destination）：指定了规则应用的目标。这可以是一个容器、一个IP地址、一个服务等。
应用（Application）：可能指定了规则适用的具体应用或服务。这有助于细化规则，确保只有特定的应用可以访问或被访问。
端口（Port）：规定了允许的端口。这可以是指定的端口范围，也可以是具体的端口号。
动作（Action）：指定规则匹配时应采取的动作。这可以是允许流量通过、拒绝流量或者采取其他特定的操作。动作决定了规则匹配后对流量的处理方式。
类型（Type）：描述规则的类型或分类。这可能是系统生成、用户创建，或者其它特定的规则类型。规则类型有助于组织和理解规则集。
更新于（Last Updated）：表示规则最后一次更新的时间戳。这个字段显示了规则的最新修改时间，帮助管理员追踪规则的变更历史。

这些规则可以用于定义容器之间的通信规则，确保网络流量按照期望的方式进行。这有助于加强容器环境的安全性，限制不必要的网络访问，防范潜在的安全威胁。这样的规则页面提供了对容器网络流量的可视化和配置手段，使管理员能够更好地管理容器环境的网络安全。我们可以按照如下图红框和红箭头处所示来到NeuVector的网络规则页面：

在这里插入图片描述

在此页面，我们还可以将当前NeuVector所使用的网络规则信息打印，或者导出为CSV数据：

在这里插入图片描述

当然，我们也可以按照下图红箭头和红框处所示添加自定义的网络规则：

在这里插入图片描述

对于自定义的网络规则，我们只需要填写相应信息最后保存即可，这样就可以更有针对性地应用我们自定义的网络规则了：

在这里插入图片描述

2.2.6.4、应对规则

在NeuVector中，应对规则（Response Rules）用于定义在检测到特定安全事件或威胁时采取的响应措施。以下是应对规则页面中可能包含的信息：

类别（Category）：描述规则的类别或类型。这可以是与安全事件相关的分类，例如入侵检测、恶意行为、漏洞利用等。
描述（Description）：提供对规则目的和行为的简要说明。描述字段通常包含规则的更多上下文，帮助管理员理解规则的作用。
组（Group）：规则可能分组，这有助于组织和管理一组相关的规则。组信息有助于管理员更容易地浏览和查找相关规则。
条件（Conditions）：规定了触发规则的特定条件。这可能包括对网络流量、容器行为或其他安全事件的检测条件。
动作（Action）：规定了在满足条件时采取的响应动作。这可以是阻止流量、发送警报、记录日志等。
类型（Type）：描述规则的类型，例如是系统生成、用户创建，或者其它特定的规则类型。规则类型有助于组织和理解规则集。

这些信息共同构成了NeuVector中应对规则的配置，使管理员能够定义在特定情况下系统应该采取的响应措施。这对于加强容器环境的安全性、及时应对安全事件非常重要。我们可以按照如下图红框和红箭头处所示来到NeuVector的应对规则页面：

在这里插入图片描述

我们还可以按照下图红箭头和红框处所示添加自定义的应对规则：

在这里插入图片描述

然后会打开如下图所示的界面，提示我们输入自定义的应对规则信息。在这里有几点需要注意：

NeuVector事件响应机制可以将响应规则设置为根据安全事件情况进行动态响应，包括以下事件：
- 漏洞扫描结果
- CIS基准测试
- 准入控制事件等
响应动作包括网络挂接、取缔日志和隔离：
- 网络挂接：通过定义网络规则，允许或拒绝容器之间的通信，以提高网络安全性
- 取缔日志：记录和审计容器活动的日志，用于监测和调查潜在的安全事件
- 在检测到威胁或异常行为时，将容器或系统隔离，防止其对其他部分造成影响，以保护整个系统安全

当我们在自定义应对规则时，可以以上述内容作为参考。当我们输入了自定义的应对规则后，保存新添的应对规则即可将其应用：

在这里插入图片描述

2.2.6.5、DLP探测器

在NeuVector中，DLP（Data Loss Prevention）探测器是一种用于检测和防止数据泄露的组件。DLP主要关注敏感数据在容器环境中的传输和存储，确保敏感信息不会被未经授权的应用程序或用户访问、泄露或滥用。DLP 探测器通常包括以下功能和特点：

敏感数据识别：能够识别和分类敏感数据，例如个人身份信息（PII）、信用卡信息、医疗记录等。
数据流监测：实时监测容器中的数据流，识别传输中的敏感数据。
策略定义：允许管理员定义数据保护策略，指定哪些数据是敏感的，以及在发现敏感数据流时采取的响应措施。
实时警报：提供实时警报，通知管理员发现的潜在数据泄露事件，以便及时采取行动。
审计和报告：记录数据泄露事件，生成详细的审计和报告，用于合规性和安全审计。

通过使用DLP探测器，NeuVector可以增强容器环境的数据安全性，防范潜在的数据泄露风险，保护敏感信息免受未经授权的访问。这对于符合法规、保护用户隐私以及确保业务数据的安全至关重要。我们可以按照如下图红框和红箭头处所示来到NeuVector的DLP探测器页面：

在这里插入图片描述

点击某一个特定的DLP探测器，我们可以看到如下图红框和红箭头处所示的选择的特定的DLP探测器的详细信息，这些详细信息包括规则名称和正则形式等：

在这里插入图片描述

我们还可以导入本地的DLP探测器信息到NeuVector和导出NeuVector的DLP探测器信息到本地：

在这里插入图片描述

当然，我们还可以添加自定义的DLP探测器，以对某些敏感数据进行针对性的检测和保护：

在这里插入图片描述

对于自定义的DLP探测器，我们只需要输入其对应的信息并保存即可生效：

在这里插入图片描述

2.2.6.6、WAF探测器

在NeuVector中，WAF（Web Application Firewall）探测器是一种用于检测和防御容器中Web应用程序的安全威胁的组件。WAF通常用于保护Web应用程序免受常见的攻击，例如SQL注入、跨站脚本（XSS）、跨站请求伪造（CSRF）等。WAF探测器可能包括以下功能和特点：

攻击签名检测：使用预定义的攻击签名来检测恶意的HTTP请求，识别已知的攻击模式。
异常行为检测：监测应用程序的行为，识别与正常行为不一致的模式，以检测未知的攻击。
协议检查：分析和验证HTTP请求和响应的合规性，确保它们符合协议标准，防止协议层面的攻击。
安全响应：在检测到潜在攻击时，采取相应的安全响应措施，例如阻止请求、记录日志、发送警报等。
定制规则：允许管理员定义自定义的安全规则，以满足特定应用程序和环境的安全需求。

通过使用WAF探测器，NeuVector可以增强容器中运行的Web应用程序的安全性，提供防御机制，防范常见的Web攻击。这有助于确保Web应用程序免受潜在的安全威胁，保护敏感信息和维护业务的可靠性。我们可以按照如下图红框和红箭头处所示来到NeuVector的WAF探测器页面：

在这里插入图片描述

点击某一个特定的WAF探测器，我们可以看到如下图红框和红箭头处所示的选择的特定的WAF探测器的详细信息，这些详细信息包括规则名称和正则形式等：

在这里插入图片描述

我们还可以导入本地的WAF探测器信息到NeuVector和导出NeuVector的WAF探测器信息到本地：

在这里插入图片描述

当然，我们还可以添加自定义的WAF探测器，以对某些容器内的Web应用程序进行针对性的检测和保护：

在这里插入图片描述

对于自定义的WAF探测器，我们只需要输入其对应的信息并保存即可生效：

在这里插入图片描述

2.2.7、安全隐患

安全隐患的主要功能是提供容器环境中已知漏洞和安全风险的报告。这使管理员能够了解潜在的安全问题，并采取措施进行修复或防护。对于安全隐患部分，NeuVector提供了以下功能：

漏洞
漏洞配置资料
合规
合规资料

2.2.7.1、漏洞

这里所说的漏洞就是使用NeuVector检测到的漏洞（这里关于“漏洞”的定义没有什么特别的，就是我们平时常常讨论的“漏洞”），针对每个漏洞，NeuVector可以展示对应的漏洞发布时间、漏洞影响范围、对应的组件影响版本，此外，还可以查看对漏洞进行过滤，检测是否已经修复，以及漏洞等级和发布时间等详细信息：

在这里插入图片描述

此外，还可以将这些漏洞信息打印，或者导出为CSV文件：

在这里插入图片描述

还有一项比较重要的功能需要强调一下，对于某一个具体的漏洞，我们可以按照如下图红框和红箭头处所示进行筛选，然后点击“接受”，如果对某个特定的漏洞选择了此选项，就代表我们目前可以接受此特定的漏洞，在后面的操作中，将会忽略此漏洞对当前系统带来的任何影响：

在这里插入图片描述

2.2.7.2、漏洞配置资料

NeuVector的漏洞配置资料（Vulnerability Configuration Profiles）指的是对于漏洞的配置细则，我们可以按照如下图红框和红箭头处所示进行选择以来到NeuVector的漏洞配置资料页面：

在这里插入图片描述

如果我们将某个扫描到的特定漏洞设置为“接受”（如“2.2.7.1、漏洞”章节介绍的那样），那么就会在此页面看到对应漏洞，从而对此漏洞进行各种个性化配置：

在这里插入图片描述

我们还可以添加自定义的漏洞配置资料信息：

在这里插入图片描述

我们只需要添加漏洞配置资料的各种对应信息并将其添加即可：

在这里插入图片描述

2.2.7.3、合规

NeuVector的合规检查是指该平台对容器环境进行安全合规性检查的功能。这包括确保容器工作负载符合特定的法规、安全标准或企业内部的安全策略。合规检查通常包括以下方面：

法规符合：检查容器环境是否符合特定法规的要求。例如，GDPR、HIPAA、PCI DSS等法规的合规性检查。
安全标准合规：对容器环境执行合规性检查，确保其符合特定的安全标准或框架。这可能涉及到像CIS Docker Benchmark等安全标准的合规性检查。
策略执行：执行和验证安全策略，确保容器工作负载满足特定的安全要求和合规性规定。
自定义规则：提供管理员配置和执行自定义合规性规则的能力，以满足特定企业的安全和合规性需求。
审计和报告：生成合规性审计报告，记录容器环境的合规性状态，并提供必要的审计和报告信息。

通过这些合规检查功能，NeuVector可以帮助组织降低合规性风险，确保其容器环境满足法规和标准的要求。这对于需要遵循特定法规和安全标准的行业非常重要，帮助组织保持安全合规。我们可以按照如下图红框和红箭头处所示来到NeuVector的合规页面。当前页面记录了NeuVector的全部合规性检查结果：

在这里插入图片描述

对于某个特定的合规性检查结果，NeuVector还提供了针对此合规性检查结果的修复建议和影响范围：

在这里插入图片描述

我们也可以将NeuVector的全部合规性检查结果打印或者导出为CSV文件：

在这里插入图片描述

2.2.7.4、合规资料

NeuVector的合规资料（Compliance Profiles）通常指的是用于配置和管理容器环境合规性检查的设置和规则。NeuVector的合规性审核包括CIS基线测试、自定义检查、机密审核以及PCI、GDPR（GDPR （General Data Protection Regulation，《通用数据保护条例》）为欧盟条例）和其他法规的行业标准模板扫描。在合规性检查中也会检查是否存在密文泄漏情况。包括如以下密文泄漏情况：

1.	General Private Keys  
2.	General detection of credentials including 'apikey', 'api_key', 'password', 'secret', 'passwd' etc.  
3.	General passwords in yaml files including 'password', passwd', 'api_token' etc.  
4.	General secrets keys in key/value pairs  
5.	Putty Private key  
6.	Xml Private key  
7.	AWS credentials / IAM  
8.	Facebook client secret  
9.	Facebook endpoint secret  
10.	Facebook app secret  
11.	Twitter client Id  
12.	Twitter secret key  
13.	Github secret  
14.	Square product Id  
15.	Stripe access key  
16.	Slack API token  
17.	Slack web hooks  
18.	LinkedIn client Id  
19.	LinkedIn secret key  
20.	Google API key  
21.	SendGrid API key  
22.	Twilio API key  
23.	Heroku API key  
24.	MailChimp API key  
25.	MailGun API key

以上列举了一些常见的私密信息和凭证，NeuVector会使用这些规则来进行检测和识别潜在的安全风险。具体来说：

API Key/API Secret/Password/Secret/Passwd：这些是常见的凭证，用于身份验证和授权。API Key和API Secret通常用于访问API，而Password、Secret、Passwd则是用户账户的登录凭证。
YAML文件中的密码：YAML是一种数据序列化格式，有时候用于配置文件。这里提到检测YAML文件中的密码，是指寻找可能包含在配置文件中的敏感信息。
秘密键值对：指的是在配置文件或其它数据中以键值对形式存储的敏感信息，例如数据库连接字符串等。
Putty Private Key/Xml Private Key：私钥文件用于加密通信或进行身份验证。这里提到了Putty和Xml格式的私钥。
AWS Credentials/IAM：AWS Credentials指的是亚马逊云服务（AWS）的凭证，IAM（Identity and Access Management）是AWS中用于访问控制的服务。
社交媒体和开发平台的凭证：包括Facebook、Twitter、GitHub、Square、Stripe、Slack、LinkedIn、Google等平台的相关凭证和密钥。
服务提供商的API Key：包括 SendGrid、Twilio、Heroku、MailChimp、MailGun等服务的API Key。

这些信息可能会因具体的安全检测和保护策略而有所不同，但这些规则的目标是识别和防范潜在的安全漏洞，防止敏感信息泄漏。我们可以按照如下图红框和红箭头处所示进行选择以来到NeuVector的合规资料页面。

在这里插入图片描述

上图展示的是应用了全部设置和规则之后经过合规性检查的合规性检查结果，如果想单独查看某一类合规性检查的检查结果可以按照如下图所示进行筛选：

在这里插入图片描述

对于某个特定的合规性检查结果，我们还可以对其进行编辑：

在这里插入图片描述

我们还可以查看关于合规性资产的详细信息：

在这里插入图片描述

对于某一个特定的合规性资产，我们可以对其进行自定义的模板配置：

在这里插入图片描述

2.2.8、通知

通知的主要功能是显示与安全事件相关的通知，如漏洞报告、策略违规通知等。这有助于管理员及时了解和响应安全事件。NeuVector在通知这一部分为用户具体提供了以下这些功能：

安全事件
风险报告
事件

2.2.8.1、安全事件

NeuVector的安全事件页面主要记录了当前所有可能引发容器内应用或者网络的任何不寻常或者可疑的活动或状态，不过目前我们并没有扫描到任何安全事件，所以以下界面为空：

在这里插入图片描述

2.2.8.2、风险报告

NeuVector的风险报告是一种提供对特定环境或系统中潜在风险的详细分析的文档或报告。这种报告通常用于评估和呈现潜在威胁、漏洞、合规性问题和其他可能影响安全性和稳定性的因素。风险报告的目标是为组织提供全面的了解，以便他们能够采取适当的措施来降低风险。NeuVector的风险报告通常包括以下要素：

漏洞和安全威胁：报告可能包含的已知漏洞、安全威胁或恶意活动的详细分析。
合规性和法规：如果适用，报告可能会评估组织是否符合特定的法规、标准或合规性要求。
配置和设置错误：识别可能导致安全漏洞的系统配置错误或不安全的设置。
网络活动分析：分析网络活动，以检测不寻常的通信模式、可能的攻击或其他安全问题。
访问控制评估：评估系统或应用程序的访问控制设置，识别不当配置或权限问题。
行为分析：分析系统或用户的行为，以识别可能的异常活动或潜在的内部威胁。

值得注意的是，风险报告的形式和内容会根据所涉及的领域和工具的不同而有所变化。在信息安全领域，风险报告通常是安全评估和漏洞扫描工具的输出之一，用于指导组织改进其安全性和合规性水平。我们可以按照如下图红框和红箭头处所示选择以来到NeuVector的风险报告页面：

在这里插入图片描述

我们还可以将当前NeuVector的所有风险报告打印或者导出为CSV文件：

在这里插入图片描述

2.2.8.3、事件

事件通常涉及到NeuVector平台的管理员或用户的活动记录，比如登录、启用某个功能、配置更改等。这些操作类型的事件记录主要用于审计、监控和跟踪系统的管理活动，而不是直接与容器安全性相关。在这种情况下，NeuVector可能记录以下类型的操作事件：

登录事件：记录管理员或用户登录NeuVector平台的活动，包括登录时间、用户信息等。
功能启用/禁用事件：记录管理员启用或禁用NeuVector平台中的特定功能的活动。
配置更改事件：记录管理员对NeuVector平台进行的配置更改，包括修改策略、更新设置等。
用户活动记录：记录用户在NeuVector平台上的操作活动，例如查看报告、执行扫描等。

这些操作类型的事件记录主要用于确保对NeuVector平台的管理和配置的透明性，以及追踪系统的使用情况。我们可以按照如下图红框和红箭头处所示以来到NeuVector的事件页面：

在这里插入图片描述

对于某个特定的事件，我们可以点击如下图红框和红箭头处所示的按钮以查看其更详细的信息：

在这里插入图片描述

下图红框和红箭头处就展示了某一个特定的事件的详细信息，这些详细信息包括请求的类型和请求的数据等：

在这里插入图片描述

我们还可以将NeuVector的全部事件导出为CVS文件：

在这里插入图片描述

2.2.9、设置

设置的主要功能是提供对NeuVector系统的配置和管理选项，包括用户权限、集成设置、日志配置等。NeuVector在设置这一部分为用户具体提供了以下这些功能：

用户&角色
配置
LDAP/AD配置
SAML配置
OpenID Connect配置

2.2.9.1、用户&角色

在NeuVector中，用户&角色部分涉及到用户管理和访问控制的设置。下面是一些常见的概念：

用户（User）：用户是指NeuVector平台的具体登录账户。每个用户都有一个唯一的标识符和相关的身份信息。用户可以登录到NeuVector平台，执行特定的操作，以及访问相关的功能和信息。
角色（Role）：角色定义了用户在NeuVector中的权限和访问级别。不同的角色具有不同的权限，以控制用户对系统的操作范围。常见的角色包括管理员、观察者、编辑者等，每个角色都有特定的权限，例如执行扫描、配置策略、查看报告等。

通过用户&角色设置，NeuVector平台的管理员可以：

创建新的用户账户，为每个用户分配唯一的身份标识。
配置用户角色，定义每个用户在平台上的权限和访问级别。
管理和维护用户账户，包括禁用、启用、删除用户等操作。
确保合适的访问控制，以维护平台的安全性和透明性。

这些设置有助于NeuVector平台管理员有效地管理团队成员的权限，确保用户只能执行其职责范围内的操作，从而提高系统的安全性和管理效率。我们可以按照如下图红框和红箭头处所示来到NeuVector的用户&角色界面：

在这里插入图片描述

在NeuVector的用户&角色界面，我们可以看到当前已经存在的用户的信息：

在这里插入图片描述

当然，我们也可以添加新的用户：

在这里插入图片描述

填写新用户的相关信息后，即可将其添加：

在这里插入图片描述

NeuVector还提供了API密钥，用于标识和验证访问NeuVector API的程序：

在这里插入图片描述

我们还可以添加自定义的API密钥：

在这里插入图片描述

只需要输入自定义API密钥的对应数据即可添加成功：

在这里插入图片描述

NeuVector还提供了对角色的管理：

在这里插入图片描述

用户也可以添加自定义的NeuVector的角色：

在这里插入图片描述

用户可以设置自定义的NeuVector拥有的权限，只需要填写对应信息并保存即可：

在这里插入图片描述

在这里我们还可以对NeuVector进行自定义的用户&角色的身份验证和安全策略配置，这些用户&角色的身份验证和安全策略配置包括密码格式要求、尝试登陆失败后拒绝访问和密码过期后拒绝访问等：

在这里插入图片描述

2.2.9.2、配置

在NeuVector中的配置部分通常指的是对NeuVector平台的整体配置和设置。这包括一系列的选项和参数，用于调整NeuVector的行为、集成环境和实现特定的功能。以下是可能包含在NeuVector设置中的配置选项的一些常见示例：

容器环境配置：NeuVector可能需要配置以适应不同的容器环境，包括容器网络配置、容器运行时设置等。
安全策略配置：定义容器安全策略，配置允许或阻止的行为、端口、通信规则等。
日志和审计配置：配置NeuVector如何记录和审计安全事件、活动日志等信息。
报告和可视化配置：配置报告的生成方式、可视化界面的样式等。
漏洞扫描配置：配置漏洞扫描的详细选项，如扫描范围、漏洞数据库等。
通知和警报配置：配置NeuVector如何通知管理员或团队成员有关安全事件或违规活动的信息。
集成和部署配置：配置NeuVector与其他系统或工具的集成方式，以及如何在不同环境中进行部署。
用户身份和访问控制配置：配置用户身份验证、访问控制规则和角色定义等。

这些配置选项的目的是确保NeuVector能够适应不同的容器环境和用户需求，提供灵活性和可定制性，以满足特定安全和管理要求。管理员可以通过NeuVector的配置来调整系统的行为，以符合其组织的安全政策和工作流程。我们可以按照如下图红框和红箭头处所示来到NeuVector的配置界面：

在这里插入图片描述

在这里我们可以对NeuVector进行自定义的配置，这些配置包括服务、策略模式和扫描仪弹性伸缩等：

在这里插入图片描述

2.2.9.3、LDAP/AD配置

LDAP（Lightweight Directory Access Protocol）和AD（Active Directory）配置是NeuVector中用于集成和配置用户身份验证的一部分。这允许NeuVector利用现有的LDAP或AD目录服务来进行用户身份验证和访问控制。以下是可能包含在NeuVector的LDAP/AD配置中的一些常见选项：

LDAP/AD服务器地址：指定连接到LDAP或AD服务器所需的服务器地址。
端口号：指定连接到LDAP或AD服务器所使用的端口号。
基础DN（Distinguished Name）：指定LDAP或AD中用户和组织单位的基础Distinguished Name，用于构建查询。
用户搜索过滤条件：定义用于搜索用户的过滤条件，以确保只有符合条件的用户被允许访问NeuVector。
组搜索过滤条件：定义用于搜索组的过滤条件，以确保只有符合条件的组被用于角色授权。
绑定凭证：提供连接到LDAP或AD服务器所需的用户名和密码，以进行身份验证。

通过配置LDAP/AD，NeuVector可以实现以下功能：

单一身份验证点：使用现有的LDAP或AD目录服务作为NeuVector的用户身份验证中心，减少用户管理的复杂性。
基于组的访问控制：使用LDAP或AD中的组信息进行角色授权，确保用户只能执行其特定角色所允许的操作。
集中管理用户身份：对用户的身份管理集中在LDAP或AD中，确保在NeuVector中反映组织的最新状态。

这种集成和配置允许NeuVector平台与企业的现有身份验证和访问控制基础设施集成，从而提高安全性并简化用户和角色管理。我们可以按照如下图红框和红箭头处所示来到NeuVector的LDAP/AD界面：

在这里插入图片描述

在这里我们可以对NeuVector进行自定义的LDAP配置，这些LDAP配置包括用户名、密码和端口等：

在这里插入图片描述

2.2.9.4、SAML配置

SAML（Security Assertion Markup Language）配置在NeuVector中通常用于实现单点登录（Single Sign-On，SSO）。SAML是一种用于在网络间传递身份和授权信息的开放标准。通过配置SAML，NeuVector可以与支持SAML的身份提供者（如身份服务、身份提供商）集成，实现统一的身份验证和访问控制。以下是可能包含在NeuVector的SAML配置中的一些常见选项：

身份提供者元数据（Identity Provider Metadata）：包含与SAML身份提供者相关的元数据信息，包括身份提供者的终结点、证书信息等。
服务提供者元数据（Service Provider Metadata）：包含NeuVector作为服务提供者的元数据信息，用于向身份提供者注册NeuVector。
单一登出（Single Logout）：指定是否启用SAML单一登出功能，允许用户在一个服务提供者处注销后，自动注销其他相关服务提供者的会话。
绑定和协议：定义SAML中使用的绑定和协议，例如HTTP POST绑定、SOAP绑定等。
身份映射：配置NeuVector如何将SAML中的身份信息映射到NeuVector中的用户信息。

通过配置SAML，NeuVector可以实现以下功能：

单点登录（SSO）：用户只需通过一次身份验证，即可访问多个关联的服务，提高用户体验和方便性。
集成企业身份提供者：NeuVector通过与企业的SAML身份提供者集成，实现与企业身份管理系统的协同工作。
强化安全性：通过使用SAML标准，NeuVector可以确保身份验证和授权信息在网络中的安全传输，提高系统的整体安全性。

配置SAML提供了一种灵活的方式，使NeuVector能够适应不同组织的单点登录和身份管理需求。我们可以按照如下图红框和红箭头处所示来到NeuVector的SAML配置界面：

在这里插入图片描述

在这里我们可以对NeuVector进行自定义的SAML配置，这些SAML配置包括身份提供者、X.509证书和组别声明等：

在这里插入图片描述

2.2.9.5、OpenID Connect配置

OpenID Connect（OIDC）是一种在应用程序和服务之间进行身份验证和授权的协议，建立在OAuth 2.0的基础上。在NeuVector中，配置OpenID Connect主要涉及与支持OIDC的身份提供者集成，以实现统一身份验证和访问控制。以下是可能包含在NeuVector的OpenID Connect配置中的一些常见选项：

身份提供者元数据（Identity Provider Metadata）：包含与OpenID Connect身份提供者相关的元数据信息，如身份提供者的终结点、证书信息等。
客户端ID和密钥：为NeuVector注册的OpenID Connect客户端提供的标识和密钥信息，用于进行身份验证。
终结点配置：包括授权终结点、令牌终结点等，用于在身份验证和令牌获取过程中与身份提供者通信。
用户信息终结点：用于获取关于已认证用户的信息的终结点。
单一登出（Single Logout）：指定是否启用OpenID Connect单一登出功能，允许用户在一个服务提供者处注销后，自动注销其他相关服务提供者的会话。

通过配置OpenID Connect，NeuVector可以实现以下功能：

单点登录（SSO）：用户只需通过一次身份验证，即可访问多个关联的服务，提高用户体验和方便性。
集成企业身份提供者：NeuVector通过与企业的OpenID Connect身份提供者集成，实现与企业身份管理系统的协同工作。
强化安全性：通过使用OpenID Connect标准，NeuVector可以确保身份验证和授权信息在网络中的安全传输，提高系统的整体安全性。

这种集成提供了一种灵活的方式，使NeuVector能够适应不同组织的单点登录和身份管理需求。我们可以按照如下图红框和红箭头处所示来到NeuVector的OpenID Connect配置界面：

在这里插入图片描述

在这里我们可以对NeuVector进行自定义的OpenID Connect配置，这些OpenID Connect配置包括身份提供者单点登录网址、客户端id和客户端secret等：

在这里插入图片描述

3、测试用例

3.1、Pod间通过网络策略相互隔离

在Kubernetes中，网络策略（Network Policies）是一种用于定义Pod间通信规则的资源。网络策略允许我们明确指定哪些Pod可以与其它Pod进行通信，以及使用哪些协议和端口进行通信。Pod间通过网络策略相互隔离意味着我们可以通过网络策略规定某些Pod之间的通信是允许的，而另一些Pod之间的通信是被禁止的。网络策略通常包括以下要素：

选择器（Selectors）：我们可以使用标签选择器指定受策略影响的Pod集合。例如，我们可以通过选择器指定所有属于某个应用或属于某个环境的 Pod。
规则（Rules）：网络策略定义了一系列规则，这些规则决定了允许或拒绝哪些流量。规则可以基于源Pod、目标Pod、协议、端口等条件进行匹配。

通过网络策略，我们可以实现一定程度上的微隔离，确保只有经过授权的Pod之间可以进行通信。这有助于提高安全性，减少横向扩展时的潜在风险，以及限制不同微服务之间的直接访问。下面将会介绍如何使用NeuVector来实现Pod间通过网络策略相互隔离。

首先打开一个新的终端，在Kubernetes平台中创建四个Nginx：

$ cd ~
$ kubectl create deployment test-web1 --image=nginx
$ kubectl expose deployment/test-web1 --port=80 --type=NodePort
$ kubectl create deployment test-con1 --image=nginx
$ kubectl create deployment test-con2 --image=nginx
$ kubectl create deployment test-con3 --image=nginx

其中，值得注意的是：
- 名为“test-web1”的Nginx（以下简称“test-web1”）用作Web服务器
- 名为“test-con1”的Nginx（以下简称“test-con1”）用作连接客户端1
- 名为“test-con2”的Nginx（以下简称“test-con2”）用作连接客户端2
- 名为“test-con3”的Nginx（以下简称“test-con3”）用作连接客户端3
此时在NeuVector中打开如下图所示的界面，并点击一下“刷新”，就可以发现在NeuVector中会自动生成我们刚刚创建好的这几个组：
然后使用如下命令获取“test-con1”对应的Pod的名称：

$ kubectl get pods -l app=test-con1

可以发现“test-con1”对应的Pod的名称为“test-con1-867f6fbcc8-4rqgv”：
然后进入“test-con1”对应的Pod的Shell交互界面：

$ kubectl exec -it test-con1-867f6fbcc8-4rqgv -- /bin/bash

然后在“test-con1”的Shell交互界面中通过curl命令访问“test-web1”：

# curl test-web1

执行上面的命令可以得到如下图所示的输入，这代表此时“test-con1”可以正常访问“test-web1”：
上面可以正常访问是因为在学习模式下NeuVector会自动添加此访问规则：
然后我们将“test-web1”和“test-con2”都设置为监控模式。首先选中这两个组，然后点击“切换模式”：
然后在弹出的界面中，选中“监视”，然后点击“提交”：
然后点击“Ok”：
然后打开一个新的终端，并使用如下命令获取“test-con2”对应的Pod的名称：

$ cd ~
$ kubectl get pods -l app=test-con2

可以发现“test-con2”对应的Pod的名称为“test-con2-5b75fc4d6f-gkgkt”：
然后进入“test-con2”对应的Pod的Shell交互界面：

$ kubectl exec -it test-con2-5b75fc4d6f-gkgkt -- /bin/bash

然后在“test-con2”的Shell交互界面中通过curl命令访问“test-web1”：

# curl test-web1

执行上面的命令可以得到如下图所示的输入，这代表此时“test-con2”可以正常访问“test-web1”：
虽然此时“test-con2”可以正常访问“test-web1”，但是当我们打开NeuVector的如下界面却发现网络活动拓扑图中对应的连接链路变为红色，这代表虽然网络可以连通，但是产生了告警信息：
然后按照刚刚介绍的同样的方法再将“test-web1”和“test-con2”都设置为保护模式：
然后再通过“test-con2”去访问“test-web1”：

# curl test-web1

可以发现此时“test-con2”无法成功访问“test-web1”，这是因为curl命令在学习模式时没有使用，同时也不是NeuVector默认允许的可执行进程，所以此进程无法成功执行：
然后按照之前介绍的同样的方法将“test-con1”设置为保护模式：
然后在“test-con1”中访问www.baidu.com：

# curl www.baidu.com

可以发现“test-con1”无法访问www.baidu.com：
为了让“test-con1”可以访问www.baidu.com，我们可以通过自定义添加网络规则的方式开通访问权限：
在弹出的界面中，为“test-con1”添加外部访问规则，只需要按照如下图所示进行配置即可：

NeuVector深度了解应用程序行为，并将分析有效负载，以确定应用程序协议。协议包括：HTTP，HTTPS，SSL，SSH，DNS，DNCP，NTP，TFTP，ECHO，RTSP，SIP，MySQL，Redis，Zookeeper，Cassandra，MongoDB，PostgresSQL，Kafka，Couchbase，ActiveMQ，ElasticSearch，RabbitMQ，Radius，VoltDB，Consul，Syslog，Etcd，Spark，Apache，Nginx，Jetty，NodeJS，Oracle，MSSQL和GRPC。

然后别忘了点击“保存”：
然后还要点击“Ok”：
此时在“test-con1”中再次访问www.baidu.com：

# curl www.baidu.com

可以发现现在“test-con1”仍然无法访问www.baidu.com，即外部网络。按理说现在“test-con1”应该可以访问www.baidu.com，即外部网络，至于是什么原因导致出现如下图所示的情况，目前还不可知，后续如果解决了这个问题，会更新到下一版本的文档中：

除上述策略外，NeuVector也内置网络威胁检测，能够快速识别常用网络攻击，保护业务容器安全运行。无论保护模式如何，在“学习和监控”模式下，NeuVector将发出警报，并且可以在“通知->安全事件”中找到这些威胁。在保护模式下将收到警报和阻止；还可以根据威胁检测创建响应规则。包含的威胁检测如下：

1.	SYN flood attack  
2.	ICMP flood attack  
3.	IP Teardrop attack  
4.	TCP split handshake attack  
5.	PING death attack  
6.	DNS flood DDOS attack  
7.	Detect SSH version 1, 2 or 3  
8.	Detect SSL TLS v1.0  
9.	SSL heartbeed attack  
10.	Detect HTTP negative content-length buffer overflow  
11.	HTTP smugging attack  
12.	HTTP Slowloris DDOS attack  
13.	TCP small window attack  
14.	DNS buffer overflow attack  
15.	Detect MySQL access deny  
16.	DNS zone transfer attack  
17.	ICMP tunneling attack  
18.	DNS null type attack  
19.	SQL injection attack  
20.	Apache Struts RCE attack  
21.	DNS tunneling attack  
22.	TCP Small MSS attack  
23.	Cipher Overflow attack  
24.	Kubernetes man-in-the-middle attack per CVE-2020-8554

以上列举的是一些常见的网络攻击类型。以下是对这些攻击的简要解释：

SYN Flood Attack（SYN洪水攻击）：利用TCP协议的三次握手过程中的SYN请求进行洪水攻击，目的是消耗目标系统的资源。
ICMP Flood Attack（ICMP洪水攻击）：使用大量的ICMP数据包向目标系统发送请求，以耗尽目标系统的带宽或资源。
IP Teardrop Attack（IP碎片攻击）：利用IP协议中的碎片重组漏洞，通过发送特殊构造的碎片数据包来攻击目标系统。
TCP Split Handshake Attack（TCP分裂握手攻击）：利用TCP协议握手过程中的不对称握手来绕过防火墙，导致建立不安全的连接。
PING Death Attack（PING死亡攻击）：发送大量的ICMP Echo请求（ping请求）来消耗目标系统的资源。
DNS Flood DDOS Attack（DNS洪水攻击）：向目标域名服务器发送大量DNS请求，以耗尽其资源或导致服务不可用。
Detect SSH Version 1, 2, or 3（检测SSH版本1、2或3）：尝试识别目标系统上运行的SSH协议版本。
Detect SSL/TLS v1.0：检测目标系统是否支持或运行SSL/TLS版本1.0，该版本存在安全漏洞。
SSL Heartbleed Attack（SSL心脏滴漏攻击）：利用OpenSSL中的Heartbleed漏洞，从目标系统中泄漏敏感信息。
Detect HTTP Negative Content-Length Buffer Overflow：检测HTTP协议中负的Content-Length字段，可能导致缓冲区溢出攻击。
HTTP Smuggling Attack（HTTP伪装攻击）：利用HTTP协议的解析差异，欺骗代理服务器或防火墙，从而绕过安全策略。
HTTP Slowloris DDOS Attack（HTTP Slowloris DDOS攻击）：通过发送部分HTTP请求，维持多个连接的开放状态，以消耗目标系统的资源。
TCP Small Window Attack（TCP小窗口攻击）：减小TCP窗口大小，降低网络性能，可能导致拥塞。
DNS Buffer Overflow Attack（DNS缓冲区溢出攻击）：利用DNS协议的缓冲区溢出漏洞，执行恶意代码。
Detect MySQL Access Deny（检测MySQL拒绝访问）：检测MySQL数据库是否禁止访问。
DNS Zone Transfer Attack（DNS区域传输攻击）：尝试获取DNS服务器上全部的域名信息。
ICMP Tunneling Attack（ICMP隧道攻击）：通过伪装在ICMP数据包中的数据进行隧道通信，绕过网络安全检测。
DNS Null Type Attack（DNS空类型攻击）：发送DNS请求，其中Type字段为空，可能用于欺骗或攻击。
SQL Injection Attack（SQL注入攻击）：利用应用程序对输入的不正确验证，注入恶意SQL语句，以执行数据库攻击。
Apache Struts RCE Attack（Apache Struts远程代码执行攻击）：利用Apache Struts框架中的远程代码执行漏洞，执行恶意代码。
DNS Tunneling Attack（DNS隧道攻击）：利用DNS协议进行隧道通信，绕过网络安全策略。
TCP Small MSS Attack（TCP小MSS攻击）：发送TCP数据包，降低最大报文段长度，可能导致网络性能下降。
Cipher Overflow Attack（密码溢出攻击）：利用密码算法中的溢出漏洞，可能导致信息泄露。
Kubernetes Man-in-the-Middle Attack per CVE-2020-8554（Kubernetes中间人攻击，根据CVE-2020-8554）：利用Kubernetes中的安全漏洞进行中间人攻击。

这些攻击类型代表了网络安全领域中的一些常见威胁和漏洞。在实际应用中，网络管理员和安全专业人员需要采取相应的措施来防范和应对这些威胁。

3.2、行为监控

NeuVector的行为监控是指对容器和容器集群中发生的各种行为进行实时监控和记录，以便及时检测异常行为、安全事件或潜在威胁。这种监控有助于提高容器环境的安全性，并允许管理员或安全团队对违规行为做出及时响应。行为监控主要关注以下方面：

容器运行时行为：监控容器的运行时行为，包括进程启动、文件系统访问、网络通信等，以识别可能的异常或恶意活动。
容器间通信：监控容器之间的网络通信，识别异常的容器间流量模式，以及检测可能的横向移动攻击。
系统调用和API调用：监控容器内的系统调用和API调用，检测任何与安全策略不符的调用。
文件系统活动：跟踪容器内的文件系统活动，包括文件的创建、修改、删除等，以检测潜在的恶意文件操作。
用户权限变更：监控用户权限的变更，识别可能的特权升级或未经授权的访问。
敏感数据访问：检测容器内对敏感数据的访问，以保护敏感信息免受未经授权的泄露。
异常网络行为：监控容器的网络活动，包括异常的连接、端口扫描等，以检测潜在的网络攻击。

NeuVector使用行为监控来建立正常的容器行为基准，并通过实时分析与基线的差异来识别潜在的风险或威胁。当发现异常行为时，NeuVector可以采取自动响应措施，如隔离容器、阻止网络通信等，以确保容器环境的安全性。下面我们就将介绍如何在NeuVector中进行行为监控。

我们以CVE漏洞配置为例，目的是配置包含CVE漏洞名称为CVE-2023-39616的漏洞的容器在使用的时候进入隔离模式。以下是实现此目的的具体细节：

首先来到NeuVector的应对规则界面，并添加一个新的应对规则：
然后在弹出的窗口中按照如下图所示进行配置（其中“组”对应的是影响范围，如果为空，表示对全部的组都生效，填写特定的组名可以设置对特定组生效。）：
这个新的应对规则添加完毕后，会显示在应对规则界面中：
当我们配置完新的应对规则后，使用如下命令获取在“3.1、Pod间通过网络策略相互隔离”章节中创建的“test-con3”对应的Pod的名称：

$ cd ~
$ kubectl get pods -l app=test-con3

可以发现“test-con3”对应的Pod的名称为“test-con3-77f59897d8-lj4ng”：
然后进入“test-con3”对应的Pod的Shell交互界面：

$ kubectl exec -it test-con3-77f59897d8-lj4ng -- /bin/bash

然后在“test-con3”的Shell交互界面中通过curl命令访问名为“nginx”的容器：

# curl nginx

当我们执行上面的命令后，提示我们发现无法访问名为“nginx”的容器：
然后回到NeuVector的如下界面，选择“test-con3”对应的名为“nginx”的容器（如下图红框和红箭头处所示）进行漏洞扫描：
可以发现“test-con3”容器和“test-con3”对应的名为“nginx”的容器的状态全部都为隔离状态，这就意味着这两个容器内存在名称为CVE-2023-39616的漏洞，并且当这两个容器使用的时候，会由于我们制定的应对规则而将这两个容器的状态设置为隔离的状态，保证了这两个容器和安全：
此外，值得注意的是，当我们删除我们刚刚配置好的应对规则时，就可以配置将对应隔离状态的容器解除隔离。但是请注意：
- 隔离操作不适用于为主机事件触发的规则
- 每个规则可以有多个操作

4、总结

学习NeuVector容器安全平台是深入理解和应用容器安全领域的关键一步。通过学习过程，我们覆盖了多个关键方面。首先，我们了解了容器网络安全，学会了使用NeuVector进行深度网络审计，监控和控制容器通信流量，并通过安全组策略确保网络的安全性。其次，我们深入研究了运行时安全，掌握了NeuVector的行为分析技术，用于监测容器运行时的行为，以及实时检测漏洞和攻击的方法。在威胁检测和防御方面，我们学习了NeuVector如何应对各种威胁，包括零日漏洞和未知威胁，通过蜜罐技术提供额外的安全防护。容器防火墙的使用也是学习的重点，我们了解了NeuVector提供的细粒度访问控制策略，确保容器之间的安全通信。此外，我们研究了合规性与报告功能，确保容器环境符合相关行业和法规标准，并学习了NeuVector提供的报告和分析工具，以便及时了解容器环境的安全状况。最后，通过NeuVector直观的界面，我们实现了对容器环境的可视化监控，从而更好地理解容器运行状态和安全事件。这样的全面学习过程使我们能够更有效地保障容器化应用的安全性，确保其在生产环境中的可靠性。