dinhtri6905/aws-eks-devsecops-platform
GitHub: dinhtri6905/aws-eks-devsecops-platform
一个基于 AWS EKS 的云原生 DevSecOps 平台，通过 Terraform 与 ArgoCD GitOps 统一基础设施自动化、安全策略执行与系统可观测性。
Stars: 2 | Forks: 0
# AWS EKS 上的云原生安全 GitOps 平台
一个建立在 AWS EKS 上的云原生 DevSecOps 平台，通过 GitOps 展示安全、自动化、可扩展的交付过程。
它使用 Online Boutique（一个微服务电商演示项目）作为其工作负载——但真正的目标是平台本身：基础设施自动化、持续交付、策略执行、运行时安全和可观测性，所有这些都统一在一个运维工作流中。
基础设施即代码、GitOps、自动化安全控制和集中化监控的结合，使得基础设施、应用程序和策略都可以通过 Git 进行管理——从而实现可靠的部署、更强的安全治理，并减少人工繁琐操作。
## 目录
1. [引言](#1-introduction)
2. [架构概述](#2-architecture-overview)
3. [解决方案架构](#3-solution-architecture)
4. [仓库结构](#4-repository-structure)
5. [基础设施设计](#5-infrastructure-design)
6. [GitOps 与 CI/CD 工作流](#6-gitops--cicd-workflow)
7. [所需的 Secrets 与环境](#7-required-secrets--environments)
8. [安全架构](#8-security-architecture)
9. [监控与可观测性](#9-monitoring--observability)
10. [应用架构](#10-application-architecture)
11. [部署指南](#11-deployment-guide)
12. [测试与验证](#12-testing--validation)
13. [未来增强](#13-future-enhancements)
14. [参考](#14-references)
## 1. 引言
### 项目概述
一个自包含的 DevSecOps 平台：Terraform 配置 AWS 基础设施，引导 EKS 集群，然后通过 ArgoCD 将交付工作完全移交至 GitOps。安全在每一个阶段都得到强制执行——规划阶段、镜像构建、准入和运行时——而不是事后补缀。
### 问题陈述
微服务团队通常面临三个复合问题：**安全漂移**（配置偏离策略，漏洞被忽视）、**人工繁琐操作**（基础设施变更和部署依赖容易出错的人工协调），以及**可观测性缺口**（故障在工程师察觉之前就已经影响到用户）。
### 目标
- 完全以代码形式配置 AWS 基础设施（网络、计算、注册表、数据库）
- 通过 GitOps 交付 Kubernetes 工作负载，而非手动执行 `kubectl apply`
- 在 IaC、镜像、准入和运行时层面强制执行安全策略
- 为平台和应用提供统一的指标、仪表盘和告警
### 范围
| 层级 | 技术 | 职责 |
|---|---|---|
| 基础设施 | Terraform on AWS | VPC, EKS, ECR, RDS, ALB, IAM |
| 平台交付 | ArgoCD + Kustomize | GitOps 同步，App of Apps |
| 安全（静态） | OPA Rego | Terraform plan 策略门禁 |
| 安全（准入） | OPA Gatekeeper | Kubernetes 准入控制 |
| 安全（运行时） | Falco | Syscall 级别威胁检测 |
| 可观测性 | kube-prometheus-stack | 指标、仪表盘、告警 |
| CI/CD | GitHub Actions | 跨基础设施和应用轨道的五个工作流 |
| 应用 | Online Boutique | 11 个服务的 gRPC 微服务演示 |
### 核心能力
- 模块化的 Terraform 与远程状态后端：S3 版本控制、DynamoDB 锁定、KMS 加密
- ArgoCD App of Apps 模式，跨平台、安全、可观测性、应用层进行 sync-wave 排序
- 通过 Argo Rollouts 进行蓝绿部署，实现零影响切换和即时回滚
- Terraform plans 上的 OPA Rego 门禁，准入阶段的 OPA Gatekeeper，运行时每个节点上的 Falco
- 五个 GitHub Actions 工作流，基于 OIDC 的 AWS 认证——无长期访问密钥
- Terraform 和 GitOps 之间的明确划分：Terraform 配置基础设施并安装 ArgoCD；ArgoCD 接管其上运行的所有内容，包括它自己的 RootApplication
## 2. 架构概述
Terraform 在 AWS 上配置 VPC、EKS 集群、ECR 仓库和 RDS，然后安装 ArgoCD。此后，ArgoCD 的 RootApplication——一个通过 `kubectl` 一次性应用的静态清单——接管一切，以严格的 sync-wave 顺序从 Git 拉取平台服务、安全工具、可观测性技术栈以及 Online Boutique。GitHub Actions 负责处理基础设施变更（plan → OPA 门禁 → apply）和应用变更（构建 → 扫描 → 推送到 ECR → 更新 GitOps 清单），并在每个阶段都嵌入了安全扫描。
## 3. 解决方案架构
该平台包含五个协作层。
- **基础设施层** —— Terraform 配置所有 AWS 资源：一个跨越两个可用区（AZ）并包含公有/私有子网的 VPC，一个带有托管节点组的 EKS 集群，每个微服务一个 ECR 仓库，一个 RDS PostgreSQL 实例，以及集群及其控制器所需的 IAM 角色。一个专门的 `argocd-bootstrap` 模块通过 Helm 安装 ArgoCD；Terraform 的职责到此结束——它不管理 RootApplication。
- **GitOps 层** —— ArgoCD 持续根据 Git 协调集群状态。RootApplication 及其 AppProject 是位于 `platform/gitops/argocd/root-app.yaml` 的静态清单，在引导新集群时通过 `kubectl apply` 一次性应用。此后，ArgoCD 像协调任何其他 Application 一样对其进行协调——包括它自身。它监视 `platform/gitops/argocd/applications/` 并跨八个 sync wave（0–7）管理十个子 Application。
- **安全层** —— 在四个点进行控制：OPA Rego 在 apply 之前评估 Terraform plans，Trivy 在镜像到达注册表之前对其进行扫描，OPA Gatekeeper 在准入阶段验证每个 Pod，而 Falco 在运行时于每个节点上检查 syscall。
- **可观测性层** —— Prometheus 抓取集群、ArgoCD、Gatekeeper、Falco 和应用服务。Grafana 通过三个仪表盘对其进行可视化；Alertmanager 将告警路由到 Slack。
- **应用层** —— Online Boutique 作为 11 个 gRPC 微服务运行，外加一个 Redis 缓存和一个负载生成器，以 Argo Rollouts 资源的形式部署以实现蓝绿交付。
### 端到端平台流程
```
flowchart TD
Dev([Developer]) -->|git push| GitHub[GitHub Repository]
GitHub -->|PR opened| CI[CI Pipelines\napp-ci / terraform-ci]
CI -->|PR merged to main| CD{CD Pipelines}
CD -->|terraform/** changed| TF[terraform-cd\nplan → OPA gate → apply]
CD -->|microservices/** changed| APP[app-cd\nbuild → Trivy scan → push ECR → Kustomize update]
TF -->|terraform apply| AWS[AWS Infrastructure\nVPC · EKS · ECR · RDS]
TF -->|installs| ARGOINSTALL[ArgoCD Helm release]
ARGOINSTALL -->|kubectl apply, once| ROOT[Root Application + AppProject]
APP -->|git commit image tag| GIT[GitOps manifests updated]
GIT -->|ArgoCD detects diff| ARGO[ArgoCD sync]
ROOT --> ARGO
ARGO -->|Argo Rollouts| BG[Blue/Green Cutover]
```
### Sync Wave 排序
组件严格按照 wave 顺序部署，以便在需要它们的组件启动之前，准入 webhook 和依赖项都已准备就绪。
```
flowchart TD
W0["Wave 0 — argocd-config
ArgoCD's own configuration (RBAC, projects, notifications)"]
W1["Wave 1 — platform-services
Metrics Server, AWS Load Balancer Controller, Argo Rollouts"]
W2["Wave 2 — gatekeeper-install
OPA Gatekeeper controller + CRDs"]
W3["Wave 3 — observability-crds
Prometheus Operator CRDs"]
W4["Wave 4 — gatekeeper-templates, falco
Gatekeeper ConstraintTemplates · Falco DaemonSet"]
W5["Wave 5 — gatekeeper-policies, network-policies
Gatekeeper Constraints (7 policies) · NetworkPolicies"]
W6["Wave 6 — observability
Prometheus, Grafana, Alertmanager"]
W7["Wave 7 — online-boutique
11 microservices as Rollout resources (Blue/Green)"]
W0 --> W1 --> W2 --> W3 --> W4 --> W5 --> W6 --> W7
```
十个 Application 共享这八个 wave：`gatekeeper-templates`/`falco` 均在 wave 4 同步，而 `gatekeeper-policies`/`network-policies` 均在 wave 5 同步，因为这两对都不相互依赖——仅依赖于其前一个 wave。
### Terraform / GitOps 所有权边界
由 Terraform 管理的 Kubernetes 资源会跟踪整个对象，包括 ArgoCD 不断重写的字段（同步状态、健康状况、上次操作）。将 RootApplication 和 AppProject 置于 Terraform 之外，可以避免将这些协调误认为是配置漂移，并保持两个工具之间的边界清晰：
```
flowchart LR
subgraph Terraform
A[VPC, EKS, ECR, RDS, IAM] --> B[ArgoCD Helm release]
end
subgraph GitOps
C[Root Application + AppProject\napplied once via kubectl] --> D[Child Applications]
D --> E[Platform services, security,\nobservability, online-boutique]
end
B -.bootstrap, once.-> C
```
## 4. 仓库结构
```
aws-eks-devsecops-platform/
├── .github/workflows/ # CI/CD: terraform-ci, terraform-cd, app-ci, app-cd, check-scan
├── microservices-application/ # Online Boutique source code (11 services + protos)
├── platform/
│ ├── infrastructure/terraform/ # IaC: oidc-bootstrap, bootstrap, environments, modules, OPA policies
│ ├── gitops/ # ArgoCD root-app.yaml + App of Apps + Kustomize manifests
└── docs/ # Architecture notes and diagram sources
```
## 5. 基础设施设计
### AWS 网络
```
flowchart TB
subgraph VPC["VPC 10.0.0.0/16 — ap-southeast-1"]
subgraph AZa["ap-southeast-1a"]
PubA["Public Subnet 10.0.1.0/24
NAT Gateway + IGW route"]
PrivA["Private Subnet 10.0.11.0/24
EKS Nodes, RDS"]
end
subgraph AZb["ap-southeast-1b"]
PubB["Public Subnet 10.0.2.0/24
IGW route"]
PrivB["Private Subnet 10.0.12.0/24
EKS Nodes, RDS standby (prod)"]
end
end
PubA -->|NAT| PrivA
PubB -->|NAT, shared in dev| PrivB
```
VPC 模块应用了 AWS Load Balancer Controller 进行自动子网发现所需的 Kubernetes 子网标签：
| 标签 | 值 | 子网 | 用途 |
|---|---|---|---|
| `kubernetes.io/role/elb` | `1` | 公有 | 面向互联网的 ALB 子网发现 |
| `kubernetes.io/role/internal-elb` | `1` | 私有 | 内部 ALB 子网发现 |
| `kubernetes.io/cluster/` | `shared` | 两者 | EKS 子网所有权 |
**安全组：**
| 安全组 | 入站 | 出站 |
|---|---|---|
| EKS Control Plane | 节点组 (HTTPS 443) | 节点组 (所有) |
| EKS Nodes | 控制平面、节点间 | 所有 (拉取 ECR、AWS API) |
| ALB | 互联网 (HTTP 80, HTTPS 443) | EKS Nodes |
| RDS | EKS Nodes (PostgreSQL 5432) | 无 |
### Amazon EKS
集群 (`eks-devsecops-dev-cluster`，Kubernetes 1.33) 运行一个由 `t3.medium` 实例（`AL2023_x86_64_STANDARD`，按需，20 GiB gp3）组成的托管节点组，配置为 `desired=2, min=1, max=3` 并支持滚动更新 (`max_unavailable=1`)。公有和私有 API 端点均已启用，控制平面日志（`api`、`audit`、`authenticator`、`controllerManager`、`scheduler`）将发送至 CloudWatch。
Terraform 管理四个 EKS 插件：
| 插件 | 用途 |
|---|---|
| `vpc-cni` | Pod 网络及从 VPC CIDR 分配 IP |
| `coredns` | 用于服务发现的集群 DNS |
| `kube-proxy` | 每个节点上的网络规则 |
| `aws-ebs-csi-driver` | 动态 PersistentVolume 配置 (gp3) —— Prometheus 必需 |
### Amazon ECR
总共 11 个仓库，Online Boutique 的每个服务各一个，每个仓库都配有生命周期策略。启用了 `scan_on_push`，因此 AWS 会独立于 CI 自身的 Trivy 扫描，对每个推送的镜像重新扫描。
### Amazon RDS
PostgreSQL 配备了一个自定义参数组，记录连接、断开连接、DDL 和慢查询（阈值 1000ms），并与引擎版本相匹配。开发环境为单可用区 (Single-AZ)，生产环境为多可用区 (Multi-AZ)。备份保留 7 天并开启 PITR；已启用 Performance Insights。
### IAM 与 IRSA
| 角色 | 信任主体 | 附加的策略 |
|---|---|---|
| EKS Cluster Role | `eks.amazonaws.com` | `AmazonEKSClusterPolicy`, `AmazonEKSVPCResourceController` |
| EKS Node Group Role | `ec2.amazonaws.com` | `AmazonEKSWorkerNodePolicy`, `AmazonEKS_CNI_Policy`, `AmazonEC2ContainerRegistryReadOnly`, `AmazonSSMManagedInstanceCore` |
| EBS CSI Driver (IRSA) | OIDC → `kube-system:ebs-csi-controller-sa` | `AmazonEBSCSIDriverPolicy` |
| AWS LBC (IRSA) | OIDC → `kube-system:aws-load-balancer-controller` | 用于 ALB/NLB 管理的自定义策略 |
IRSA 在 Pod 级别而非节点级别授予 AWS 权限——受损的 Pod 无法继承整个节点角色。这就是 AWS LBC 和 EBS CSI Driver 使用 IRSA 而不是更广泛的节点 IAM 策略的原因。
### Terraform 状态管理
一个一次性的 `bootstrap` 模块（本地状态）创建远程后端：一个带有版本控制、KMS 加密、阻止公开访问以及 90 天非当前版本过期的 S3 存储桶；以及一个具有 `PAY_PER_REQUEST` 计费和时间点恢复功能的 DynamoDB 锁定表。之后的每个环境都使用此后端。
另一个独立的一次性 `oidc-bootstrap` 模块（同样使用本地状态）创建 GitHub OIDC Identity Provider 和 GitHub Actions 为 `terraform-cd`/`app-cd` 所担任的 IAM 角色。两者都在任何远程后端或 CI/CD 角色存在之前运行，因此本地状态是唯一的选择——操作顺序请参见[第 11 节](#11-deployment-guide)。
### 高可用性考量
| 组件 | 开发环境 | 生产环境 |
|---|---|---|
| EKS Control Plane | 托管（始终高可用） | 托管（始终高可用） |
| EKS Nodes | 跨 2 个可用区的 2 个节点 | 跨 2 个以上可用区的 3 个以上节点 |
| NAT Gateway | 1 个共享 | 每个可用区 1 个 |
| RDS PostgreSQL | 单可用区 | 多可用区 |
| ArgoCD | 1 个副本 | 2 个副本 |
| ALB | 多可用区（托管） | 多可用区（托管） |
## 6. GitOps 与 CI/CD 工作流
### 应用 CI 流水线 (`app-ci.yaml`)
在针对 `develop` / `feature/**` 的 PR 上触发。Gitleaks 将扫描整个 git 历史作为硬性门禁；一旦通过，Kustomize 构建验证将针对 Kubernetes 1.33 schema 运行，同时运行的还有 OPA 策略单元测试、Falco 规则验证，以及上传至 GitHub Security 标签页的非阻塞ivy 文件系统扫描。
### 应用 CD 流水线 (`app-cd.yaml`
在触及微服务路径并推送到 `main` 分支时触发。基于 `git diff` 的步骤会检测哪些服务发生了变化，随后 matrix job 仅对这些服务进行构建、扫描和推送：
```
flowchart LR
A[Detect changed services] --> B[Docker build]
B --> C[Trivy scan: SARIF + table + JSON]
C -->|CRITICAL CVEs found| X[Block ECR push]
C -->|No CRITICAL CVEs| D[Push image to ECR with SHA tag]
D --> E[kustomize edit set image]
E --> F[Git commit + push to main]
F --> G[ArgoCD detects diff → sync]
```
### 基础设施 CI 流水线 (`terraform-ci.yaml`)
在触及 Terraform 路径并针对 `develop` / `feature/**` 的 PR 上触发。运行 `terraform fmt`/`validate`、`tflint`、`tfsec` 和 Checkov（映射 CIS/NIST/SOC 2）——结果将发布到 PR 和 Security 标签页。
### 基础设施 CD 流水线 (`terraform-cd.yaml`)
在推送到 `main` 或手动触发时运行。执行 `terraform plan`，将其导出为 JSON，并根据三个 OPA Rego 策略文件对其进行评估（deny 规则将阻止 apply；warn 规则仅作记录），只有在门禁通过后才继续执行 `apply`。单独的 `destroy` 作业仅限手动触发，并在需要多名审核人员的隔离环境中运行。
### ArgoCD 同步流程
RootApplication——一个位于 `platform/gitops/argocd/root-app.yaml` 的静态清单，在 Terraform 安装 ArgoCD 后应用一次——监视 `platform/gitops/argocd/applications/` 并跨八个 sync wave（0–7）管理十个子 Application：`argocd-config` (0)、`platform-services` (1)、`gatekeeper-install` (2)、`observability-crds` (3)、`gatekeeper-templates` 和 `falco` (4)、`gatekeeper-policies` 和 `network-policies` (5)、`observability` (6)，以及 `online-boutique` (7)。ArgoCD 大约每三分钟轮询一次 Git，检测差异，并通过 Kustomize 构建 + 服务端 apply 进行协调。`selfHeal: true` 意味着任何频段外的手动更改都会被自动回滚，包括对 RootApplication 本身的更改。
### 部署策略
Online Boutique 服务通过 Argo Rollouts 使用**蓝绿部署**。一个新的绿色 ReplicaSet 在流量切换之前会被完全配置并进行健康检查；蓝色在切换前继续服务所有流量。每个服务都会暴露 `-active` 和 `-preview` 服务，并且在 `autoPromotionSeconds` 之后，Argo Rollouts 会以原子方式修补活动 Service 的选择器。
```
sequenceDiagram
participant Git
participant ArgoCD
participant Rollouts as Argo Rollouts
Git->>ArgoCD: New image tag committed
ArgoCD->>Rollouts: Sync Rollout manifest
Rollouts->>Rollouts: Provision green ReplicaSet
Rollouts->>Rollouts: Health-check green
Rollouts->>Rollouts: autoPromotionSeconds elapses
Rollouts->>Rollouts: Patch active Service selector → green
Note over Rollouts: Blue kept alive for scaleDownDelaySeconds (instant rollback window)
```
### 回滚策略
只要 `scaleDownDelaySeconds` 还未过期，蓝色副本就仍在运行——回滚只需一条命令，流量会在几秒钟内恢复：
```
kubectl argo rollouts undo -n online-boutique
```
一旦蓝色副本被缩容，回滚就意味着在 Git 中回退镜像 tag 提交（`git revert`），并让 ArgoCD 重新同步，使用之前的镜像运行一次全新的蓝绿部署周期。
## 7. 所需的 Secrets 与环境
### GitHub 仓库 Secrets
| Secret | 用途 | 工作流使用情况 |
|---|---|---|
| `AWS_DEV_ROLE_ARN` | 通过 GitHub OIDC 信任的 IAM Role 的 ARN | `terraform-cd`, `app-cd`, `check-scan` |
| `BUCKET_TF_STATE` | 从引导输出中获取的 S3 存储桶名称 | `terraform-cd`, `check-scan` |
| `TF_VAR_DB_PASSWORD` | RDS 主密码 | `terraform-cd` |
| `GITOPS_REPO_URL` | 可选的私有仓库凭据 Secret 所使用的仓库 URL | `terraform-cd` |
| `GITOPS_BOT_TOKEN` | 具有内容读写权限的 GitHub PAT，用于提交镜像 tag 更新 | `app-cd` |
| `AWS_ACCOUNT_ID` | 用于构建 ECR URI 的 12 位 AWS 账户 ID | `app-cd` |
| `SLACK_WEBHOOK_URL` | 用于流水线通知的 Incoming Webhook URL | 所有工作流 |
### OIDC 认证
工作流通过 OpenID Connect 认证到 AWS，而不是使用长期有效的访问密钥。GitHub Actions 将短期的 OIDC token 交换为临时的 AWS 凭据，该过程受信任策略限制，该策略限制了哪个仓库（以及可选的环境）可以担任该角色——GitHub secrets 中无需存储或轮换静态 AWS 密钥。
对于生产环境，请将 `sub` 条件收紧为 `environment:dev-apply`，以将角色担任限制为仅限 apply 作业。
### GitHub 环境
| 环境 | 使用者 | 保护规则 |
|---|---|---|
| `dev-plan` | `terraform-cd` → plan | 无——自动运行 |
| `dev-apply` | `terraform-cd` → apply | 可选的必需审核人员，用于受控的 apply |
| `dev-destroy` | `terraform-cd` → destroy | **强制：2 名以上必需审核人员，且仅限于 `main` 分支** |
## 8. 安全架构
纵深防御，在交付生命周期的每个阶段都设有控制措施。
```
flowchart LR
A["Commit
Gitleaks"] --> B["Source Code
Trivy fs scan"]
B --> C["IaC Plan
OPA Rego, tfsec, Checkov"]
C --> D["Image Build
Trivy image scan"]
D --> E["Registry
ECR scan-on-push"]
E --> F["Admission
OPA Gatekeeper"]
F --> G["Runtime
Falco"]
```
### 左移安全
Gitleaks 在每次 PR 时将扫描整个 git 历史作为硬性门禁——只要检测到一个密钥，就会停止整个流水线。Trivy 在任何镜像构建之前扫描源代码，并将 SARIF 结果上传到 GitHub Security 标签页。
### 基础设施安全
`terraform plan` 将被转换为 JSON，并在允许 `apply` 之前根据三个 OPA Rego 策略文件进行评估：
| 策略文件 | 关键的 `deny` 规则 |
|---|---|
| `security.rego` | EKS 不受限的公共端点、缺少密钥加密、禁用了 ECR scan-on-push、RDS 可公开访问、IAM `Action: * / Resource: *` |
| `networking.rego` | 安全组允许所有入站流量、SSH 对互联网开放 (端口 22)、EKS 节点位于公有子网中 |
| `compliance.rego` | 缺少必需标签 (`Project`, `Environment`, `ManagedBy`)、EBS 卷未加密、S3 存储桶未进行服务器端加密 |
`tfsec` 和 Checkov 也会在 CI 中运行，捕获静态配置错误并将发现结果映射到 CIS/NIST/SOC 2 框架。
### Kubernetes 安全
OPA Gatekeeper 对每个 Pod 强制执行七项准入策略：
| 约束 | 范围 | 违规影响 |
|---|---|---|
| `allow-ecr-and-trusted-registries-only` | `online-boutique` namespace | 被拒绝——来自未知 registry 的镜像 |
| `disallow-latest-tag` | 所有 namespace | 被拒绝——必须使用显式镜像 tag |
| `disallow-privileged` | 所有 namespace | 被拒绝——禁止 `privileged: true` |
| `require-labels` | `online-boutique` namespace | 被拒绝——缺少必需标签 |
| `require-non-root` | 所有 namespace | 被拒绝——必须以非 root UID 运行 |
| `require-read-only-root-filesystem` | 所有 namespace | 被拒绝——需要只读根文件系统 |
| `require-resource-limits` | 所有 namespace | 被拒绝——需要 CPU/内存限制 |
系统 namespace（`kube-system`、`gatekeeper-system`、`falco`、`monitoring`、`argocd`）被排除在外，以避免出现引导死锁。
### 运行时安全
Falco 作为 DaemonSet 使用 `modern_ebpf` 驱动程序在每个节点上运行，执行 syscall 级别的威胁检测，并对可疑行为（例如在容器内执行 shell 或意外的权限提升）发出告警。
### IAM 安全
任何地方都没有长期有效的 AWS 访问密钥：GitHub Actions 使用 OIDC，EC2 节点使用实例配置文件，平台控制器使用限定于特定 Service Account 的 IRSA。ArgoCD RBAC 默认为 `readonly`；管理员访问权限需要具备 `platform-admins` 组成员身份。
### 纵深防御摘要
| 阶段 | 控制措施 |
|---|---|
| 提交 | Gitleaks 密钥扫描（硬性门禁） |
| 源代码 | Trivy 文件系统扫描 |
| 基础设施规划 | OPA Rego deny/warn，tfsec，Checkov |
| 镜像构建 | Trivy 镜像扫描（遇到 CRITICAL CVEs 阻断推送到 ECR） |
| 注册表 | ECR `scan_on_push` |
| 准入 | OPA Gatekeeper（7 项约束） |
| 运行时 | Falco eBPF syscall 检测 |
## 9. 监控与可观测性
### Prometheus
通过 kube-prometheus-stack 部署，抓取 node-exporter、kube-state-metrics、ArgoCD、OPA Gatekeeper、Falco 以及 Online Boutique 的 `/metrics` 端点。EKS 控制平面日志会发送到 CloudWatch（`api`、`audit`、`authenticator`、`controllerManager`、`scheduler`）。
### Grafana
通过 ConfigMap 预配置了三个仪表盘：集群概览（节点状态、Pod 数量、ArgoCD 应用健康状况）、节点指标（每个节点的 CPU/内存/磁盘/网络）和应用指标（请求速率、错误率、延迟，使用 RED 方法）。
### Alertmanager
三条告警规则路由到 Slack：高 CPU（节点 > 80% 持续 5 分钟）、高内存（节点 > 85% 持续 5 分钟）以及 Pod 重启循环（15 分钟内重启 > 5 次）。
```
flowchart LR
A[Cluster, ArgoCD, Gatekeeper, Falco, App metrics] --> B[Prometheus]
B --> C[Grafana Dashboards]
B --> D[Alertmanager]
D --> E[Slack]
```
## 10. 应用架构
### Online Boutique 概述
Google 的开源微服务演示项目，在此作为平台的工作负载进行部署：跨越 Go、Python、Node.js、Java 和 C# 的 11 个服务，一个用于购物车状态的 Redis 缓存，以及一个基于 Locust 的负载生成器，用于模拟真实流量。
### 核心服务
| 服务 | 语言 | 角色 |
|---|---|---|
| `frontend` | Go | Web UI 和入口点；聚合所有后端服务 |
| `checkoutservice` | Go | 订单编排——协调购物车、支付、配送、邮件 |
| `cartservice` | C# | 购物车状态，由 Redis 支持 |
| `productcatalogservice` | Go | 产品目录 |
| `currencyservice` | Node.js | 货币转换 |
| `paymentservice` | Node.js | 模拟支付处理 |
| `shippingservice` | Go | 运费估算 |
| `emailservice` | Python | 订单确认模拟 |
| `recommendationservice` | Python | 产品推荐 |
| `adservice` | Java | 上下文广告 |
| `loadgenerator` | Python (Locust) | 模拟用户流量 |
### 服务通信流程
```
flowchart TD
Browser -->|HTTP| ALB[AWS ALB]
ALB --> Frontend[frontend]
Frontend -->|gRPC| ProductCatalog[productcatalogservice]
Frontend -->|gRPC| Currency[currencyservice]
Frontend -->|gRPC| Cart[cartservice]
Cart -->|TCP| Redis[redis-cart]
Frontend -->|gRPC| Recommendation[recommendationservice]
Frontend -->|gRPC| Ad[adservice]
Frontend -->|gRPC| Checkout[checkoutservice]
Checkout -->|gRPC| Cart
Checkout -->|gRPC| ProductCatalog
Checkout -->|gRPC| Currency
Checkout -->|gRPC| Shipping[shippingservice]
Checkout -->|gRPC| Payment[paymentservice]
Checkout -->|gRPC| Email[emailservice]
```
所有服务间通信均通过集群内部 DNS 使用 gRPC。只有 `frontend` 通过 ALB Ingress 对外暴露——并且它像任何其他工作负载一样与平台集成：由 ArgoCD 部署，受 OPA Gatekeeper 治理，被 Falco 监控，并被 Prometheus 抓取。
## 11. 部署指南
### 前置条件
| 工具 | 最低版本 |
|---|---|
| Terraform | `>= 1.10.0` |
| AWS CLI | `>= 2.x` |
| kubectl | `>= 1.30` |
确保已配置 AWS 凭据，并在开始之前设置了来自[第 7 节](#7-required-secrets--environments)的 GitHub 仓库 secrets。
### 为 CI/CD 引导 GitHub OIDC
需运行一次，使用具有 IAM 管理员权限的本地 AWS 凭据，**必须在**设置 `AWS_DEV_ROLE_ARN` GitHub secret 或运行任何工作流**之前**执行。这将创建 GitHub OIDC Identity Provider 和 GitHub Actions 通过 `sts:AssumeRoleWithWebIdentity` 担任的 IAM 角色（`github-actions-terraform-dev`）——GitHub 中不存储任何静态 AWS 密钥。
```
cd platform/infrastructure/terraform/oidc-bootstrap
cat > terraform.tfvars < /dev/null && echo "OK"
# ArgoCD application health
kubectl get applications -n argocd \
-o jsonpath='{range .items[*]}{.metadata.name}{"\t"}{.status.sync.status}{"\t"}{.status.health.status}{"\n"}{end}'
# 验证 selfHeal（进行手动更改，观察 ArgoCD 将其还原）
kubectl scale deployment frontend -n online-boutique --replicas=5
sleep 180
kubectl get deployment frontend -n online-boutique -o jsonpath='{.spec.replicas}'
# 预期：1
```
### 应用可用性
```
kubectl argo rollouts list rollouts -n online-boutique
ALB=$(kubectl get ingress -n online-boutique frontend \
-o jsonpath='{.status.loadBalancer.ingress[0].hostname}')
curl -s -o /dev/null -w "%{http_code}" "http://${ALB}" # expect 200
```
### 监控技术栈
```
kubectl exec -n monitoring deploy/kube-prometheus-stack-prometheus -- \
wget -qO- "http://localhost:9090/api/v1/targets" | \
jq '.data.activeTargets[] | select(.labels.namespace=="online-boutique") | {job: .labels.job, health: .health}'
```
## 13. 未来增强
### 短期
| 增强项 | 理由 |
|---|---|
| ArgoCD webhook | 用即时的 Git 推送通知取代 3 分钟轮询 |
| Argo Rollouts Canary | 扩展至带有 Analysis 模板的 Canary 策略，以实现自动提升/中止 |
| External Secrets Operator | 将 secrets 从 AWS Secrets Manager 同步到 Kubernetes Secrets 中 |
| Cluster Autoscaler | 基于不可调度的 Pod 数量自动缩放节点 |
| HTTPS/TLS 终止 | 在 ALB 监听器上使用 ACM 证书——目前仅支持 HTTP |
### 中期
| 增强项 | 理由 |
|---|---|
| GitHub SSO for ArgoCD | 通过 Dex 使用 GitHub OAuth 替换初始管理员密码 |
| Falcosidekick | 将 Falco 告警路由到 Slack 和 Prometheus，而不是仅输出到 Pod 日志 |
| 分布式追踪 | 添加 AWS X-Ray 或 Jaeger 以实现跨 gRPC 服务的请求追踪 |
| OPA Gatekeeper mutation | 自动注入资源限制，而不是拒绝不合规的 Pod |
| 多区域 DR | 部署备用集群并结合 RDS 跨区域复制 |
### 长期
| 增强项 | 理由 |
|---|---|
| 多集群 ArgoCD | 从单个 ArgoCD 实例管理开发和生产集群 |
| ApplicationSet | 用针对环境/服务矩阵的生成器替换手动的 Application YAML |
| Vault 集成 | 用 HashiCorp Vault 替换 AWS Secrets Manager，以获取动态 secrets 和 PKI |
| 服务网格 | 服务间的 mTLS、流量管理、断路 |
| 成本优化 | 使用 Karpenter 进行节点配置，使用 KEDA 进行事件驱动缩放 |
## 14. 参考
### 官方文档
- [Amazon EKS 文档](https://docs.aws.amazon.com/eks/)
- [Terraform AWS Provider](https://registry.terraform.io/providers/hashicorp/aws/latest/docs)
- [ArgoCD 文档](https://argo-cd.readthedocs.io/)
- [Kustomize 文档](https://kustomize.io/)
- [OPA Gatekeeper](https://open-policy-agent.github.io/gatekeeper/)
- [Falco 文档](https://falco.org/docs/)
- [kube-prometheus-stack](https://github.com/prometheus-community/helm-charts/tree/main/charts/kube-prometheus-stack)
- [AWS Load Balancer Controller](https://kubernetes-sigs.github.io/aws-load-balancer-controller/)
- [Argo Rollouts](https://argoproj.github.io/argo-rollouts/)
### 相关项目
- [Google Online Boutique](https://github.com/GoogleCloudPlatform/microservices-demo) —— 用作平台工作负载的演示性微服务应用
### 最佳实践与架构参考
- [AWS EKS 最佳实践](https://aws.github.io/aws-eks-best-practices/) —— 安全、网络和可靠性指南
- [GitOps with ArgoCD](https://argo-cd.readthedocs.io/en/stable/user-guide/best_practices/) —— App of Apps 模式与 GitOps 原则
标签：EVTX分析