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代理, 可观测性, 子域名突变, 搜索引擎查询, 测试用例, 漏洞利用检测, 用户代理, 自定义请求头, 请求拦截