增强您的 Kubernetes 服务网格安全性！！
mesh-kridik 是一个开源安全检查器，对运行 Istio 服务网格的 Kubernetes 集群执行各种安全检查，并输出安全报告。
安全检查测试完整实现了 istio 安全最佳实践。
在运行 Istio 服务网格的 Kubernetes 集群上执行安全检查，并利用 OPA（Open Policy Agent）强制执行安全规则，输出审计报告包括： 安全问题根因以及建议的修复措施。
git clone https://github.com/chen-keinan/mesh-kridik
cd mesh-kridik
make build
执行 Mesh-Kridik 不带任何标志，执行所有测试
./mesh-kridik
使用标志执行 mesh-kridik，按需执行测试
Usage: mesh-kridik [--version] [--help] <command> [<args>]
Available commands are:
-r , --report : run security checks and generate remediation report
-i , --include: execute only specific security check, example -i=1.1
-e , --exclude: ignore specific security check, example -e=1.1,2.0
执行测试并生成失败测试报告及其修复建议
./mesh-kridik -r
Kube-kridik 暴露了一个用户插件的钩子 示例 ：
go build -buildmode=plugin -o=~/<插件文件夹>/<插件>.so ~/<插件文件夹>/<插件>.go
cp ~/<插件文件夹>/<插件>.so ~/.kube-kridik/plugins/compile/<插件>.so
Kube-kridik 支持以下规范，并且可以轻松扩展：
可以通过修改 ~/.mesh-kridik/security/mesh/istio 文件夹下的规范文件来轻松扩展这些规范。
| 名称 | 描述 | 影响 |
|---|---|---|
| 双向 TLS | Istio 双向 TLS 代理默认配置为宽松模式 | 代理将同时接受双向 TLS 和明文流量 |
| 更安全的 Istio 授权策略模式 | 使用“ALLOW 配合正向匹配”或“DENY 配合负向匹配”模式 | 这些授权策略模式更安全，因为在策略不匹配时最坏情况是意外的 403 拒绝，而非授权策略绕过。 |
| 授权策略中的路径规范化 | 授权策略的强制执行点是 Envoy 代理，而非后端应用程序中的常规资源访问点 | 不匹配可能导致意外拒绝或策略绕过 |
| 出口流量的 TLS 发起 | 在 ServiceEntry 上使用 DestinationRule 处理出口流量 | 不对出口到外部服务的流量使用 TLS 发起，将以明文发送 |
| 协议检测 | 显式声明服务协议 | 检测错误可能导致意外的流量行为 |
| CNI 支持 | Istio 透明流量捕获 | 并非所有网络流量都会被捕获 |
| 过宽的主机 | 避免在 Gateway 中设置过宽的主机 | 可能导致意外暴露不应有的域名 |
| 限制 Gateway 创建权限 | 限制 Gateway 资源的创建权限，仅授予受信任的集群管理员 | 可能导致非信任用户创建网关 |
| 配置下游连接数限制 | 根据部署中单个网关实例所需的并发连接数，更新配置映射中的 global_downstream_max_connections。达到限制后，Envoy 将开始拒绝 TCP 连接 | 不对下游连接数做限制可能被恶意攻击者利用 |
| 配置第三方服务账户令牌 | 建议配置第三方令牌，因为第一方令牌的属性安全性较低 | 第一方令牌属性安全性较低，可能导致身份验证漏洞 |
| 控制面 | 默认情况下，Istiod 会暴露一些未经验证的明文端口以方便使用 | 暴露了 XDS 服务端口 15010 和调试端口 8080，且未经身份验证的明文传输 |
| 数据面 | 代理暴露了多种端口 | 与代理运行在同一个 Pod 中的应用可以访问这些端口；Sidecar 与应用程序之间没有信任边界 |
| 理解流量捕获限制 | 通过设置 meshConfig.outboundTrafficPolicy.mode 来保护出口流量 | 外部服务访问将不受控制 |