YogeshT22/end-to-end-ci-cd-jenkins-docker

GitHub: YogeshT22/end-to-end-ci-cd-jenkins-docker

基于Docker Compose编排的本地DevSecOps平台,通过Jenkins流水线集成Trivy漏洞扫描、Cosign镜像签名和K3s编排,模拟生产级安全软件交付全流程。

Stars: 1 | Forks: 0

# 项目:生产级 DevSecOps 平台 + K6 负载测试 ![平台](https://img.shields.io/badge/Platform-Kubernetes-blue) ![CI/CD](https://img.shields.io/badge/CI/CD-Jenkins-red) ![安全](https://img.shields.io/badge/Security-Cosign-green) ![监控](https://img.shields.io/badge/Monitoring-Prometheus-orange) ![自动化](https://img.shields.io/badge/Automation-Bash-yellow) ![logo](https://static.pigsec.cn/wp-content/uploads/repos/2026/05/1adf502902175413.png) ## 关于本仓库 本仓库包含了一个完整的本地 DevOps 生态系统的基础设施即代码,模拟了现代、安全的软件交付生命周期。使用 Docker Compose,它编排了一系列业界最佳的开源工具,以自动构建、测试、保护和部署容器化应用程序到多节点 Kubernetes 集群。 该平台被设计为一个实践学习环境,旨在掌握包括原生 TLS、容器安全、流水线即代码和 Kubernetes 自动化在内的高级概念。 **配套应用程序仓库:** [https://github.com/YogeshT22/sample-flask-app](https://github.com/YogeshT22/sample-flask-app) # 项目概述 该平台展示了真实的 DevOps 工程实践,包括: - 基础设施自动化 - Kubernetes 集群生命周期管理 - 安全的软件供应链 (Trivy, SBOM, Cosign) - 私有 TLS 容器仓库 - 使用 Jenkins 的 CI/CD 流水线自动化 - 使用 Prometheus 和 Grafana 的监控与可观察性 - 幂等的引导架构 - 集成到流水线中的 K6 负载测试 ## 生产级供应链与 CI/CD 流程 本项目实现了“安全第一”的零信任流水线。每一次代码提交都会经过以下自动化阶段: 1. **源码与触发:** 开发者推送到 Gitea → Webhook 触发 Jenkins。 2. **构建前安全检查:** Jenkins 扫描源代码,检查是否意外提交了敏感信息 (`Trivy`)。 3. **构建与打包:** Jenkins 构建 Docker 容器。 4. **构建后安全检查:** Jenkins 扫描构建好的镜像以查找漏洞,并生成 CycloneDX SBOM。 5. **加密信任:** 使用 `Cosign` 对镜像进行签名。 6. **安全制品存储:** 推送到私有本地 Docker 仓库,通过本地受信任的 TLS (`mkcert`) 进行身份验证。 7. **不可变部署:** Kubernetes 拉取已签名的镜像,并使用其不可变的 SHA256 摘要进行部署。 8. **集群内负载测试:** Jenkins 针对已部署的服务运行 k6 测试并归档结果。 ## 经验总结 主要收获包括: - **基础设施的不可变性:** 当本地集群被错误网络或安全配置“污染”时,删除并重新创建它比修补它更快、更可靠。 - **显式信任是强制性的:** 在私有、安全的环境中,不存在“自动”信任。每一个通信环节 (Jenkins -> 仓库 -> K8s) 都需要显式的证书注入和验证。 - **WSL 中的路径与引号:** 带有空格的 Windows 文件路径需要严格加引号,以防止 `k3s` 等工具找不到卷。 - **迭代开发:** 构建这样一个复杂的平台需要迭代开发,并在将每个组件集成到完整流水线之前对其进行单独测试。 ### 重要提示 (WSL 用户) - 为了获得最佳的可靠性,请在 WSL 文件系统内克隆并运行该项目: **正确做法**: ``` ~/projects/devsecops-platform ``` ### **避免做法**: ``` /mnt/c/Users/.../Downloads/devsecops-platform ``` - 这可以避免由 Windows 挂载引起的文件系统权限问题。 - 如果您必须从 Windows 路径运行,请确保脚本中的所有路径都正确使用了引号,以处理空格和特殊字符。 ## 目录 - [项目概述](#project-overview) - [生产级供应链与 CI/CD 流程](#-production-grade-supply-chain--cicd-flow) - [经验总结](#lessons-learned) - [核心概念](#core-concepts--skills-demonstrated) - [架构图](#architecture-diagram) - [端到端信任架构](#end-to-end-trust-architecture) - [快速开始 (如何运行平台)](#-quick-start-how-to-run-platform) ## 核心概念与展示技能 - **DevSecOps 流水线设计:** 实施了一个采用“安全第一”方法的完整多阶段流水线: - `Git Push -> Webhook -> 密钥扫描 -> 构建 -> 镜像扫描 -> SBOM 生成 -> 镜像签名与验证 -> 部署` - **基础设施自动化:** - **Docker Compose:** 用于编排核心 CI/CD 工具链。 - **安全基础设施:** - **原生 TLS 仓库:** 部署了一个使用由 `mkcert` 生成的本地受信任证书通过 HTTPS 保护的私有 Docker 仓库。 - **端到端信任:** 设计了一个“信任圈”,其中所有组件 (Docker 守护进程、Jenkins、K3s 节点) 都被配置为信任自定义根 CA,从而无需使用不安全的标志。 - **容器编排:** 使用 `Deployments`、`Services` 和 `Ingress` 在 **Kubernetes (K3s)** 集群上部署和管理应用程序。 - **软件供应链安全:** - **漏洞扫描:** 集成了 **Trivy**,用于文件系统 (构建前) 和容器镜像 (构建后) 扫描。 - **SBOM 生成:** 为每次构建创建 CycloneDX 软件物料清单。 - **镜像完整性:** 使用 **Cosign** 对容器镜像进行加密签名和验证,确保它们在构建和部署之间不会被篡改。 - **可观察性与监控:** 使用 **Helm** chart 部署 **Prometheus** 和 **Grafana**,以收集和可视化实时指标。 - **集群内负载测试:** 将 **k6** 负载测试集成到流水线中,在 Kubernetes 内部运行测试,以在现实条件下验证已部署的服务。 ## 架构图 ![架构图](https://static.pigsec.cn/wp-content/uploads/repos/2026/05/b62a3eb55d175414.png) ## 端到端信任架构 本平台在整个软件供应链中实现了完整的加密信任链: 1. **证书颁发机构 (CA)** - 使用 `mkcert` 生成自定义根 CA。 - 此 CA 为私有 Docker 仓库的 TLS 证书进行签名。 2. **受信任的组件** 根 CA 被显式注入到以下组件中: - Docker 守护进程 - Jenkins 容器 - Kubernetes (k3s) 节点 3. **仓库信任** 这允许所有组件安全地与私有仓库通信,而无需使用不安全的标志。 4. **镜像完整性** - 镜像使用 Cosign 私钥进行签名。 - 公钥 (cosign.pub) 存储在仓库中。 - Jenkins 在部署前验证镜像签名。 5. **不可变部署** Kubernetes 使用不可变的 SHA256 摘要而不是可变标签来部署镜像。 这确保了: - 镜像真实性 - 仓库真实性 - 部署完整性 - 端到端的供应链安全 ## 组件职责 | 组件 | 职责 | | ---------------- | ---------------------------------------------- | | Gitea | 源代码管理和 webhook 触发 | | Jenkins | CI/CD 编排、构建、扫描、签名、部署 | | Docker Registry | 使用 TLS 的安全镜像存储 | | Trivy | 密钥扫描和漏洞扫描 | | Cosign | 镜像签名和验证 | | Kubernetes (k3s) | 容器编排 | | Prometheus | 指标收集 | | Grafana | 指标可视化 | | mkcert | 本地证书颁发机构 | | k6 | 集群内负载测试 | ## 网络架构 所有服务都在隔离的 Docker 桥接网络中运行: big-project-2-cicd-pipeline_cicd-net _如有需要,可以在 `docker-compose.yml` 中更改名称。_ 这允许使用容器 DNS 名称进行安全的内部通信: - gitea-server:3000 - jenkins-server:8080 - local-docker-registry:5000 Kubernetes 节点通过 k3s 加入同一网络,允许直接进行安全的镜像拉取。 不需要暴露外部的不安全仓库。 ## 私有仓库安全 私有 Docker 仓库通过以下方式确保安全: - TLS 加密 - 自定义根 CA 信任 - 内部 Docker 网络隔离 在部署期间,绝不会从不安全的公共仓库拉取镜像。 这模拟了企业私有仓库环境,例如: - AWS ECR - Azure ACR - Google Artifact Registry - Harbor ## 不可变部署策略 该平台不使用可变标签 (latest, v1 等) 进行部署,而是使用不可变的 SHA256 镜像摘要进行部署: 示例: local-docker-registry:5000/sample-flask-app@sha256:abcd1234... 这可以防止: - 镜像篡改 - 标签覆盖攻击 - 不一致的部署 ## 🛠️ 快速开始 (如何运行平台) ### 1. 配置基础设施 整个平台使用幂等自动化脚本进行配置。 ``` git clone https://github.com/YogeshT22/big-project-2-cicd-pipeline.git cd big-project-2-cicd-pipeline # 将启动 Docker, K8s, 生成 TLS certs, 并配置 Jenkins/Kubeconfig ./bootstrap.sh ``` ### 2. 生成 Cosign 密钥 (镜像签名) 此流水线使用 **Cosign** 对容器镜像进行加密签名。在运行流水线之前,您需要生成一个密钥对: ``` # 如果你尚未安装, 请安装 cosign # 生成新的 key pair (按 Enter 将 password 留空以便自动化) cosign generate-key-pair ``` 这将生成两个文件: 1. `cosign.pub`:公钥。将此文件移动到您的应用程序代码库 (`sample-flask-app/cosign.pub`) 中。 2. `cosign.key`:私钥。**不要提交此文件。** 将此文件作为 **Secret File** 上传到您的 Jenkins 凭据存储中,其 ID 必须完全匹配:`cosign-private-key`。 ### 3. 最终 Web UI 配置 (一次性设置) 由于 Gitea 和 Jenkins 在 Docker 内部本地运行,您必须一次性配置它们最初的 UI 连接: 1. **Gitea:** 前往 `http://localhost:8081`,使用标准的 SQLite 完成安装。创建一个用户并创建一个名为 `sample-flask-app` 的空仓库。 2. **Jenkins:** 前往 `http://localhost:8080` (通过 `docker logs jenkins-server` 获取初始密码)。 - 安装 **Docker Pipeline** 插件。 - 前往 Manage Jenkins -> Credentials 并添加三个 **Secret File** 凭据: - ID:`kubeconfig-sa` (上传引导脚本生成的 `kubeconfig-jenkins.yaml`)。 - ID:`cosign-private-key` (上传您在上面生成的 `cosign.key`)。 - ID:`cosign-passoword` (如果在创建 cosign 密钥对时使用了密码)。 3. 创建一个新的 Jenkins Pipeline Job,将其指向您的 Gitea 仓库,并运行构建! ## 自动化脚本概述 该平台使用模块化、生产风格的基础设施自动化脚本,这些脚本位于 `scripts/` 目录中。 每个脚本都有单一职责,并且可以安全地重新运行 (幂等性)。 | 脚本 | 用途 | | -------------------------- | ---------------------------------------------------- | | 01-start-infrastructure.sh | 启动 Docker 服务 | | 02-wait-for-services.sh | 等待 Gitea、Jenkins 和 Registry 准备就绪 | | 03-create-cluster.sh | 创建或恢复 Kubernetes 集群 | | 04-configure-kubernetes.sh | 配置 Kubernetes 服务账号和 kubeconfig | | 05-deploy-monitoring.sh | 使用 Helm 部署 Prometheus 和 Grafana | | 06-verify-platform.sh | 验证完整的平台功能 | | stop-platform.sh | 安全停止平台基础设施 | | bootstrap.sh | 编排完整的平台配置过程 | | generate-certs.sh | 生成 CA 根证书和仓库证书。 | ## 自动化配置架构 平台遵循生产级引导模型: 1. 基础设施启动 2. 服务就绪验证 3. Kubernetes 集群配置 4. 信任和凭据配置 5. 监控部署 6. 平台验证 这确保了该平台: - 完全可重现 - 可以安全地重新运行 - 能够抵抗部分故障 - 适用于真实的 DevOps 工作流 有关如何配置基础设施的详细分步说明,请参见 [手动设置指南](docs/MANUAL_SETUP_GUIDE.md)。 ## 许可证 本项目基于 MIT 许可证授权 - 有关详细信息,请参见 [LICENSE](LICENSE) 文件。
标签:Bash, CISA项目, Cosign, DevOps 平台, DevSecOps, Docker Compose, EC2, Gitea, Grafana, IaC, Jenkins, JSONLines, K6, SBOM, StruQ, TLS, Webhook, Web截图, 上游代理, 人体姿态估计, 力导向图, 安全学习环境, 安全扫描, 安全软件供应链, 容器安全, 容器镜像仓库, 应用安全, 开发安全运维, 性能测试, 持续集成/持续部署, 数字取证, 时序注入, 流水线即代码, 版权保护, 监控与可观测性, 硬件无关, 自动化脚本, 自定义请求头, 请求拦截, 负载测试, 防御工具, 零信任