lAnviuml/devsecops-gitops-platform

GitHub: lAnviuml/devsecops-gitops-platform

一个可复现的 Kubernetes DevSecOps GitOps 参考平台,将 OpenTofu 基础设施、Argo CD 持续交付、容器签名与 SBOM 等供应链安全控制整合到端到端可验证的流水线中。

Stars: 0 | Forks: 0

# DevSecOps GitOps 平台 [![CI](https://static.pigsec.cn/wp-content/uploads/repos/cas/ad/ad5834178f7599af9fdda11629d49cae07f2997beec49821b2920eff5bfd50e7.svg)](https://github.com/lAnviuml/devsecops-gitops-platform/actions/workflows/ci.yml) [![本地 GitOps 端到端](https://static.pigsec.cn/wp-content/uploads/repos/cas/46/46eec097e26268cd8bae8a1460c4191c3f5dd55b6e833fa6d1d20888a4dc7acb.svg)](https://github.com/lAnviuml/devsecops-gitops-platform/actions/workflows/e2e-local.yml) [![许可证](https://img.shields.io/badge/license-Apache--2.0-blue.svg)](LICENSE) 一个可复现的 Kubernetes GitOps 参考平台,使用 OpenTofu、Argo CD、GitHub Actions、签名容器镜像、SBOM、策略执行和可观测性构建。 强制性的验收路径是本地且免费的:一个干净的克隆可以创建一个三节点的 `kind` 集群,引导 Argo CD,调和平台,并验证工作负载、策略、指标和自愈行为。AWS EKS 是可选的扩展,绝不是验证项目所必需的。 ## 快速开始 前置条件: - Docker,至少有 10 GiB 可用空间; - Git、`kubectl`、Helm 4.2.3、kind 0.32.0、OpenTofu 1.12.5 和 Task; - 端口 `8080`、`8443`、`3000` 和 `9090` 可用(当执行其相关任务时)。 ``` git clone https://github.com/lAnviuml/devsecops-gitops-platform.git cd devsecops-gitops-platform task tools:check task local:up task local:verify ``` 随后 API 可通过 访问。验证任务会检查每个 endpoint、所有 Argo 应用程序、Kyverno 拒绝情况、Prometheus target、Pod 替换以及 Argo 自愈。 仅删除此项目的集群: ``` task local:down ``` ## 交付架构 ``` flowchart LR Dev["Pull request"] --> CI["Tests, lint, IaC, secrets, policy"] CI --> Main["Protected main"] Main --> Build["One amd64/arm64 BuildKit build"] Build --> GHCR["Immutable GHCR digest"] GHCR --> Scan["Trivy vulnerability gate"] Scan --> Evidence["Syft SBOM, Cosign signature, GitHub provenance"] Evidence --> Verify["Signature, SBOM, provenance verification"] Verify --> GitOps["Generated gitops branch"] GitOps --> Argo["Argo CD multi-source reconciliation"] Main --> Argo Argo --> Policy["Kyverno admission"] Policy --> K8s["kind or optional EKS"] K8s --> Observe["Prometheus, Grafana, alert rules"] ``` CI 身份无法部署到 Kubernetes。它只能发布已验证的制品,并更新生成的 `gitops` 分支中的环境摘要。Argo CD 将来自 `main` 的 chart 与该摘要结合,因此部署历史仍然是正常的 Git 历史。 ## 部署内容 Argo CD 使用 app-of-apps 层次结构和两个项目: - `platform` 拥有 ingress-nginx、Kyverno、metrics-server、kube-prometheus-stack 和集群策略; - `workloads` 被限制在 `demo` namespace 和应用程序仓库中。 FastAPI 工作负载公开: | Endpoint | 契约 | |---|---| | `GET /` | 仅公开名称、版本和 Git commit | | `GET /health/live` | 进程存活性 | | `GET /health/ready` | 流量就绪状态 | | `GET /metrics` | 有限基数 Prometheus 指标 | 该镜像以 UID/GID `10001` 运行,没有添加额外的包管理器,支持只读根文件系统,并且在部署时删除了所有 Linux capabilities。Kubernetes 增加了两个副本、探针、requests 和 limits、PDB、拓扑分布、Pod Security `restricted` 以及默认拒绝的网络策略。 ## 安全与供应链 在 GitOps 状态更改之前,每次发布都必须通过以下顺序: 1. Ruff、mypy、pytest,以及至少 90% 的覆盖率; 2. 通过不可变摘要进行镜像构建和推送; 3. 根据 Trivy 扫描,不存在可修复的高危或严重漏洞; 4. 使用 Syft 生成 SPDX JSON SBOM; 5. 来自确切 `release.yml` workflow 身份的免密 Cosign 签名; 6. 附加到 OCI 摘要的 GitHub SLSA 溯源信息; 7. 独立的签名、SBOM 证明和溯源验证; 8. 将摘要提交到 `gitops`。 Kyverno 会独立拒绝没有所需 runtime 控制的可变镜像和工作负载。应用程序镜像还必须携带预期的免密签名和 SLSA 溯源信息。有关信任边界、滥用案例和残余风险,请参阅[威胁模型](docs/threat-model.md)。 从受信任的 shell 验证已发布的摘要: ``` export GITHUB_REPOSITORY=lAnviuml/devsecops-gitops-platform bash scripts/verify-artifact.sh \ ghcr.io/lanviuml/devsecops-gitops-platform@sha256:REPLACE_WITH_64_HEX_CHARACTERS ``` ## 运维 | 任务 | 效果 | |---|---| | `task local:up` | 创建或仅复用 `devsecops-gitops`,安装 Argo CD,并应用根应用 | | `task local:verify` | 运行完整的本地验收套件 | | `task local:status` | 显示节点、Argo 应用程序、工作负载和 endpoint | | `task local:logs` | 跟踪工作负载日志 | | `task local:port-forward:argocd` | 通过 `https://localhost:8443` 暴露 Argo CD | | `task local:port-forward:grafana` | 通过 `http://localhost:3000` 暴露 Grafana | | `task local:port-forward:prometheus` | 通过 `http://localhost:9090` 暴露 Prometheus | | `task local:down` | 仅删除指定名称的 kind 集群 | 运维程序位于 [docs/runbooks](docs/runbooks/bootstrap.md) 中。[五分钟演示](docs/demo.md) 提供了简洁的项目组合演示。 ## 回滚 回滚是一次经过验证的 GitOps 更改,而不是 `argocd rollback`: 1. 在 `Roll back GitOps digest` workflow 中选择之前发布的摘要; 2. 该 workflow 会重新验证签名、SBOM 和溯源信息; 3. 它将之前的摘要提交到 `gitops`; 4. Argo CD 调和所需状态,并在 Git 历史中记录回滚。 这避免了与自动化同步发生冲突,并保留了可审计的恢复路径。请参阅[回滚 runbook](docs/runbooks/rollback.md)。 ## 可选的 AWS EKS 扩展 `infra/aws/bootstrap` 会创建一个保留的、带版本控制的、加密的 S3 状态桶,并为 plan 和 apply 创建独立的 GitHub OIDC 角色。`infra/aws/eks` 会创建一个双可用区 VPC、私有节点、一个演示用的 NAT Gateway、EKS 1.36、所需的附加组件,以及一个最小/最大节点数为 1/3 的双节点 `t3.medium` 托管节点组。 私有 API endpoint 已启用。公共 API 访问需要非空的 `admin_cidrs` 允许列表。默认情况下不会创建公共 AWS ingress,并且 GitHub 中不包含长期有效的 AWS 密钥。AWS 资源会产生费用;在执行 apply 之前,请查看计划和 [AWS 销毁 runbook](docs/runbooks/aws-destroy.md)。 ## 仓库结构图 ``` app/ FastAPI source, lock file, and tests platform/charts/ Application Helm chart platform/argocd/ Common and environment app-of-apps definitions platform/policies/ Kyverno policies and policy tests platform/environments/ Human values on main; generated digests on gitops platform/kind/ Pinned local cluster configuration infra/aws/bootstrap/ Retained state and GitHub OIDC bootstrap infra/aws/eks/ Optional VPC and EKS root module .github/workflows/ CI, release, E2E, promotion, rollback, and AWS workflows docs/ ADRs, runbooks, threat model, evidence, and demo scripts/ Cross-platform operational and verification scripts ``` ## 证据与局限性 [能力证据矩阵](docs/evidence.md) 将每一项项目组合声明映射到仓库制品或可复现的检查。仅当截图由真实的成功运行产生时才被接受;该仓库绝不包含伪造的终端输出或模拟仪表板。 版本 1 有意排除了公共域名和 TLS、数据库、External Secrets、Loki、service mesh 以及高可用的多 NAT AWS 拓扑。这些是有用的扩展,但并非证明交付和范围内的安全控制所必需的。 ## 贡献与许可证 在提交 pull request 之前,请阅读 [CONTRIBUTING.md](CONTRIBUTING.md),并通过 [SECURITY.md](SECURITY.md) 报告漏洞。基于 [Apache-2.0](LICENSE) 获得许可。
标签:API集成, DevSecOps, GitOps, LLM防护, PyVis, 上游代理, 可观测性, 子域名突变, 自定义请求头, 请求拦截, 逆向工具