anishvedant/aegispipeline

GitHub: anishvedant/aegispipeline

一个云原生与 Kubernetes 安全自动化实验室,将基础设施扫描、密钥检测、云态势审计和准入控制整合为端到端的安全流水线。

Stars: 0 | Forks: 0

# AegisPipeline [![安全门禁](https://static.pigsec.cn/wp-content/uploads/repos/cas/06/06e88fd53e9a36da6b500fffaff91578a478347f84a0f3e145327643542c60d6.svg)](https://github.com/anishvedant/aegispipeline/actions/workflows/security.yml) AegisPipeline 是一个云端与 Kubernetes 安全自动化实验室,展示了基础设施安全团队如何在部署前扫描基础设施、在部署后验证实时的 AWS 状态、在准入阶段执行 Kubernetes 安全护栏,并保留证据以供审查。 该项目结合了 Terraform、AWS、Checkov、Trivy、Gitleaks、Prowler、K3s、Kubernetes、Kyverno、Python 报告脚本、Docker、Prometheus、Grafana 以及 GitHub Actions。 ## 项目目标 云端与 Kubernetes 的安全事件往往源于配置失误,而非复杂的漏洞利用。常见的例子包括公开的对象存储、通配符 IAM 权限、暴露的管理端口、提交到代码库的凭证、特权容器、可变的镜像标签,以及没有任何资源限制的工作负载。 AegisPipeline 将这些风险转化为自动化控制: 1. 在部署前扫描基础设施和应用程序构建产物。 2. 通过 Terraform 部署加固的 AWS 基准环境。 3. 使用 Prowler 扫描实时的 AWS 账户。 4. 将发现的问题标准化为一份报告。 5. 在配置后使用 Grok 对发现的问题进行优先级排序,或使用确定性的离线启发式算法。 6. 使用 Kyverno 强制执行 Kubernetes 工作负载策略。 7. 证明不安全的工作负载会被拦截,且经过加固的工作负载会被成功准入。 ## 架构 ``` Developer push or pull request | v +----------------------------------------------------------+ | GitHub Actions | | | | Checkov Blocking IaC policy gate | | Gitleaks Blocking full-history secrets gate | | Trivy Secondary IaC and image visibility | +----------------------------------------------------------+ | v Hardened Terraform staging | v +----------------------------------------------------------+ | AWS deployment | | | | S3 model-artifact bucket | | Public-access block, encryption, versioning | | Restricted security group | | Least-privilege IAM policy | +----------------------------------------------------------+ | v Prowler live AWS posture scan | v aggregate.py -> summary.json and SUMMARY.md | v ai_triage.py -> AI_REPORT.md | v +----------------------------------------------------------+ | AWS EC2 single-node K3s cluster | | | | Kyverno admission controller | | GrokGuard ClusterPolicies | | Insecure workload denied | | Hardened workload admitted | +----------------------------------------------------------+ ``` ## 三层安全防御 ### 1. 部署前安全 基础设施代码和应用程序构建产物在受信任之前会先接受检查: - **Checkov** 扫描 Terraform 和 Kubernetes 配置,包括 `policies/` 中的自定义所有权标签策略。 - **Gitleaks** 扫描完整的 Git 历史记录,以查找 token、私钥和其他凭证。 - **Trivy** 针对 Terraform 和 Kubernetes 的配置错误提供第二意见,并扫描加固的 Docker 镜像以查找操作系统和库漏洞。 在当前的实验室工作流中,Checkov 和 Gitleaks 是阻断性控制措施。Trivy 会生成供审查的构建产物,但不会阻断分支合并,这避免了使作品集分支依赖于上游瞬时的镜像扫描结果。在建立批准的漏洞基准和异常处理流程后,生产环境的推广可以将 Trivy 的 `exit-code` 更改为 `1`。 ### 2. 实时 AWS 状态验证 Terraform 从 `terraform/deploy/` 部署加固的预发环境配置。随后,Prowler 会扫描真实的 AWS 账户,并导出 OCSF JSON 以及面向合规性的 CSV 报告。这将静态代码审查与运行时云状态管理区分开来。 ### 3. Kubernetes 准入控制执行 Terraform 在 AWS EC2 实例上配置了一个轻量级的 K3s Kubernetes 集群。Kyverno 作为准入控制器在该集群内运行。在 Kubernetes 准入工作负载之前,Kyverno 会根据 GrokGuard 策略对其进行检查。 这些策略会拦截: - `hostPath` 卷 - 特权容器 - 未声明以非 root 用户身份运行的容器 - 使用可变 `:latest` 标签的镜像 - 没有 CPU 和内存限制的容器 故意设置的不安全工作负载会被拒绝。经过加固的工作负载会被准入并达到 `1/1 Running` 状态。 ## 已部署内容 | 层级 | 已部署或实现的内容 | |---|---| | AWS 安全基准 | S3 模型构建产物存储桶、AES-256 服务端加密、版本控制、公共访问屏蔽、所有权标签、受限的安全组、最小权限 S3 读取策略 | | AWS 状态 | Prowler 账户扫描结果导出为 JSON-OCSF 和合规性 CSV 文件 | | Kubernetes 基础设施 | EC2 上的单节点 K3s 控制平面、弹性 IP、加密的 GP3 根卷、IMDSv2、仅限管理员 CIDR 访问的 SSH 和 Kubernetes API | | 准入控制 | 包含三个 GrokGuard ClusterPolicies 的 Kyverno | | 工作负载测试 | 故意设置的不安全模型服务部署被拒绝,加固后的部署被准入 | | 报告 | 标准化的 JSON 和 Markdown 摘要、按风险分级的分诊报告、Kubernetes 执行证据 | | 可选监控 | Prometheus exporter 和 Grafana/Prometheus Docker Compose 堆栈 | | 多云测试夹具 | 安全和不安全的 AWS 及 Azure Terraform 示例,在记录的实验室运行期间未部署 Azure | ## 仓库布局 ``` .github/workflows/ security.yml Main Terraform, secret, and container security workflow security-k8s.yml Kubernetes manifest visibility workflow docker/ app.py Minimal FastAPI finding-ranking service Dockerfile Hardened image, pinned dependencies, non-root execution Dockerfile.insecure Deliberately weak image for scanner testing docs/ SETUP.md Complete setup, deployment, verification, and teardown guide k8s/ policies/ Kyverno GrokGuard ClusterPolicies workloads/insecure/ Deliberately non-compliant deployment workloads/secure/ Hardened deployment that passes GrokGuard monitoring/ security_exporter.py Converts summary.json into Prometheus metrics prometheus.yml Scrapes the exporter every 15 seconds docker-compose.yml Local Prometheus and Grafana stack policies/ require_project_tag.yaml Custom Checkov ownership-tag rule reports/ SUMMARY.md Aggregated scanner findings AI_REPORT.md Risk-prioritized findings and drafted remediation compliance/ Prowler compliance exports k8s/ Live Kubernetes node, policy, event, denial, and workload evidence scripts/ aggregate.py Normalizes Checkov, Trivy, Gitleaks, and Prowler output ai_triage.py Grok-enabled or offline heuristic risk ranking terraform/ aws/insecure/ Deliberately insecure AWS fixture aws/secure/ Hardened AWS fixture aws/k3s-cluster/ EC2-based K3s cluster azure/insecure/ Deliberately insecure Azure fixture azure/secure/ Hardened Azure fixture deploy/ Controlled Terraform deployment staging area ``` ## 核心组件 ### Terraform Terraform 是基础设施构建工具。它在操作员工作站上运行,并调用 AWS API 来创建或移除资源。该项目将不安全的测试夹具与受控的 `terraform/deploy/` 预发环境目录分开,以防止意外应用故意设置的存在漏洞的示例。 安全的 AWS 基准包括: - 通过 `random_id` 实现全球唯一的 S3 存储桶命名 - S3 公共访问屏蔽 - S3 版本控制 - AES-256 服务端加密 - 仅限管理员 `/32` CIDR 访问的 SSH - 演示安全组中仅允许出站的 HTTPS 访问 - 限于单个存储桶的 `s3:GetObject` 和 `s3:ListBucket` 的 IAM 策略 - 项目和环境所有权标签 ### Prowler Prowler 执行实时的云安全状态管理扫描。记录的运行执行了 610 项 AWS 检查。汇总后的项目报告包含来自三个扫描源的 367 个发现,分类为 4 个严重、98 个高危、144 个中危和 121 个低危。 Prowler 会扫描整个 AWS 账户,而不仅仅是 AegisPipeline 创建的资源。因此,其扫描结果代表了账户范围的状态、现有服务以及实验室资源的综合情况。 ### `scripts/aggregate.py` 聚合脚本会读取可用的 Checkov、Trivy、Gitleaks 和 Prowler 输出。它将不同的 JSON 结构转换为一个标准化的发现模型,包含来源、严重性、资源、标题、详情、修复指南以及轻量级的合规性标签。 它会生成以下文件: - `reports/summary.json`,机器可读输出 - `reports/SUMMARY.md`,GitHub 可读输出 ### `scripts/ai_triage.py` 分诊层支持 Grok,但 Grok 是可选的。 - 如果设置了 `XAI_API_KEY`,最多会将 40 个标准化的发现发送到 xAI 的 chat-completions API,进行爆炸半径排序并起草修复方案。 - 如果没有提供密钥,或 API 调用失败,该脚本将使用确定性的本地启发式算法,根据严重性、公开暴露、机密、宽泛的 IAM 权限、加密缺失、实时的 Prowler 扫描结果以及 Gitleaks 扫描结果来确定优先级。 提交的实验室报告是在 `local-heuristic` 模式下生成的。复现该项目不需要 xAI 密钥,并且永远不应将任何 API 密钥提交到代码库中。 ### Docker `docker/app.py` 是一个最小化的 FastAPI 服务,包含一个健康检查端点和一个发现结果排序端点。加固的 Dockerfile 使用最新的精简版 Python 基础镜像、固定版本的依赖项,并以非 root 身份执行。GitHub Actions 会构建镜像并由 Trivy 进行扫描。 故意设置的不安全的 Dockerfile 仅作为扫描测试夹具存在。它使用过时的基础镜像,且缺乏非 root 加固。 ### Kubernetes 与 GrokGuard K3s 集群运行在 AWS EC2 上。Kyverno 会评估传入的 Pod 以及由 Deployment 生成的 Pod 模板。 这三个 ClusterPolicies 分别是: | 策略 | 目的 | |---|---| | `gg-block-hostpath` | 防止工作负载挂载节点文件系统或模型检查点路径 | | `gg-pod-hardening` | 阻断特权执行,并要求容器必须以非 root 身份运行 | | `gg-supply-chain-and-limits` | 拦截 `:latest` 镜像,并要求设置 CPU 和内存限制 | 这是预防性控制,而不仅仅是检测。被拒绝的工作负载永远不会进入运行状态。 ### 监控 `monitoring/security_exporter.py` 会读取 `reports/summary.json` 并公开暴露: - `grokguard_findings_total{severity}` - `grokguard_findings_by_source{source}` - `grokguard_last_scan_timestamp` Prometheus 可以在 `9105` 端口抓取该 exporter 的数据,Grafana 可以将发现结果与运营指标一起进行可视化。此监控堆栈是一个可选扩展,并不是证明核心 AWS 和 Kubernetes 控制措施所必需的。 ## GitHub Actions 行为 主工作流会在针对 `main` 分支的推送和拉取请求上运行。 阻断性控制: - 如果 Checkov 发现未获接受的高危或严重 Terraform 问题,则运行失败。 - 如果在 Git 历史记录中检测到凭证或机密信息,Gitleaks 会运行失败。 可见性控制: - Trivy Terraform 扫描会生成 JSON 构建产物。 - Trivy Docker 镜像扫描会生成 JSON 构建产物。 - Kubernetes Checkov 和 Trivy 工作流会针对加固的工作负载进行报告,而 Kyverno 仍然是权威的运行时执行点。 Checkov 门禁明确记录了六个已获接受的仅限实验室的例外情况: - `CKV2_AWS_5`,演示安全组未附加到 EC2 训练节点 - `CKV2_AWS_62`,S3 事件通知不在实验室范围内 - `CKV2_AWS_61`,S3 生命周期自动化不在实验室范围内 - `CKV_AWS_18`,S3 访问日志需要单独的日志目标 - `CKV_AWS_144`,跨区域复制需要额外的区域基础设施 - `CKV_AWS_145`,实验室使用 S3 管理的 AES-256 加密,而不是客户管理的 KMS 密钥 这些例外是明确且可审查的。它们并不是为了掩盖实验室已达到生产可用标准的隐藏声明。 ## 实验室实时证据 使用以下文件验证已完成的运行记录: - [`reports/SUMMARY.md`](reports/SUMMARY.md),汇总的发现结果 - [`reports/AI_REPORT.md`](reports/AI_REPORT.md),按风险优先级排序的分诊输出 - [`reports/k8s/insecure-workload-blocked.txt`](reports/k8s/insecure-workload-blocked.txt),Kyverno 拒绝证据 - [`reports/k8s/model-serving.txt`](reports/k8s/model-serving.txt),加固的部署和运行中的 Pod - [`reports/k8s/clusterpolicies.txt`](reports/k8s/clusterpolicies.txt),GrokGuard 策略已就绪 - [`reports/k8s/kyverno-pods.txt`](reports/k8s/kyverno-pods.txt),Kyverno 控制器正在运行 - [`reports/k8s/nodes.txt`](reports/k8s/nodes.txt),实时 K3s 节点证据 - [`reports/k8s/events.txt`](reports/k8s/events.txt),命名空间事件历史记录 ## 演示路径 简短的面试演示应遵循以下顺序: 1. 打开 `reports/k8s/insecure-workload-blocked.txt`,说明为何拒绝了不安全的部署。 2. 打开 `reports/k8s/model-serving.txt`,展示处于 `1/1 Running` 状态的加固工作负载。 3. 打开 `reports/k8s/clusterpolicies.txt`,展示所有 GrokGuard 策略已准备就绪。 4. 打开 `reports/SUMMARY.md`,解释如何将多种扫描器格式进行标准化。 5. 打开 `reports/AI_REPORT.md`,解释风险优先级排序层。 6. 可选展示 `.github/workflows/security.yml`,解释自动化的部署前检查。 ## 快速开始 完整的设置、部署、验证和销毁流程详见 [`docs/SETUP.md`](docs/SETUP.md)。 基本的本地对比: ``` cp terraform/aws/insecure/main.tf terraform/deploy/main.tf checkov -d terraform/deploy --framework terraform --external-checks-dir policies --compact cp terraform/aws/secure/main.tf terraform/deploy/main.tf checkov -d terraform/deploy --framework terraform --external-checks-dir policies --compact ``` 请勿应用不安全的测试夹具。仅应用受控的加固预发配置。 ## 安全设计决策 - 采用两款 IaC 扫描工具可提供更广泛的可见性,因为扫描引擎的覆盖范围和规则实现各不相同。 - Gitleaks 会检查完整的 Git 历史记录,因为从当前文件中删除机密信息并不能使之前已提交到代码库的凭证失效。 - Terraform 计划、状态、kubeconfig 文件、私钥、环境变量文件和 VPN 配置文件已被排除在 Git 之外。 - 保留 Terraform 依赖锁定文件以确保 provider 的可复现性。 - Grok 集成具有离线后备方案,因此报告生成不依赖于外部 API。 - 运行时准入执行保护可防止手动更改 `kubectl`、被破坏的自动化流程以及绕过 CI 的紧急更改。 - 该项目会存储证据,因此无需重建实验室即可审查控制措施的有效性。 ## 商业价值 APipeline 展示了基础设施安全性如何支持工程开发速度,而不是成为最终的手动瓶颈。 该控制模型可以减少: - 对常见配置失误的反复手动审查 - 在资源已部署后进行的后期返工 - 由公开存储或宽泛的 IAM 权限引起的暴露风险 - 通过源代码控制导致的凭证泄露 - 由特权或主机挂载的工作负载引发的 Kubernetes 节点风险 - 由没有 CPU 或内存限制的工作负载引发的可靠性和成本风险 - 通过保留可重复的证据来减少审计工作量 我们不主张任何固定的财务节省,因为该实验室并未对生产环境进行测量。其价值来自于更早的反馈、可重复的执行、降低的事故发生概率以及更高效地利用安全工程时间。 ## 已知限制 这是一个专注于实验室和作品集的构建,而不是生产级平台。 目前的限制包括: - 实验室使用了长期的 IAM 用户凭证,而不是联合身份验证。 - Terraform 状态保存在本地,而不是存储在带有锁定机制的远程加密后端中。 - K3s 是一个单节点集群,而不是高可用的托管型 Kubernetes。 - EC2 控制平面只能从一个受限的管理员 CIDR 通过互联网访问,而不是位于受控访问路径之后的私有网络中。 - Prowler 的聚合功能可以通过更强大的去重和更丰富的状态解析来改进。 - Docker API 是一个演示服务,而不是生产级的分诊平台。 - 在建立稳定的漏洞基准和异常处理流程之前,Trivy 的发现结果在作品集工作流中仅作为报告存在。 - 监控文件夹提供了 Prometheus 和 Grafana 的组件,但尚未包含提交的看板。 - Azure 的测试夹具已实现,但在记录的运行期间并未部署。 ## 生产路线图 生产环境的实现将会增加: - GitHub OIDC 或员工身份联合验证,并使用短期的云凭证 - 最小权限的部署和扫描角色 - 带有锁定和受控访问权限的远程加密 Terraform 状态 - EKS、AKS 或其他具有私有端点的托管型 Kubernetes 服务 - 集中式的 CloudTrail、VPC Flow Logs、GuardDuty、Security Hub 和 SIEM 集成 - 使用 Cosign 进行镜像签名和验证 - 注册表允许列表和镜像摘要强制执行 - 软件物料清单 (SBOM) 生成和来源控制 - Kubernetes NetworkPolicies 和命名空间安全控制 - Falco 或同等的运行时检测层 - Security Hub、Jira、Slack 或事件管理工具的集成 - 改进的 Prowler 标准化、去重、资产所有权和修复跟踪 - 用于安全指标的时间序列 Grafana 看板和警报 ## 安全清理 AWS 资源在销毁之前会持续产生费用。演示结束后,请销毁两个 Terraform 堆栈,并停用或删除实验室访问密钥。具体的命令包含在 `docs/SETUP.md` 中。 ## 免责声明 不安全的 Terraform、Docker 和 Kubernetes 示例均为故意的测试夹具。请勿将其部署到真实环境中。
标签:DevSecOps, 上游代理, 子域名突变, 安全合规, 漏洞利用检测, 网络代理, 自定义请求头, 请求拦截, 逆向工具