iheb-mrabet/cloudquarantine

# CloudQuarantine 事件驱动的 Kubernetes 运行时安全平台，用于检测、决策、自动化响应和事件取证。 CloudQuarantine 是一个为 Kubernetes 环境设计的运行时安全控制平面。它从 Falco 接收安全事件，评估风险，丰富工作负载上下文和行为分析，然后决定是否记录、告警、请求人工审批或自动隔离受影响的工作负载。 不仅仅是停留在检测上，CloudQuarantine 将运行时告警转化为具体的安全操作。 ## 为什么要使用 CloudQuarantine？ 运行时安全工具经常能检测到可疑活动，但将响应留给人类。这会在检测和遏制之间产生缺口。 CloudQuarantine 通过以下方式填补这一缺口： - 基于风险的决策 - 行为感知评分 - 自动隔离工作流 - 在自动化存在风险时进行人工审核 - 为每个事件提供取证可见性 这使它不仅作为一个检测层，而且作为一个轻量级的运行时安全平台。 ## 它能做什么 CloudQuarantine 可以： - 通过 Falco 检测可疑的容器活动 - 规范化和处理运行时事件 - 使用策略驱动的决策引擎对事件进行评分 - 通过 AI 风格的行为分析丰富决策 - 触发高风险工作负载的自动隔离 - 支持中等风险事件的人工审批 - 使用标签 + NetworkPolicy 隔离 Pod - 在关键场景中将对 Deployment 的副本数缩容至零 - 存储事件以供取证分析 - 在仪表板中展示事件和决策 - 实时通过 Telegram 发送告警 ## 核心概念 ``` Falco = detection CloudQuarantine = detection + decision + response + forensics ``` CloudQuarantine 不仅仅问“是否有可疑行为？” 它还会问： - 风险有多大？ - 这是重复发生的吗？ - 这发生在生产环境吗？ - 系统应该自动行动还是等待审批？ ## 高级架构 ``` Falco (Runtime Detection) ↓ Falcosidekick (Event Routing) ↓ CloudQuarantine Controller (FastAPI) ↓ Decision Engine (Risk Scoring) ↓ AI Behavior Layer (Repetition + Context) ↓ Response Engine (Playbooks) ↓ Kubernetes API ↓ Isolation / Quarantine / Scaling ↓ Forensics Store + Dashboard + Alerts ``` ## 关键特性 ### 运行时威胁检测 - 检测容器内的 shell 执行 - 检测可疑的 root 活动 - 实时处理 Falco 运行时事件 ### 基于风险的决策引擎 - 基于策略的评分 - 使用以下上下文进行感知评估： - 命名空间 - 工作负载类型 - 关键性 - 挂载和权限 - 明确的决策模式： - 仅记录 - 人工审核 - 自动隔离 ### 行为分析层 - 跟踪同一 Pod 上的重复活动 - 在命名空间级别跟踪异常模式 - 当可疑行为重复时提高评分 - 使决策比单纯的静态规则更具适应性 ### 自动响应 - 标记受影响的 Pod 为隔离状态 - 应用拒绝所有流量的 NetworkPolicy - 在需要时将拥有者的 Deployment 缩容至零 - 保留响应记录以供审查 ### 人工审批工作流 某些事件不会自动被包含。操作员可以从仪表板批准或拒绝操作。 ### 仪表板 - 带有筛选器的事件列表 - 严重程度和状态徽章 - 评分、原因和匹配规则 - AI 行为洞察 - 响应结果详情 - 待处理事件的批准 / 拒绝操作 ### 告警 - 实时事件意识的 Telegram 通知 ### 取证 - 事件持久化 - 时间线生成 - 用于调查的原始事件可见性 ## AI / 行为层 CloudQuarantine 包含一个轻量级的行为分析层，用于提升评分。 它观察以下模式： - 同一 Pod 上的重复可疑活动 - 同一命名空间内的重复可疑活动 - 之前的遏制后继续活动 这意味着单个 shell 事件可能只需要人工审核，而重复的 shell 活动会提高风险评分，并推动系统采取更强的遏制措施。 示例： - `demo-app` 中的第一个 shell → 中等风险 → 人工审核 - 同一 Pod 中的重复 shell → 评分上升 - `prod` 中的相同操作 → 自动隔离 - 基于 Deployment 的工作负载上的相同操作 → Deployment 缩容至零 ## 隔离能力 根据策略和工作负载类型，CloudQuarantine 可以执行： - Pod 打标 标记受影响 Pod 为已隔离 - 网络隔离 应用拒绝所有流量的 NetworkPolicy 以阻止通信 - 部署容器 解析 ReplicaSet → Deployment 所有权 将工作负载缩容至零以实现更强隔离 这些操作设计为 Kubernetes 原生且易于审计。 ## 事件生命周期 典型事件会经历以下流程： 1. Falco 检测到可疑行为 2. Falcosidekick 转发事件 3. CloudQuarantine 规范化负载 4. 过滤噪声和重复项 5. 收集工作负载上下文 6. 计算风险评分 7. 行为分析根据需要调整评分 8. 做出决策： - 仅记录 - 人工审核 - 自动隔离 9. 执行响应 10. 存储事件并在仪表板中展示 11. 如果已配置，发送 Telegram 告警 ## 示例演示场景 ### 1) 人工审核场景 在非生产命名空间中的 Pod 内触发一个 shell： ``` kubectl exec -it test-shell -n demo-app -- sh ``` 预期结果： - 仪表板上出现事件 - 中等风险评分 - 决策模式 = 人工审核 - 操作员可以批准或拒绝 ### 2) 自动隔离场景 在生产环境中触发相同类型的事件： ``` kubectl exec -it test-shell -n prod -- sh ``` 预期结果： - 高风险评分 - 自动隔离 - Pod 被标记并网络隔离 ### 3) 部署容器场景 在基于 Deployment 的 Pod 内触发一个 shell： ``` kubectl exec -it -n prod -- sh ``` 预期结果： - 解析 Deployment 所有者 - Deployment 缩容至零 - 存储带有完整响应详情的事件 ## 技术栈 - Kubernetes (k3d) - Falco - Falcosidekick - FastAPI - React - PostgreSQL - Helm - Telegram Bot API ## 使用场景 CloudQuarantine 适用于以下环境： - 运行 Kubernetes 的 SaaS 平台 - 云原生初创公司 - 金融科技 / 受监管的工作负载 - 多租户集群 - DevSecOps 实验室和自动化工作流 - 运行时安全演示和研究 ## 路线图 / 后续改进 潜在的下一步包括： - Slack / Teams 告警 - 多集群控制平面 - 更丰富的策略引擎集成（OPA / Kyverno） - 事件回放模式 - 更高级的异常检测 - 截图丰富的仪表板分析 - 审批工作流的基于角色的访问控制 ## 作者 Iheb Mrabet 一个有志于成为 DevSecOps 工程师的开发者 ## 最后说明 CloudQuarantine 的设计目标是像一个轻量级运行时安全平台，而不仅仅是一个检测演示。 它展示了： - 对 Kubernetes 运行时安全的理解 - 基于风险的自动化 - 事件响应设计 - 行为感知检测 - 全栈的 DevSecOps 思维 ## 📸 截图 ### 仪表板概览  ### 事件详情  ### 部署容器  ## 🎥 演示视频 [下载演示视频](docs/demo/demo.mp4)

标签：AI行为分析, Deployment 缩容, Falco 集成, FTP漏洞扫描, Kubernetes 安全, Pod 隔离, SEO: CloudQuarantine, SEO: Kubernetes 安全防护, SEO: 运行时安全平台, Telegram 告警, Web截图, 事件溯源, 事件驱动, 仪表盘监控, 响应与隔离, 子域名突变, 安全编排, 容器安全, 手动审批, 时间线生成, 模型鲁棒性, 测试用例, 生产环境防护, 策略引擎, 网络安全挑战, 网络策略, 自动化隔离, 轻量级安全平台, 风险评分