brypreez/security-sentinel
GitHub: brypreez/security-sentinel
基于 Wazuh SIEM 的 Kubernetes 控制平面 SOAR 方案，实现静态 Pod 持久化攻击的实时检测与自动化清除。
Stars: 0 | Forks: 0
# security-sentinel
**生产级 Kubernetes 主动响应哨兵。自动化事件响应 (AIR) 引擎，集成了 Wazuh SIEM、自定义 XML 规则层、基于 Bash 的主动响应，以及用于实时集群安全运营的 6 面板 SOC 仪表盘。**
## 概述
本仓库是 **Kubernetes Control Plane Sentinel** 的信源——这是一个完全部署的 SOAR 流水线，用于防御 5 节点 Kubernetes HA 集群免受静态 Pod 持久化攻击和破坏性 API 活动。
系统分两个阶段运行：一个 **自动化响应引擎**，在 Kubelet 初始化之前检测并消除未授权的控制平面清单；以及一个 **安全运营中心**，通过 6 面板 Wazuh/Kibana 仪表盘提供集群 API 活动、操作者身份和缓解事件的实时可见性。
## 完整流水线架构
```
flowchart LR
A[K8s Master 1/2/3\n/etc/kubernetes/manifests] -->|inotify realtime FIM| B[Wazuh Agent\nlocation: local]
C[kube-apiserver\nAudit Log Stream] -->|JSON audit events| B
B -->|syscheck + audit events| D[Wazuh Manager\n192.168.40.20]
D -->|Rule 110003\nAudit normalization| E{Rule Engine}
D -->|Rule 110005\nFIM manifest match| E
E -->|Rule 110006\nLevel 12 - kube-system delete| F[Slack Webhook API\nAnsible Vault secured]
E -->|Active Response\nstdin JSON handshake| G[k8s-nuke.sh\nReaper Script]
F -->|Structured alert| H[#security-alerts\nSOC Channel]
G -->|Whitelist check\nMaintenance mode check\nrm -f manifest| I[Threat Neutralized\nMTTR under 3 seconds]
D -->|wazuh-alerts index| J[6-Panel SOC Dashboard\nKibana/Wazuh]
```
## 阶段 1 — 自动化响应引擎
### 威胁：静态 Pod 持久化
恶意 YAML 文件被投递到 `/etc/kubernetes/manifests` 后，将完全绕过 Kubernetes API server、RBAC 和审计日志。Kubelet 会直接加载它，赋予攻击者节点级别的持久性，且该持久性在执行 `kubectl delete` 后依然存活。Sentinel 通过 `inotify` 在 OS syscall 层运行——持续优于 Kubelet 的调和循环，从而在恶意清单初始化之前将其删除。
### 规则层 — 检测逻辑
**规则 110005** — FIM 触发器 (`wazuh/rules/local_rules.xml`):
```
550
/etc/kubernetes/manifests
CRITICAL: K8s Manifest Tampering Detected on $(agent.name) - file: $(file)
syscheck,k8s_security,pci_dss_11.5,gpg13_4.11,
```
### 主动响应 — k8s-nuke.sh
**工程决策：**
- **stdin JSON 握手** — Wazuh 通过 stdin 将完整警报作为 JSON 对象传递。PCRE 正则 (`grep -oP`) 提取精确的 `path` 字段，以实现手术式文件定位
- **智能白名单** — 正则守卫防止删除核心控制平面组件，无论规则是否触发。受保护组件：
```
WHITELIST="kube-apiserver|kube-controller-manager|kube-scheduler|etcd"
# 如果 FILE_PATH 匹配以上任意一项 → 记录日志并退出，不执行删除
```
- **维护模式熔断开关** — `/tmp/SENTINEL_OFF` 的存在会停止所有主动响应执行，允许进行授权的集群升级而不触发清除程序
- **零信任路径守卫** — 所有操作在执行前均针对 `SAFE_DIR=/etc/kubernetes/manifests` 进行验证
- **取证审计跟踪** — 每个事件都带有时间戳并记录到 `/var/ossec/logs/active-responses.log`，包含完整的原始 JSON 输入
### 主动响应绑定 (`ossec.conf`)
```
k8s-nuke
k8s-nuke.sh
filename
no
k8s-nuke
local
110005
```
`local ` 将响应动态路由到触发代理——无需硬编码代理 ID。可从 3 个节点水平扩展至 300 个，无需更改配置。
### 已验证的集群级部署
| Node | IP | k8s-nuke.sh | 主动响应 | 白名单 | 维护模式 |
|------|----|-------------|----------------|-----------|-----------------|
| k8s-master-1 | 192.168.20.10 | 已部署 | ✅ 已验证 | ✅ 激活 | /tmp/SENTINEL_OFF |
| k8s-master-2 | 192.168.20.11 | 已部署 | ✅ 已验证 | ✅ 激活 | /tmp/SENTINEL_OFF |
| k8s-master-3 | 192.168.20.12 | 已部署 | ✅ 已验证 | ✅ 激活 | /tmp/SENTINEL_OFF |
## 阶段 2 — 安全运营中心
### 规则层 — 审计与行为检测
**规则 110003** — K8s 审计归一化：
摄取来自 kube-apiserver 的原始 Kubernetes JSON 审计日志流。将 `data.verb`、`data.objectRef.namespace`、`data.objectRef.resource` 和 `data.sourceIPs` 映射到 Wazuh 的内部字段架构，以实现一致的查询和仪表盘可视化。
**规则 110006** — 12 级行为警报：
针对 `kube-system` 命名空间内的破坏性 API 操作（`delete`、`patch`）触发。12 级分类通过 webhook 集成直接路由到 Slack——即时 SOC 通知高风险集群活动。
### 6 面板 SOC 仪表盘 (Wazuh/Kibana)
基于 `wazuh-alerts-*` 索引构建，使用 KQL 过滤的可视化：
| 面板 | 类型 | 用途 |
|-------|------|---------|
| 命名空间分布 | 饼图 | 爆炸半径可视化——按命名空间的资源分配 |
| 紧急度指标 | 指标计数器 | 12 级+安全事件的实时计数 |
| 身份审计 | 数据表 | 每次 API 调用的 `user.username` 跟踪——行为者归因 |
| API Verb 分解 | 水平条形图 | `get` 与 `delete` 的数量比率——行为基线化 |
| Sentinel 审计跟踪 | 过滤表 | 来自 k8s-nuke.sh 的每个自动化缓解事件的专用日志 |
| 高风险时间线 | 日期直方图 (KQL 过滤) | 破坏性集群活动的时间峰值 |
## 纵深防御架构
| 层级 | 控制 | 防护对象 |
|-------|---------|-----------------|
| API Server | RBAC + Admission Controllers | 未授权的 API 请求 |
| 主机文件系统 | Wazuh FIM + k8s-nuke.sh | 绕过 API 的静态 Pod 持久化 |
| 行为层 | 规则 110006 + Slack | kube-system 中的破坏性 API 活动 |
| 审计层 | 规则 110003 + SOC 仪表盘 | 行为者归因和取证跟踪 |
Sentinel 专门解决了 Admission Controllers (OPA/Kyverno) 无法覆盖的盲区——即通过直接写入主机文件系统来完全绕过 API server 的攻击。
## 检测到修复的时间线
| 阶段 | 组件 | 延迟 |
|-------|-----------|---------|
| 检测到文件变更 | Wazuh FIM (inotify) | < 1s |
| 规则 110005 匹配 | Wazuh Manager | < 1s |
| Slack 警报已送达 | Webhook API | < 3s MTTD |
| 主动响应已分发 | Manager → 本地代理 | < 1s |
| 白名单 + 维护检查 | k8s-nuke.sh | 毫秒级 |
| 未授权清单已删除 | rm -f | < 3s MTTR |
## Secrets 管理
所有凭证通过 **Ansible Vault** 管理——生产级的静态 Secret 管理。
- Slack webhook URL 仅存在于 `ansible/vars/secrets.yml` 中，使用 `ansible-vault encrypt` 加密
- Vault 密码仅本地存储于 `~/.ansible_vault_pass` (`chmod 600`)——从未提交
- 在每个引用敏感变量的 Ansible 任务上设置 `no_log: true`——即使在使用 `-v` 详细模式时，webhook URL 也不会出现在 playbook 输出中
- 推送前 Secret 扫描已验证干净：`Get-ChildItem -Recurse -File | Select-String -Pattern "hooks.slack.com"` ——版本控制中零真实凭证
- `.gitignore` 明确阻止 `*.vault_pass`、`secrets.yml.unencrypted` 和所有 `.env` 文件
## 仓库结构
```
security-sentinel/
├── README.md
├── .gitignore
├── ansible/
│ ├── vars/
│ │ └── secrets.yml # Ansible Vault - slack_webhook_url (encrypted)
│ └── playbooks/
│ └── wazuh_self_healing.yml # RFC 6724 fix + Slack alert on remediation
└── wazuh/
├── rules/
│ └── local_rules.xml # Rules 110003, 110005, 110006
└── active-response/
└── k8s-nuke.sh # Reaper - whitelist, maintenance mode, PCRE parsing
```
## 环境
| 组件 | 详情 |
|-----------|--------|
| Wazuh 版本 | 4.14.3 |
| 监控节点 | 3 个 K8s 控制平面 + 2 个工作节点 + 3 个 Proxmox 主机 |
| Agent 数量 | 8 |
| 集群 | 5 节点 K8s HA (kubeadm), etcd quorum |
| 警报目的地 | Slack #security-alerts |
| 合规性 | PCI DSS 11.5, GPG13 4.11, MITRE ATT&CK T1485, NIST 800-53 |
| MTTD | < 5 秒 |
| MTTR | < 3 秒 |
## 路线图
- [ ] 通过 Wazuh Manager 上的 `agent.conf` 集中管理 FIM 配置
- [ ] k8s-nuke.sh 中基于哈希的白名单，用于授权清单验证
- [ ] K8s NetworkPolicy 执行层
- [ ] 通过 ArgoCD 实现 OPA/Gatekeeper 策略即代码
## 相关
- [`homelab`](https://github.com/brypreez/homelab) — 完整基础设施仓库 (Proxmox, Kubernetes, Terraform, Ansible, 可观测性)
*按生产标准运营。此处所有内容均已验证可用。*
标签：Ansible Vault, Bash 脚本, DevSecOps, DNS 反向解析, Force Graph, IT 运维, Kibana 仪表盘, Kubernetes 安全, Slack 告警, SOAR, SOC 运维, Wazuh, XML 规则, 上游代理, 入侵检测系统, 合规性审计, 子域名突变, 安全数据湖, 安全编排与自动化响应, 应用安全, 控制平面加固, 文件完整性监控 (FIM), 模型鲁棒性, 网络安全, 网络安全审计, 自动化事件响应, 蜜罐与主动防御, 越狱测试, 隐私保护, 静态 Pod 防护, 高可用集群