BadBoy0170/k8s-security-hardener

# K8s 安全强化器 ## 架构 ``` ┌─────────────────────────────────────────────────────────────────┐ │ K8s API Server │ │ │ │ │ ┌─────────────▼──────────────┐ │ │ │ Admission Webhook │ Blocks bad deploys │ │ │ cmd/webhook │ before they land │ │ └─────────────┬──────────────┘ │ └─────────────────────────┼───────────────────────────────────────┘ │ ┌───────────────▼────────────────────┐ │ Scanner Engine │ │ ┌─────────┐ ┌─────────────────┐ │ │ │ RBAC │ │ Workloads │ │ │ │ Scanner │ │ Scanner │ │ │ ├─────────┤ ├─────────────────┤ │ │ │ Secrets │ │ Network Policy │ │ │ │ Scanner │ │ Scanner │ │ │ └─────────┘ └─────────────────┘ │ │ │ │ ┌──────────────┐ ┌─────────────┐ │ │ │ Graph Attack │ │eBPF Runtime │ │ │ │ Path (gonum) │ │ Monitor │ │ │ └──────────────┘ └─────────────┘ │ │ │ │ ┌──────────────────────────────┐ │ │ │ LLM Auto-Remediation │ │ │ │ (Ollama / dolphin-llama3) │ │ │ └──────────────────────────────┘ │ └───────────────┬────────────────────┘ │ JSON findings ┌───────────────▼────────────────────┐ │ Wazuh │ │ Decoders → Rules → Active Response │ │ Pod isolation on Critical alerts │ └────────────────────────────────────┘ ``` ## 项目结构 ``` k8s-security-hardener/ ├── cmd/ │ ├── scanner/main.go # CLI / CronJob entrypoint │ └── webhook/main.go # Admission controller entrypoint ├── internal/ │ ├── auth/client.go # K8s API authentication (in-cluster + kubeconfig) │ ├── scanners/ │ │ ├── rbac.go # Wildcard permissions, exec access checks │ │ ├── workloads.go # Privileged containers, root UID, missing limits │ │ ├── secrets.go # Hardcoded secrets in env vars │ │ └── network.go # Missing default-deny NetworkPolicies │ ├── graph/attack_path.go # Dijkstra's attack-path analysis (gonum) │ ├── ebpf/ │ │ ├── runtime.go # Linux eBPF monitor (sys_enter_execve) │ │ ├── runtime_stub.go # macOS no-op stub │ │ └── bpf_linux_stub.go # Linux type stubs (pre-bpf2go) │ ├── remediation/llm_patcher.go # Ollama LLM YAML patching │ ├── webhook/validator.go # ValidatingWebhookConfiguration handler │ └── report/ │ ├── models.go # SecurityFinding JSON schema │ ├── wazuh_shipper.go # File + syslog shipping to Wazuh │ └── console.go # Color-coded terminal output ├── deployments/ │ ├── scanner-cronjob.yaml # CronJob + least-privilege ClusterRole │ ├── webhook-deployment.yaml # Webhook Deployment + ValidatingWebhookConfiguration │ ├── wazuh/ │ │ ├── local_decoder.xml # Wazuh JSON decoder │ │ ├── local_rules.xml # Alert rules 110000–110005 (MITRE ATT&CK mapped) │ │ └── ossec-active-response.xml │ └── wazuh-active-response.sh # Pod isolation script for Wazuh agent ├── scripts/ │ └── gen-certs.sh # Self-signed TLS certificate generation └── go.mod ``` ## 快速入门 ### 前置条件 - Go 1.22+ - `kubectl` 配置针对集群（`kind`、`minikube` 或远程） - （可选）[Ollama](https://ollama.ai) 用于 LLM 自动修复 - （可选）Linux 5.8+ 内核，带有 BTF 以进行 eBPF 运行时监控 ### 构建 ``` go mod tidy go build -o bin/scanner ./cmd/scanner go build -o bin/webhook ./cmd/webhook ``` ### 在您的集群上运行 ``` # 控制台输出仅 — 不更改集群 ./bin/scanner --cluster-name=my-cluster --dry-run ``` ### 将发现结果发送到 Wazuh ``` ./bin/scanner \ --cluster-name=production \ --output-file=/var/log/k8s-hardener.log \ --syslog-addr=wazuh-manager:514 ``` ### LLM 自动修复 ``` # 默认模型：dolphin-llama3（使用 --ollama-model 修改） ollama serve ./bin/scanner --cluster-name=production --llm-fix --dry-run # 在不使用集群的情况下测试 LLM ./bin/scanner --mock-scan --llm-fix --ollama-model=dolphin-llama3 ``` ## 🔍 安全检查 ### RBAC 扫描器 | 规则 ID | 严重性 | 描述 | |---|---|---| | `RBAC-001` | 严重 | 带有通配符动词和资源的 ClusterRole | | `RBAC-002` | 高 | 角色授予 `pods/exec` 或 `pods/portforward` | | `RBAC-003` | 严重 | 主题绑定到通配符 ClusterRole | | `RBAC-004` | 高 | 命名空间范围的 Role 带有通配符权限 | ### 工作负载扫描器 | 规则 ID | 严重性 | 描述 | |---|---|---| | `WORKLOAD-001` | 高 | Pod `runAsUser: 0`（root） | | `WORKLOAD-002` | 严重 | 容器 `privileged: true` | | `WORKLOAD-003` | 高 | 容器 `runAsUser: 0` | | `WORKLOAD-004` | 中 | 缺少 `readOnlyRootFilesystem` | | `WORKLOAD-005` | 中 | `allowPrivilegeEscalation` 未设置为 `false` | | `WORKLOAD-006` | 中 | 没有资源限制（CPU/内存） | | `WORKLOAD-007` | 高 | `hostNetwork: true` | | `WORKLOAD-008` | 高 | `hostPID: true` | ### 机密扫描器 | 规则 ID | 严重性 | 描述 | |---|---|---| | `SECRET-001` | 高 | 环境变量中的硬编码凭证 | | `SECRET-002` | 中 | 机密存储在 `default` 命名空间中 | | `SECRET-003` | 低 | 带有敏感名称的机密密钥 — 审计访问 | ### 网络扫描器 | 规则 ID | 严重性 | 描述 | |---|---|---| | `NETWORK-001` | 高 | 命名空间缺少默认拒绝 **Ingress** 网络策略 | | `NETWORK-002` | 中 | 命名空间缺少默认拒绝 **Egress** 网络策略 | ### 图形攻击路径分析 (`GRAPH-001`) 使用 `gonum/graph` 构建Pod → ServiceAccounts → Secrets → Roles的定向图，并运行 **Dijkstra的最短路径** 以找到从面向公众的Pod到ClusterAdmin绑定服务账户的可利用路径。发现包括 `attack_path` 中的完整路径。 ### eBPF 运行时监控 (`EBPF-001`) 钩入 `sys_enter_execve` 内核跟踪点，并在容器意外执行可疑的二进制文件（`bash`、`curl`、`nc`、`socat` 等）时发出警报。 ## Wazuh 集成 ### 安装解码器和规则 ``` sudo cp deployments/wazuh/local_decoder.xml /var/ossec/etc/decoders/ sudo cp deployments/wazuh/local_rules.xml /var/ossec/etc/rules/ sudo systemctl restart wazuh-manager ``` ### 安装主动响应脚本 ``` sudo cp deployments/wazuh-active-response.sh \ /var/ossec/active-response/bin/k8s-isolate-pod.sh sudo chmod 750 /var/ossec/active-response/bin/k8s-isolate-pod.sh sudo chown root:wazuh /var/ossec/active-response/bin/k8s-isolate-pod.sh ``` 将 `deployments/wazuh/ossec-active-response.xml` 中的主动响应布线添加到 `/var/ossec/etc/ossec.conf`。 ### 警报规则 | 规则 ID | 级别 | 触发 | |---|---|---| | `110000` | 3 | 任何 k8s-hardener 事件 | | `110001` | 7 | 中等严重性发现 | | `110002` | 10 | 高严重性发现 | | `110003` | 12 | 严重严重性发现 | | `110004` | 14 | 严重 + 确认攻击路径 | | `110005` | 15 | eBPF 运行时威胁（反向shell / 可疑执行） | 规则 **110004** 和 **110005** 会自动触发主动响应脚本，该脚本应用拒绝所有 NetworkPolicy 以隔离受影响的Pod。 ## 接受控制器 在非合规工作负载到达集群之前阻止它们。 ``` # 生成自签名 TLS 证书 ./scripts/gen-certs.sh # 创建 TLS 密钥 kubectl create namespace security kubectl create secret tls k8s-hardener-webhook-tls \ --cert=certs/tls.crt --key=certs/tls.key -n security # 在 webhook-deployment.yaml 中填写 caBundle CA_BUNDLE=$(cat certs/ca.crt | base64 | tr -d '\n') # 将 $CA_BUNDLE 粘贴到 deployments/webhook-deployment.yaml 中的 caBundle 字段 # 部署 kubectl apply -f deployments/webhook-deployment.yaml # 验证 — 应该被拒绝： kubectl run bad-pod --image=nginx \ --overrides='{"spec":{"containers":[{"name":"bad-pod","image":"nginx","securityContext":{"privileged":true}}]}}' ``` ## LLM 修复 将易受攻击资源的原始 YAML 发送到本地 [Ollama](https://ollama.ai) 模型，该模型生成强化补丁。输出通过 `kubectl apply --dry-run=client`（在没有集群的情况下回退到结构化 YAML 解析）进行验证。 ``` # 拉取模型（首次运行） ollama pull dolphin-llama3 # 运行 — LLM 补丁附加到每个发现的修复字段 ./bin/scanner --llm-fix --ollama-model=dolphin-llama3 --cluster-name=production ``` 通过 `--ollama-model` 支持：`dolphin-llama3`、`llama3`、`codellama` 或 Ollama 提供的任何模型。 ## 发现 JSON 架构 所有发现都以换行符分隔的 JSON 发出，兼容 Wazuh 的 `JSON_Decoder`： ``` { "tool": "k8s-hardener", "timestamp": "2026-06-01T12:00:00Z", "severity": "Critical", "rule_id": "RBAC-001", "cluster_name": "production", "namespace": "default", "resource": "clusterrole/admin", "description": "ClusterRole has wildcard verbs and resources", "remediation": "Remove wildcard rules and apply least-privilege permissions.", "attack_path": "Pod/default/web → ServiceAccount/default/admin → ClusterRole/cluster-admin" } ``` ## 安全注意事项 - **只读扫描器** — 扫描器 ClusterRole 只具有 `get` 和 `list` 动词；它永远不会更改集群状态 - **失败时打开 webhook** — `failurePolicy: Ignore` 在 webhook 暂时不可用时保持集群运行；一旦 webhook 证明稳定性，请将其更改为 `Fail` - **安全日志文件** — 发现日志以模式 `0640`（所有者 + wazuh 组）写入 - **强化容器** — 所有提供的清单强制执行 `runAsNonRoot`、`readOnlyRootFilesystem` 和 `capabilities.drop: ALL` - **无硬编码机密** — 所有敏感值都通过标志或环境变量传递；`certs/` 和 `bin/` 是 gitignored ## Linux 兼容性 在 Linux 上无需代码更改即可运行： | 功能 | Linux | |---|---| | 所有静态扫描器 | ✅ 全部 | | 图形攻击路径分析 | ✅ 全部 | | LLM 修复 | ✅ 全部（需要 `ollama serve`） | | 接受 webhook | ✅ 全部（需要 TLS 证书） | | Wazuh 集成 | ✅ 全部（需要 `jq` + Wazuh 代理） | | eBPF 运行时监控 | ✅ 编译；需要 `go generate` + `clang` 以进行实时字节码 |

标签：Apex, API网关, C2, Docker镜像, EVTX分析, GitHub Advanced Security, Go, LLM, Ruby工具, Unmanaged PE, Wazuh, Webhook, Web截图, 企业级安全, 力导向图, 子域名突变, 安全加固, 容器安全, 攻击路径分析, 日志审计, 机器学习, 自动修复, 运行时检测, 静态代码扫描