2. 自动化部署基础：CI/CD 流水线概念、常见工具与安全风险

2.1 CI/CD 流水线核心概念

持续集成（Continuous Integration, CI）与持续部署（Continuous Deployment/Delivery, CD）是现代 DevOps 实践的基石。CI/CD 流水线将代码从提交到生产环境的全过程自动化，显著缩短交付周期并降低人为失误。

2.2 常见 CI/CD 工具对比

市场上有多种成熟的 CI/CD 工具，它们在部署方式、配置语法、生态集成方面各有特点。选择工具时需考虑团队技术栈、安全合规要求及运维成本。

2.3 部署流程中的安全风险

自动化部署在提升效率的同时，也引入了新的攻击面。以下是在 CI/CD 流水线各阶段常见的安全风险及应对策略。

• 代码仓库风险： 硬编码密钥、第三方依赖漏洞（供应链攻击）、恶意 PR 注入。
• 构建阶段风险： 构建环境被篡改、依赖包投毒、构建产物被植入后门。
• 测试阶段风险： 测试数据泄露、测试环境配置漂移导致安全策略失效。
• 部署阶段风险： 未经授权的部署、部署凭证泄露、回滚机制缺失导致服务中断。
• 运行时风险： 容器镜像漏洞、配置不当导致权限提升、日志泄露敏感信息。

2.4 流水线安全权限控制原则

在自动化部署中，权限控制是防止安全风险扩散的核心防线。以下原则应在流水线设计初期就纳入架构。

1. 最小权限原则： 每个流水线任务只授予完成其功能所需的最小权限。例如，构建阶段不应拥有生产环境的部署权限。
2. 临时凭证： 使用 OIDC（OpenID Connect）或 STS（Security Service）生成短期凭证，避免长期密钥泄露风险。
3. 环境隔离： 开发、测试、预发、生产环境的 Runner 和凭证严格隔离，禁止跨环境复用。
4. 审批门禁： 部署到生产环境前必须经过人工审批或自动化安全扫描门禁（如 SAST、DAST、容器扫描）。
5. 审计日志： 所有流水线操作（谁、什么时间、做了什么、用了什么凭证）必须记录到不可篡改的审计系统。

2.5 安全流水线配置示例（GitLab CI）

以下是一个遵循安全最佳实践的 GitLab CI 配置片段，展示了如何使用受保护变量、环境审批和临时凭证。

# .gitlab-ci.yml
stages:
  - build
  - test
  - deploy

variables:
  DOCKER_IMAGE: ${CI_REGISTRY_IMAGE}:${CI_COMMIT_SHORT_SHA}

build:
  stage: build
  script:
    - docker build -t ${DOCKER_IMAGE} .
    - docker push ${DOCKER_IMAGE}
  only:
    - main

test:
  stage: test
  script:
    - docker run ${DOCKER_IMAGE} npm run test:security
  needs: [build]

deploy_prod:
  stage: deploy
  script:
    - kubectl set image deployment/app app=${DOCKER_IMAGE} --namespace=production
  environment:
    name: production
    url: https://app.example.com
  rules:
    - if: '$CI_COMMIT_BRANCH == "main"'
      when: manual  # 需要人工审批
  needs: [test]
  variables:
    KUBECONFIG: ${PROD_KUBECONFIG}  # 受保护变量，仅在 main 分支可用