aadieng100/KubeSecure-GitOps

GitHub: aadieng100/KubeSecure-GitOps

一个企业级、安全加固的 Kubernetes GitOps 部署平台,结合 Terraform、ArgoCD 和 Helm,在 AWS EKS 上实现从本地到云端的安全声明式交付。

Stars: 0 | Forks: 0

# 🛡️ KubeSecure-GitOps 一个企业级、经过安全加固的 GitOps 部署流水线,基于 **Helm**、**ArgoCD** 和高度解耦的 **Terraform Infrastructure Pattern Library** 构建。它将在 **AWS EKS** 和 **Amazon RDS** 上部署一个连接到托管 PostgreSQL 数据库的安全 Spring Boot REST API。 该项目遵循严格的 **Local-First 开发策略** —— 每个工作负载首先在本地 Kubernetes Kind 集群中进行验证,然后通过顺畅的迁移路径,将其提升至具有生产环境代表性且严格隔离的云基础设施中。 ## 🗺️ 系统架构 ### 1. 基础设施拓扑 (AWS EKS & RDS) 云基础设施由模块化的 Terraform 进行配置,在三个独立的子网层级中实施了严格的微分段和深度防御: - **Public Tier** — 仅托管 AWS NAT Gateways。此处不运行任何应用程序或计算工作负载。 - **Private Tier** — 托管私有的 **AWS EKS 1.30** Managed Node Groups。工作节点通过私有 endpoint 访问 EKS 控制平面(`endpoint_private_access = true`)。 - **Isolated Tier** — 托管加密的 **Amazon RDS PostgreSQL 15** 实例。该层级**没有任何**通往互联网或 NAT Gateway 的路由 —— 从设计上杜绝了从外部世界对其进行访问。 ### 2. 网络与应用流程 ``` graph TD subgraph Internet User([External Traffic]) end subgraph AWS["AWS Cloud — VPC 10.0.0.0/16"] subgraph Public["Public Subnets"] NAT[AWS NAT Gateway] end subgraph Private["Private Subnets — EKS Cluster v1.30"] Argo[ArgoCD Engine] API[Spring Boot API Pods x2] end subgraph Isolated["Isolated Subnets"] RDS[(RDS PostgreSQL 15)] end end User -->|Secure Tunnel / Port-Forward| API Argo -->|Reconciliation Loop| GitHub[(GitHub Repository)] API -->|Egress allowed only on 5432 / 53| RDS API -->|Outbound updates| NAT style RDS fill:#f9f,stroke:#333,stroke-width:2px style API fill:#bbf,stroke:#333,stroke-width:2px style Argo fill:#bfb,stroke:#333,stroke-width:2px ``` ## 🔒 DevSecOps 与平台工程加固清单 ### 💻 容器级别(多阶段与 Distroless) - **多阶段构建** — 编译工具(Maven)在构建阶段被丢弃。最终的运行时镜像仅附带编译好的 `.jar`。 - **Distroless 基础镜像** — 运行在一个不包含 shell(`sh`、`bash`)、包管理器(`apt`)或操作系统实用程序的最小化镜像上,将攻击面降至几乎为零。 - **非 Root 强制执行** — 容器进程在非特权用户(`appuser`,UID `10001`)下运行。 - **不可变文件系统** — 根文件系统以只读模式挂载(`readOnlyRootFilesystem: true`)。易失性操作专门写入挂载在 `/tmp`(`emptyDir: {}`)的临时临时卷中。 ### ⎈ Kubernetes 级别(Helm 与 Network Policies) - **最小权限 NetworkPolicies** — 应用了默认拒绝策略。来自应用程序 pod 的 Egress 仅限于 UDP 端口 `53`(CoreDNS)和 TCP 端口 `5432`(PostgreSQL endpoint)。 - **资源约束** — 通过 Helm values 配置明确的 CPU 和内存 requests 与 limits,以保护节点免受恶意或意外的资源耗尽(OOM-Killed 保护)。 ### ☁️ 云与 Terraform 级别(最小权限与加密) - **Infrastructure Pattern Library** — 一种解耦架构,其中的原子化单一职责模块(`network`、`iam`、`compute`、`database`)完全与云状态无关。多环境执行(dev、staging、prod)完全由变量组合根驱动。 - **Security Group 微过滤** — RDS PostgreSQL 实例仅接受来自 EKS 集群主 Security Group ID 的入站连接。 - **静态数据加密** — 使用 AWS KMS 密钥在 RDS 卷上启用了存储级加密。 - **无后门** — EKS 工作节点在预置时设置了 `ec2_ssh_key = null`,彻底关闭了 SSH 攻击面。维护工作依赖于经过审计的会话管理工具。 ## 📂 仓库布局 ``` KubeSecure-GitOps/ ├── app/ # Spring Boot REST API application source │ └── Dockerfile # Secure multi-stage, non-root container build ├── helm/ # Helm packaging │ └── kubesecure-app/ │ ├── templates/ # Manifests (Deployment, Service, NetworkPolicy) │ └── values.yaml # Environment parameters ├── argocd/ # GitOps manifests │ └── application.yaml # ArgoCD Application custom resource └── terraform/ # Infrastructure as Code (Pattern Library) ├── modules/ # Reusable building blocks │ ├── network/ # VPC · 3 subnet tiers · routing · NAT Gateway │ ├── iam/ # EKS control-plane & worker-node least-privilege roles │ ├── compute/ # Private EKS 1.30 cluster & managed node group │ └── database/ # Encrypted RDS PostgreSQL 15 & security groups └── environments/ # Composition roots (state allocation) └── aws-final/ # Orchestration root wiring the infrastructure modules ``` ## 🚀 部署与验证 ### 阶段 1 — Local-First 仿真 在本地构建容器镜像: ``` docker build -t kubesecure/gitops-api:1.0.0 ./app ``` 将构建产物直接加载到 Kind 集群节点缓存中: ``` kind load docker-image kubesecure/gitops-api:1.0.0 --name kubesecure-cluster ``` 启动 GitOps 同步: ``` kubectl apply -f argocd/application.yaml ``` 访问 ArgoCD Web UI(通过 port-forward 或 ingress)来监控应用程序的同步状态: ##### 🔐 1. 认证门户 使用您的管理员凭据登录:

ArgoCD Login Portal

##### 🟢 2. 应用程序同步 通过身份验证后,请验证 `kubesecure-api-gitops` 应用程序是否已成功同步(状态为 `Healthy` 且 `Synced`):

ArgoCD Application Dashboard

### 阶段 2 — 生产环境云端迁移 初始化并配置云基础设施: ``` cd terraform/environments/aws-final/ terraform init terraform apply -auto-approve ``` 将您的本地 context 指向远程集群: ``` aws eks update-kubeconfig --region eu-west-3 --name kubesecure-final-demo-cluster ``` 将镜像推送到您私有的 ECR 仓库: ``` aws ecr get-login-password --region eu-west-3 \ | docker login --username AWS --password-stdin .dkr.ecr.eu-west-3.amazonaws.com docker tag kubesecure/gitops-api:1.0.0 \ .dkr.ecr.eu-west-3.amazonaws.com/kubesecure/gitops-api:1.0.0 docker push \ .dkr.ecr.eu-west-3.amazonaws.com/kubesecure/gitops-api:1.0.0 ``` 触发 GitOps 协调循环:在您的 `values.yaml` 中设置 `environment: "aws"`,将 `database.host` 指向 RDS endpoint,推送到 Git,然后观察 ArgoCD 自动将 manifests 同步到 EKS 上。 ## 🔍 架构回顾:Secret 管理策略 在持续、长期运行的生产流水线中,这种姿态应该向零信任模型演进: 1. **启用 OIDC provider identity** 到 EKS 集群上。 2. **设置 IRSA (IAM Roles for Service Accounts)**,在不使用硬编码 access token 的情况下,在 EKS pod 和 AWS IAM 之间建立加密信任链接。 3. **引入 External Secrets Operator (ESO)** 到集群内部,以消耗该 token,直接从 AWS Secrets Manager 获取凭据,并自动轮换它们而无需人工干预。
标签:子域名突变, 测试用例, 请求拦截