docs: consolidate Alicloud Pulumi guidance and add multicloud plan

This commit is contained in:
shenlan 2025-09-29 23:08:49 +08:00
parent 0a91feeb6b
commit 42583d4253
3 changed files with 143 additions and 55 deletions

View File

@ -105,3 +105,56 @@
- 治理扩展Terraform/ROS、命名规范、标签策略、监控告警、备份快照。
通过上述基线,单用户场景也能在阿里云上建立符合 Landing Zone 要求的环境,并为未来扩展至团队或多账号场景奠定基础。
## 7. Pulumi IaC 实现指南
为便于快速落地上述基线,仓库提供了基于 Pulumi Python 的实现(目录:`iac_modules/pulumi`与《docs/landingzone/alicloud-landingzone-mvp-single-account.md》设计保持一致可直接复用或按需裁剪。
### 7.1 模块拆分
| 模块 | 说明 |
| --- | --- |
| `modules/identity/ram.py` | 创建 RAM 用户、用户组及策略绑定,覆盖 `ops-automation`、`audit-viewer` 等角色需求。 |
| `modules/storage/oss.py` | 管理 OSS 日志桶(版本控制 + 生命周期),用于 ActionTrail 与 Pulumi 状态存储。 |
| `modules/audit/actiontrail.py` | 启用 ActionTrail将操作日志集中投递至指定 OSS Bucket。 |
| `modules/config_service/baseline.py` | 初始化 Cloud Config Recorder、Delivery Channel 与基础合规规则。 |
| `modules/network/vpc.py` | 构建单 VPC + 双可用区交换机的网络基线拓扑。 |
| `modules/security/security_groups.py` | 创建默认安全组及入/出站规则,默认仅放行必要出站流量。 |
### 7.2 配置结构
`config/alicloud/` 目录提供示例配置,按照 Landing Zone 设计拆分:
- `base.yaml`:区域与全局标签定义。
- `identity.yaml`RAM 用户 / 用户组与策略映射。
- `storage.yaml`ActionTrail 日志桶(版本控制 + 生命周期)。
- `network.yaml`VPC / 交换机拓扑结构。
- `security.yaml`:安全组与默认规则。
- `audit.yaml`ActionTrail 开关与 OSS 投递目标。
- `config-service.yaml`Cloud Config 基线配置。
> ⚠️ 注意:`target_arn`、`assume_role_arn` 等字段需替换为真实账号 ID`${AliUid}`)。
### 7.3 使用示例
```bash
# 安装依赖
pip install -r requirements.txt
# 指定配置目录(默认读取 config/,此处指向示例配置)
export CONFIG_PATH=config/alicloud
# Pulumi 登录(可选:使用 OSS backend 或 Pulumi Service
pulumi login
# 预览或部署
pulumi preview --cwd iac_modules/pulumi
pulumi up --cwd iac_modules/pulumi
```
### 7.4 自动化与扩展建议
- 可通过 `.github/workflows/iac-pipeline-alicloud-landingzone-baseline.yaml`,结合 `pulumi/actions@v4` 构建 Preview + 主干自动部署流程,使用仓库 Secrets 管理 `ALICLOUD_ACCESS_KEY_ID/SECRET``PULUMI_ACCESS_TOKEN`
- 根据生产需求扩展 Cloud Config 规则或引入企业版聚合器。
- 在安全组模块中追加环境专属规则Prod/Test
- 利用 `pulumi stack` 拆分 dev / prod 状态,配合 GitHub Environments 审批。

View File

@ -0,0 +1,90 @@
# 多云 Landing Zone 设计规划指南
本文档用于指导在多云环境(如 AWS、阿里云、Vultr 等)中构建统一的 Landing Zone 能力,确保账号治理、网络安全、合规与运维的一致性。设计目标包括:
- **统一治理**:跨云资源目录、权限与策略保持一致。
- **安全基线**:各云环境满足最低安全要求并可扩展为企业级合规。
- **网络互通**:多云 VPC/VNet/私有网络之间实现安全互联。
- **成本优化**:集中化预算管理与资源可视化。
- **自动化与可扩展性**:通过 IaC 与 GitOps 提升部署效率。
## 1. 治理与组织结构
1. **多云组织映射**
- AWS Organizations、阿里云资源目录、Vultr 项目等均划分为 Management、Security、Shared Services、Workload 等账户/项目。
- 在顶层引入统一的命名与标签策略,例如 `org=<company>`、`env=<dev|staging|prod>`、`cloud=<aws|alicloud|vultr>`。
2. **集中身份管理**
- 推荐使用身份提供商IdP如 Azure AD、Okta 或自建 IAM统一对接各云的 SSOAWS IAM Identity Center、阿里云 RAM SSO、Vultr API Key 管理)。
- 对云上 Root/主账号启用 MFA并限制使用长期密钥。
3. **策略基线**
- 定义跨云统一的最低权限策略模板结合各云原生策略语言IAM Policy、RAM Policy、Vultr API Scope
- 制定账号生命周期流程(申请、审批、创建、停用)。
## 2. 网络与连接拓扑
1. **云内网络设计**
- 各云按照环境划分 VPC/VNet`<cloud>-<env>-vpc<n>`,包含公有与私有子网。
- 使用云防火墙、安全组或 NACL 控制东西/南北向流量。
2. **跨云互联**
- 构建核心网络中心Hub通过专线、SD-WAN 或 VPN Mesh 连接多云 VPC。
- 建议采用高可用拓扑:双 VPN Gateway + BGP 动态路由或使用第三方云互联服务Megaport、Equinix Fabric
- 明确跨云 IP 规划,避免地址冲突,可采用统一的 RFC1918 地址规划表。
3. **服务发现与流量治理**
- 使用统一的 DNS如 Route 53 Private Hosted Zone、阿里云云解析 PrivateZone并通过转发器打通。
- 引入服务网格或 API GatewayIstio、Kong支持跨云服务访问控制。
## 3. 安全与合规
1. **日志与审计汇聚**
- 各云启用审计日志AWS CloudTrail、阿里云 ActionTrail、Vultr Activity Log集中投递到安全账号的存储S3、OSS、对象存储
- 使用 SIEM如 Splunk、ELK、阿里云云安全中心统一分析。
2. **配置合规与基线扫描**
- 采用多云 CSPM 工具Prisma Cloud、Check Point Dome9或开源方案Cloud Custodian
- 各云原生配置管理AWS Config、Cloud Config、Terraform Sentinel共同执行合规策略。
3. **秘钥与证书管理**
- 统一管理 KMS/KeyVault建立密钥轮换策略。
- 证书通过 ACME 或企业 CA 下发,并同步至各云负载均衡或 API Gateway。
4. **安全运营流程**
- 定义跨云事件响应手册,包含告警等级、通知渠道、分派流程。
- 建立渗透测试与漏洞扫描计划,覆盖所有云环境。
## 4. 运维与自动化
1. **基础设施即代码IaC**
- 使用 Terraform + 多云 Provider 或 Pulumi 统一编排,按照环境与云拆分模块。
- 配置 GitOpsArgo CD、Flux用于 Kubernetes 及应用层部署。
2. **CI/CD 与分支策略**
- 建立多云 IaC Pipeline包含 plan、approve、apply 阶段。
- 使用环境变量或工作目录Workspace/Stack区分不同云与环境。
3. **监控与可观测性**
- 引入多云监控聚合Prometheus 联邦、Datadog、Grafana Cloud
- 定义统一的 SLO/SLI 指标,如 API 延迟、可用性、错误率。
4. **备份与灾备**
- 关键数据在不同云间进行异地备份(例如 AWS S3 Cross-Region Replication + OSS 跨区域复制)。
- 建立跨云容灾演练计划,验证故障切换流程。
## 5. 成本与可持续性
1. **成本可视化**
- 汇总各云账单至 FinOps 平台CloudHealth、Kubecost、阿里云资源管理
- 定义成本标签,自动生成成本报表与预算告警。
2. **资源优化**
- 定期分析闲置资源ECS/EC2/裸金属、负载均衡、公网 IP
- 利用预留实例、节省计划、突发型实例等策略。
3. **绿色与可持续目标**
- 关注各云能耗披露数据,优先选择低碳区域。
- 使用自动伸缩与关机策略减少空闲资源能耗。
## 6. 路线图与落地步骤
1. **阶段 1基线搭建**
- 完成多云组织/账号初始化与身份整合。
- 部署最小网络互联与日志审计能力。
2. **阶段 2自动化与合规**
- 上线 IaC 管理与合规扫描工具,建立审批流程。
- 实施跨云监控、告警与事件响应机制。
3. **阶段 3优化与演进**
- 推动成本优化与容量管理,持续完善安全策略。
- 引入服务网格、跨云应用编排等高级能力。
通过以上规划,可以在多云环境中构建安全、可控、可扩展的 Landing Zone为业务跨云部署与弹性伸缩提供坚实基础。

View File

@ -1,55 +0,0 @@
# ☁️ Pulumi Alicloud Landing Zone Baseline
该目录提供了与《docs/landingzone/alicloud-landingzone-mvp-single-account.md》一致的 Pulumi Python 实现,用于在单账号阿里云环境中快速落地身份、审计、配置合规、网络与安全基线。
## ✅ 模块拆分
| 模块 | 说明 |
| --- | --- |
| `modules/identity/ram.py` | 创建 RAM 用户、用户组以及策略绑定,覆盖 `ops-automation`、`audit-viewer` 等身份。 |
| `modules/storage/oss.py` | 管理 OSS 日志桶,支持版本控制与生命周期策略,用于 ActionTrail & Pulumi 状态。 |
| `modules/audit/actiontrail.py` | 启用 ActionTrail将操作日志投递到指定 OSS Bucket。 |
| `modules/config_service/baseline.py` | 初始化 Cloud Config Recorder、Delivery Channel 与基础规则。 |
| `modules/network/vpc.py` | 构建单 VPC + 双可用区交换机的网络基线。 |
| `modules/security/security_groups.py` | 创建默认安全组及入站/出站规则,默认仅放行出站流量。 |
## 📂 配置结构
`config/alicloud/` 目录提供示例配置,按照 Landing Zone 设计拆分:
- `base.yaml`:区域与全局标签
- `identity.yaml`RAM 用户/用户组与策略
- `storage.yaml`ActionTrail 日志桶(版本控制+生命周期)
- `network.yaml`VPC / 交换机拓扑
- `security.yaml`:安全组与规则
- `audit.yaml`ActionTrail 开关与目标 OSS
- `config-service.yaml`Cloud Config 基线配置
> ⚠️ 其中 `target_arn`、`assume_role_arn` 等字段需替换为实际账号 ID`${AliUid}`)。
## 🚀 使用方式
```bash
# 安装依赖
pip install -r requirements.txt
# 设置配置目录(默认读取 config/,此处指向示例配置)
export CONFIG_PATH=config/alicloud
# Pulumi 登录(可选:使用 OSS backend 或 Pulumi Service
pulumi login
# 预览或部署
pulumi preview --cwd iac_modules/pulumi
pulumi up --cwd iac_modules/pulumi
```
## 🔒 GitHub Actions 自动化
新增 `.github/workflows/iac-pipeline-alicloud-landingzone-baseline.yaml`,结合 `pulumi/actions@v4` 实现 Preview + 主干自动部署,使用 Secrets 管理 `ALICLOUD_ACCESS_KEY_ID/SECRET``PULUMI_ACCESS_TOKEN`
## 🧩 扩展建议
- 根据生产需求扩展 Cloud Config 规则或引入企业版聚合器。
- 在安全组模块中追加环境专属规则Prod/Test
- 利用 `pulumi stack` 拆分 dev/prod 状态,配合 GitHub Environments 审批。