Rahulkumar240/nexus-platform

GitHub: Rahulkumar240/nexus-platform

一个集成微服务架构、安全 CI/CD 流水线与云原生基础设施的 DevSecOps 平台,展示代码如何安全、可靠地交付到生产环境。

Stars: 0 | Forks: 0

# Nexus 平台 **云原生 DevSecOps 与后端平台 —— 安全的 CI/CD、Kubernetes 编排、微服务架构以及生产级基础设施。** 其构建旨在展示现代系统在整个软件交付生命周期中如何被保护、部署和监控——而不仅仅是它们如何编写代码。 ## 本项目存在的原因 大多数作品集项目只是展示了某人会写代码。而这个项目的建立是为了展示更难的事情:我理解代码如何安全、可靠且大规模地进入生产环境。 “我写了一个能运行的应用”与“我知道如何在真实的组织中将它安全发布”之间的差距,正是这个平台旨在填补的。 ## 系统架构 ``` Client Requests │ ▼ ┌─────────────┐ │ API Gateway │ ← Authentication, rate limiting, routing └──────┬──────┘ │ ┌────┴────┐ │ │ ▼ ▼ Service A Service B (independent microservices) │ │ └────┬────┘ │ ┌────▼─────┐ ┌──────────────┐ │ PostgreSQL│ │ Redis Cache │ └──────────┘ └──────────────┘ │ ┌────▼──────────┐ │ Kubernetes │ ← Orchestration, scaling, RBAC └───────────────┘ │ ┌────▼──────────┐ │ AWS (Terraform)│ ← Infrastructure as Code └───────────────┘ ``` **为什么选择微服务而不是单体架构?** 每个服务都可以被独立扫描、部署和回滚。在安全场景下这很重要——一个服务中的漏洞不需要重新部署所有内容,并且爆炸半径得到了控制。 ## 技术栈 ### 后端 | 层级 | 技术 | 原因 | |---|---|---| | 运行时 | Node.js | 快速原型设计,拥有强大的 REST 和 middleware 生态系统 | | API 设计 | REST / Express | 直接明了,适合演示输入验证和 auth 流程 | | 数据库 | PostgreSQL | 为 auth 和用户数据提供关系完整性 | | 缓存 | Redis | 用于 session 管理和速率限制计数器 | ### DevSecOps | 工具 | 用途 | |---|---| | Docker | 容器镜像构建与加固 | | Kubernetes | 编排、水平扩展、pod 安全策略 | | GitHub Actions | CI/CD pipeline 自动化 | | Terraform | AWS 基础设施以代码形式配置 —— 可复现、版本控制 | ### 安全流水线 | 工具 | 阶段 | 为什么在此阶段 | |---|---|---| | SAST 扫描器 | Pull request | 在合并前捕获不安全的代码模式 —— 修复成本最低的阶段 | | Trivy | 构建后 | 在任何部署之前扫描容器镜像中的已知 CVE | | DAST | Staging 环境 | 需要运行中的应用程序进行探测 —— 针对 staging 运行,绝不针对生产环境 | | Secrets 扫描器 | Pre-commit + CI | 完全阻止凭证进入代码库 | ### 可观测性 | 工具 | 作用 | |---|---| | Prometheus | 指标收集 —— CPU、内存、请求延迟、错误率 | | Grafana | 仪表板和告警阈值 | | 集中式日志记录 | 聚合所有服务的日志以进行事件调查 | ## 安全设计决策 ### 为什么在 PR 阶段进行 SAST,而不仅仅是在部署前? 在代码审查阶段修复安全问题的成本只是部署后修复的一小部分。在每个 pull request 上运行 SAST 意味着不安全的模式永远不会进入主分支。 ### 为什么选择 Trivy 进行容器扫描而不是手动审查? 容器镜像会引入数百个传递依赖。Trivy 可以在整个镜像层堆栈中自动化 CVE 检测 —— 这是任何手动审查都无法快速做到的。 ### 为什么在 staging 而不是生产环境中进行 DAST? DAST 会主动探测运行中的应用程序以查找漏洞。在生产环境中运行它可能会对真实用户造成影响并触发警报。Staging 提供了一个没有风险的真实测试目标。 ### 为什么使用 Kubernetes secrets 结合 secrets 管理器而不是环境变量? 环境变量会泄露到日志、崩溃报告和进程列表中。Secrets 管理器提供轮换、审计跟踪和最小权限访问。环境变量不具备这些功能。 ### 为什么在 Kubernetes 层面使用 RBAC? RBAC 限制了每个 pod、服务账户和用户在集群内可以执行的操作。如果没有它,一个被攻破的容器就可以访问整个集群内的 secrets 和资源。 ## CI/CD 流水线 ``` Code push / PR opened │ ▼ SAST scan + secrets scan │ ▼ (pass) Automated tests │ ▼ (pass) Docker image build │ ▼ Trivy container scan │ ▼ (pass) Deploy to staging │ ▼ DAST scan on staging │ ▼ (pass) Approval gate → deploy to production │ ▼ Rollback triggered automatically on failure ``` **为什么在生产前设置审批门控?** 自动化检查能捕获已知问题。审批门控可确保由人工审查部署意图,特别是对于基础设施变更,因为自动化可能会以工具无法捕获的方式出现错误。 ## 做出的权衡 | 决策 | 收益 | 代价 | |---|---|---| | 选择 Kubernetes 而不是 Serverless | 完全控制 pod 安全、网络策略、RBAC | 带来更多需要管理的运维复杂性 | | 在 PR 阶段进行 SAST | 更早检测,更低的修复成本 | 略微减慢 PR 审查周期 | | 选择 Terraform IaC 而不是控制台手动配置 | 可复现、可审计的基础设施 | 初始设置时间较高 | | 选择微服务而不是单体架构 | 独立部署与爆炸半径控制 | 带来更多跨服务复杂性 | | 选择 PostgreSQL 而不是 NoSQL | 为 auth/用户数据提供强一致性 | 对非结构化数据的灵活性较低 | ## 已实现的功能 - [x] 带有身份验证和速率限制的 API 网关 - [x] 支持独立部署的微服务架构 - [x] 带有镜像加固的 Docker 容器化 - [x] 带有 RBAC 和 pod 安全的 Kubernetes 编排 - [x] 用于 AWS 基础设施配置的 Terraform IaC - [x] 使用 GitHub Actions 的 CI/CD pipeline - [x] 在 pull request 阶段集成 SAST - [x] Trivy 容器镜像扫描 - [x] Secrets 管理系统 - [x] 针对 staging 环境的 DAST 扫描 - [x] Prometheus 指标收集 - [x] Grafana 仪表板 - [ ] OpenTelemetry 分布式追踪 —— 进行中 - [ ] 用于 pod 间流量控制的 Kubernetes 网络策略 - [ ] 供应链安全(SBOM 生成,Sigstore 签名) ## 接下来计划添加的内容及原因 **Kubernetes 网络策略** 目前 RBAC 控制了谁可以做什么,但集群内的 pod 间流量是不受限制的。网络策略将强制要求 Service A 只能与数据库通信,而不能与 Service B 通信 —— 这是在网络层面的最小权限原则。 **SBOM 生成** 软件物料清单提供了构建中每个依赖项的完整清单。随着供应链攻击的增加,确切了解容器镜像中的内容与扫描它一样重要。 **OpenTelemetry 追踪** Prometheus 告诉您请求变慢了。分布式追踪告诉您是链路中的哪个服务导致了延迟。对于微服务系统而言,这就是猜测与知晓之间的区别。 ## 本地设置 ``` git clone https://github.com/Rahulkumar240/nexus-platform cd nexus-platform docker-compose up --build ``` Kubernetes 部署: ``` kubectl apply -f k8s/ ``` Terraform 配置: ``` cd terraform/ terraform init terraform plan terraform apply ``` ## 作者 **Rahul Kumar** — DevSecOps 工程师(培训中),BTech CSE @ IKGPTU [LinkedIn](https://linkedin.com/in/rahulkumar297) · [GitHub](https://github.com/Rahulkumar240) ## 许可证 MIT License
标签:API集成, MITM代理, 可观测性, 子域名突变, 搜索引擎查询, 测试用例, 漏洞利用检测, 用户代理, 自定义请求头, 请求拦截