本博客地址：https://security.blog.csdn.net/article/details/130789465

一、Kubernetes安全监测工具kube-bench

kube-bench是一个用Golang开发的、由Aqua Security发布的自动化Kubernetes基准测试工具，它运行CIS Kubernetes基准中的测试项目。这些测试项目是用YAML语言编写的，方便后续根据CIS基准测试的标准来进行扩展。

互联网安全中心（CIS）是一个全球性的非营利组织，其任务是确定、开发、验证、升级和维持针对网络防御的最佳解决方案。CIS发布了Kubernetes的基准测试，集群管理员可以使用该基准测试来确保集群遵循推荐的安全配置。

kube-bench可以使用kube-bench bin文件直接在节点上运行：

kube-bench node --benchmark cis-1.6
kubectl logs kube-bench-xxxxx

运行kube-bench后，通过查看kube-bench pod的运行日志获取基准测试的汇总结果。需要重点关注的是FAIL项，另外没有完全通过的条目也需要关注，对这些条目进行分析，获知未通过项所带来的风险，根据风险项的影响制定风险缓解计划。

参考文献：https://blog.51cto.com/u_15966109/6171398

二、Kubernetes安全策略配置工具kube-psp-advisor

kube-psp-advisor是一个实用的Kubernetes安全配置工具，通过它可以方便地根据实时运行的Kubernetes环境或者依据用来生成Pod的yaml文件来创建Pod安全策略。

Kubernetes Pod安全策略是一种集群级资源，用于控制Pod的安全规则、限制Pod的访问权限。通过Pod安全策略可以对以下功能和特性进行限制：

● 运行特权容器。
● 容器运行的用户。
● 访问主机进程或网络命名空间。
● 访问主机文件系统。
● Linux功能、Seccomp或SELinux配置文件。

kube-psp-advisor有2个子命令：

● kube-psp-advisor inspect：用于检查Kubernetes集群和对Pod声明文件进行检查。inspect指令连接到API Server，扫描给定命名空间或整个集群工作负载的安全上下文，并根据安全上下文生成Pod安全策略；
● kube-psp-advisor convert：Convert指令不需要连接API Server即可工作，读取包含具有Pod规范的对象的单个yaml声明文件并基于该文件生成Pod安全策略；

安装和运行kube-psp-advisor：

git clone https://github.com/sysdiglabs/kube-psp-advisor.git
cd kube-psp-advisor && make build
./kube-psp-advisor --namespace=psp-test

kube-psp-advisor运行完成后，会在stdout中生成Pod安全策略配置文件，接下来只需要应用这个Pod安全策略配置文件即可：

./kube-psp-advisor --namespace psp-test > psp-test.yaml && cat psp-test.yaml
kubectl apply -f psp-test.yaml

三、Kubernetes渗透测试工具kube-hunter

前因：Kubernetes的安全建议和安全公告发布在https://kubernetes.io/docs/reference/issues-security/security/，通过订阅安全公告来跟踪Kubernetes中发现的新安全漏洞，在有新的安全隐患报告后，能够及时进行堵漏。为了避免漏掉重要的安全漏洞公告，可以通过定期检查集群是否有任何已知CVE来获知当前环境的漏洞情况。

后果：Aqua开发和维护了开源的kube-hunter工具，可帮助识别Kubernetes集群中的已知安全问题。

安装和运行kube-hunter：

git clone https://github.com/aquasecurity/kube-hunter.git
./kubectl create -f job.yaml
./kubectl get pods

kube-hunter安全漏洞报告中出现的漏洞问题通常来说都是十分紧急的安全问题，需要立即有针对性地修复。

四、系统平台信息扫描和检索工具Osquery

Osquery可以高效地检查操作系统的信息，生成操作系统的数据，通过对这些数据进行分析来对系统安全问题进行分析和监控。

它的具体逻辑是将操作系统中的信息扫描生成关系型数据库表，然后对数据库中保存的操作系统信息进行SQL查询以分析操作系统数据。在Osquery中，SQL table代表操作系统中的一些抽象概念，例如正在运行的进程、加载的内核模块、打开的网络连接、浏览器插件、硬件事件或文件散列值等。

Osquery的安装：

curl -L https://pkg.osquery.io/rpm/GPG | tee /etc/pki/rpm-gpg/RPM-GPG-KEY-osquery
yum-config-manager --add-repo https://pkg.osquery.io/rpm/osquery-s3-rpm.repo
yum-config-manager --enable osquery-s3-rpm
yum install osquery

Osquery的使用：

# 进入使用状态
osqueryi
# 输入查询命令，例如查询所有用户信息
> SELECT * from users;

参考文献：https://blog.csdn.net/UbuntuTouch/article/details/124464826

五、数据脱敏方案ShardingSphere

ShardingSphere是一整套开源的分布式数据库中间件解决方案，它由Sharding-JDBC、Sharding-Proxy、Sharding-Sidecar这3款相互独立，却又能够混合部署配合使用的产品构成。它们均能够提供标准化的数据分片、分布式事务和分布式治理功能，可适用于如单机JVM和云原生环境等多种应用场景。

数据脱敏模块属于ShardingSphere分布式治理这一核心功能下的子功能模块。它能够对用户输入的SQL进行自动解析，并依据配置好的脱敏规则对SQL进行改写，从而实现对原文数据进行脱敏或加密。并将原文数据及密文数据同时存储到底层数据库，也可以配置只存储脱敏后的数据而忽略原文数据。在用户查询数据时，它又从数据库中取出密文数据，并对其解密，最终将解密后的原始数据返回给用户。

ShardingSphere分布式数据库中间件自动化和透明化了数据脱敏过程，让用户无须关注数据脱敏的实现细节，像使用普通数据那样使用脱敏数据。此外，无论是已在线业务进行脱敏改造，还是新上线业务使用脱敏功能，ShardingSphere都有针对性地提供了一套相对完善的解决方案。

ShardingSphere提供的Encrypt-JDBC和业务代码部署在一起。业务方通过Encrypt-JDBC访问数据库。Encrypt-JDBC实现了所有JDBC标准接口，所以对业务代码不会带来影响，业务代码无须做额外改造即可兼容使用。

通过Encrypt-JDBC接入后，业务代码所有与数据库的交互行为转换为由Encrypt-JDBC来负责处理，在应用层只需要配置好脱敏规则即可。作为业务代码与底层数据库中间的桥梁，通过Encrypt-JDBC可以拦截用户行为，并在数据库交互的过程中嵌入执行流程，改造数据请求行为。

参考文献：https://blog.csdn.net/qq_43843037/article/details/112741161

六、云原生持续交付模型GitOps

GitOps是一种适用于云原生架构的持续交付模型，它在传统的CI/CD模型上针对云原生应用的特点进行了规范及功能性扩展，它的一个重要思想是：基础设施即代码（IaC）。IaC把软件运行的基础环境也进行声明式的定义，包括应用运行所需要的组件，如消息代理、数据库定义、网络定义和监控运维方式定义等。

IaC是把应用程序本身和应用运行所依赖的基础设施通过源代码的方式进行编辑和定义，并存放在Git库中。Git库本身就有代码版本管理的能力，通过将应用程序全部的相关信息都以代码的方式存储在版本库中，实现了基础设施版本化。GitOps通过自动比对当前运行环境的版本与目标定义的运行环境版本之间的差异，采用自动化的方式来纠正差异，以声明式的方式对基础设施进行管理。

GitOps有三条基本的原则：

● 任何能够被描述的内容都必须存储在Git库中，通过检查比较实际环境的状态与代码库上的状态是否一致，来决定如何更新环境。
● 对环境和应用程序的所有操作都是由配置库更新而自动触发的，GitOps的触发机制是Pull模式（相对于Push的概念）。
● 调用Kubernetes的API接口或者控制器应该遵循Operator模式。

GitOps流程如图：

上图是GitOps从代码提交到应用部署上线的流水线过程，可以看到整个流程都是围绕Git库工作的。Git库有两个，分别是代码库和配置库。

具体的流程是：

● 开发人员将更新的代码推送到Git代码库，CI工具获取更改并最终构建容器镜像；
● Config Updater（配置更新器）检测到有新的镜像产生时，就从存储库中提取新镜像，然后在Git配置库中更新其声明文件；
● Deploy Operator会检测到集群状态未更新（实际运行的状态与配置库中的状态有差别），最终的状态是以Git配置库中的为准；
● 于是GitOps从配置库中提取已更改的配置清单，根据配置清单来执行更新操作，最终将新镜像部署到生产集群中。

七、渗透测试与代码扫描工具ZAP

ZAP的全称是OWASP Zed Attack Proxy，是一款开源的、跨平台的、支持对Web应用程序进行集成渗透测试的工具。主要覆盖了安全性测试里的渗透测试，它通过对系统进行模拟攻击和分析来确定系统是否存在安全漏洞以及存在什么安全漏洞。ZAP以代理的形式来实现渗透性测试，它将自己作为浏览器与应用之间交互的一个中间人，浏览器与服务器的任何交互都将经过ZAP，ZAP则可以通过对其抓包进行分析和扫描。

ZAP提供了两种扫描模式：Automated Scan（自动扫描）和Manual Explore（手动扫描）。在通常情况下，是将ZAP集成进DevSecOps全流程，在每次有新功能并入时，自动触发编译构建和部署运行，然后基于ZAP对运行的业务进行安全测试。具体的集成方法我在另一篇博客中已经有所提及了：https://security.blog.csdn.net/article/details/130734964

八、软件包扫描工具D-check

Dependency-Check用于识别项目依赖项并检查这些依赖项中是否存在任何已知和公开披露的漏洞。它的核心功能是通过其包含的一系列分析器来探测项目的依赖，收集依赖的各类信息，通过这些信息来确认其CPE（通用平台软件依赖信息），一旦CPE确认，就可以罗列出CVE。收集有关依赖项的信息后，将其与本地的CPE库数据进行对比，如果检查发现扫描的组件存在已知的、易受攻击的漏洞则标识，最后生成报告进行展示。

Dependency-Check提供命令行界面、Maven插件、Ant任务和Jenkins插件，可以嵌入流水线中执行。核心引擎包含一系列分析器，用于检查项目依赖项、收集有关依赖项的信息片段（称为证据）。然后使用证据来识别给定的依赖项，在报告中列出相关的常见漏洞CVE条目。

九、开源API网关Kong

Kong是云原生社区最为主流的开源网关组件之一，它是基于OpenResty编写的高可用、易扩展的开源API网关项目。Kong提供了易于使用的RESTful API来操作和配置API管理系统，社区还有与Kong相配合的Konga前端项目，提升易用性。Kong在可扩展能力方面也十分突出，它可以水平扩展多个Kong服务实例，通过前置的负载均衡配置把请求均匀地分发到各服务实例，来应对大并发情况下的网络请求。

Kong网关工作模型如图：

原生的Kong主要有三个组件：

● Kong Server：基于Nginx的服务器，用来接收API请求。
● Apache Cassandra/PostgreSQL：用来存储操作数据，在测试环境，也可以不用数据库存储，可采用将配置存储在文件系统中的方式。
● Kong Dashboard：官方推荐UI管理工具，也可以使用开源的Konga平台。

Kong的一大优势是支持采用插件机制来进行功能定制，原生的Kong本身已经具备了安全、限流、日志、认证、数据映射等基础插件能力，同时也可以很方便地通过Lua脚本定制自己的插件。插件可以以动态插拔的模式，实现Kong网关能力的扩展。Kong社区提供了多种认证插件，如下所示：