Lia-Bing0/secure-terraform-azure-pipeline

# secure-terraform-azure-pipeline [](https://github.com/Lia-Bing0/secure-terraform-azure-pipeline/actions/workflows/terraform-ci.yml) 一个专注于 DevSecOps 的 Terraform + GitHub Actions Azure 工作流，在合并更改之前强制执行基础设施质量检查和安全策略门禁。 本项目通过在 CI 阶段拦截不安全的基础设施即代码 配置，展示了切实可行的云安全控制。 该仓库包含用于基础设施配置的 Terraform，用于流水线强制执行的 GitHub Actions，以及用于 Entra ID 联合身份验证和 Azure RBAC 设置的 PowerShell 引导自动化。 ## 关键成果 - 构建了一个 CI 流水线，在每次推送到 `main` 分支和每个 Pull Request 时运行 Terraform 检查（`fmt`、`init`、`validate`、`plan`）。 - 集成 Checkov 作为安全门禁，在 Azure 资源配置错误时使构建失败。 - 直接在 Terraform 中强化了 Azure Storage 基线（仅限 HTTPS、最低 TLS 1.2、无公共访问、无共享密钥）。 - 演示了 失败 → 修复 → 通过 的工作流，以验证安全强制行为。 - 实施了 GitHub → Azure OIDC 联合身份验证（无长期有效的客户端密钥）。 - 配置了具有作用域 RBAC 的 Entra ID 联合凭据。 - 为 Terraform 后端状态启用了 AzureAD 身份验证。 ## 架构 ``` Developer Commit / PR | v GitHub Actions: .github/workflows/terraform-ci.yml | +--> terraform fmt -check -recursive +--> terraform init +--> terraform validate +--> terraform plan +--> Checkov scan (policy gate) | +--> PASS: merge/deploy flow can continue +--> FAIL: pipeline blocks insecure change | v Azure Resource Group + Hardened Storage Account ``` ## CI/CD 流水线概述 ### 工作流触发器 - `push` 到 `main` - `pull_request` ### 流水线步骤 - Terraform 格式强制执行 - Provider 初始化 - 配置验证 - 执行计划预览 - 使用 `Checkov` 进行安全扫描 Checkov 检查失败会导致工作流以非零状态退出，从而将安全性强制作为合并门禁。 ## 强制执行的安全控制 - **仅限 HTTPS + TLS1.2**：`https_traffic_only_enabled = true` 和 `min_tls_version = "TLS1_2"`。 - **禁止公共/匿名 Blob 访问**：`allow_nested_items_to_be_public = false`。 - **实施了额外的存储强化** - **仅 AzureAD 身份验证** - `shared_access_key_enabled = false` - **临时公共网络访问** - `public_network_access_enabled = true` 这是为了 GitHub 托管的运行器 所做的刻意设计权衡，因为它们必须通过公共 Azure 端点访问 Terraform 后端。 在生产环境中，这通常会被替换为 **Private Endpoint + 自托管运行器**，以消除公共网络暴露。 - **异地冗余复制 (GRS)** 安全扫描在 CI 中自动化；不安全的配置更改会导致工作流失败。 ## 演示：失败 → 修复 → 通过 ### 策略门禁失败 在一个 Pull Request 中引入了故意不安全的 Terraform 配置，以验证 CI 流水线在合并前是否会拦截不符合规范的基础设施即代码更改。  ### 安全扫描证据 Checkov 检测到与存储账户配置中的公共 Blob 访问相关的策略违规。  ### 修复 修正了启用公共 Blob 访问的不安全设置。 ``` allow_nested_items_to_be_public = false ```  ## 安全强制证据 ### OIDC 身份验证 (无密钥 CI)  ### Entra 联合凭据  ### 存储安全配置  ## 如何在本地运行 ``` cd infra terraform fmt -check -recursive terraform init terraform validate terraform plan ``` Azure 身份验证选项： - Azure CLI 登录：`az login` - 服务主体环境变量：`ARM_CLIENT_ID`, `ARM_CLIENT_SECRET`, `ARM_TENANT_ID`, `ARM_SUBSCRIPTION_ID` ## GitHub 身份验证 (OIDC) 此流水线使用 GitHub OIDC 联合身份验证来通过 Azure 进行身份验证，无需客户端密钥。 ### 必需的 GitHub Actions Secrets - `AZURE_CLIENT_ID` - `AZURE_TENANT_ID` - `AZURE_SUBSCRIPTION_ID` 不需要 `ARM_CLIENT_SECRET`。 OIDC 联合身份验证通过 Entra ID 联合凭据和 `azure/login@v2` 进行配置。 ### 联合身份凭据 (信任边界) 文件 [`federated-credential-main-branch.json`](bootstrap/entra/federated-credential-main-branch.json) 定义了 GitHub Actions 与 Azure (Entra ID) 之间的工作负载身份信任关系。 - **颁发者**：GitHub OIDC 提供商 (`https://token.actions.githubusercontent.com`) - **主体**：限制为 `repo:Lia-Bing0/secure-terraform-azure-pipeline:ref:refs/heads/main` - **受众**：`api://AzureADTokenExchange` 此配置确保只有从此仓库受保护的 `main` 分支触发的工作流才能通过 Azure 进行身份验证。 身份验证是短期且限定作用域的，消除了静态凭据并强制执行分支级别的部署信任。 ## 清理 / 卸载 ``` cd infra terraform destroy ``` ## 第二阶段 – 生产强化 (已完成) - 在 Azure Storage (`liatfstateprod01`) 中配置了远程 Terraform 状态 - 通过 Azure Blob 后端启用了状态锁定 - `/bootstrap` 下的引导自动化用于身份 + RBAC 设置 - 使用 `terraform import` 处理基础设施状态漂移 ## 下一阶段 - 将 Terraform 后端访问迁移到 **Azure Private Endpoint** - 引入 **VNet 内的自托管 GitHub runner** 以消除公共后端访问 - 集成 **Azure Key Vault 与客户管理的密钥 (CMK)** - 启用 **诊断设置到 Log Analytics / Microsoft Sentinel** - 添加 **Azure Policy / Defender for Cloud 集成** ## 为什么这很重要 - 通过在部署前强制执行控制，将云安全左移。 - 通过自动化 CI 门禁防止配置漂移。 - 展示了使用 OIDC 联合身份验证、最小权限 RBAC 和与企业 DevSecOps 标准一致的策略即代码 强制来实施安全的 CI/CD。

标签：AI合规, Azure, DevSecOps, ECS, Entra ID, GitHub Actions, IaC扫描, IPv6, Libemu, OIDC, PowerShell, RBAC, Terraform, 上游代理, 人工智能安全, 合规性, 安全基线, 教学环境, 最小权限, 特权提升, 策略即代码, 聊天机器人安全, 自动化部署, 自动笔记