你如何在 CI/CD 管道中处理 secrets？

Question

Accepted Answer

CI/CD 管道需要 **secrets**（API 密钥、部署凭证、数据库密码、令牌）来构建和部署——但以不安全的方式处理它们是一个严重的风险。正确的 **secrets 管理**在整个管道中保持凭证安全。

## 问题：secrets 永远不应该被暴露

```text
Pipelines need credentials, but secrets are a major security risk if mishandled:
  ⚠️ NEVER hardcode secrets in code, pipeline config files, or commit them to Git
     (committed secrets are exposed in history — even if "removed" later)
  ⚠️ NEVER print secrets in logs (pipeline logs may be visible/stored)
→ Leaked CI/CD secrets (deploy keys, cloud credentials) can compromise entire systems.
```

## 正确的 secrets 处理

```text
✓ Use the CI/CD platform's SECRETS STORE — encrypted secrets injected as env vars at
  runtime (GitHub Actions Secrets, GitLab CI variables, etc.) — NOT in the config file
✓ Use dedicated SECRETS MANAGERS — HashiCorp Vault, AWS Secrets Manager, etc.
  (fetch secrets at runtime; centralized, audited, rotatable)
✓ Reference secrets by NAME in the pipeline; the platform injects the value securely:
```

```yaml
# GitHub Actions: reference a secret (stored encrypted in the repo settings)
steps:
  - run: ./deploy.sh
    env:
      API_KEY: ${{ secrets.API_KEY }}   # injected securely, not hardcoded, masked in logs
```

## 最佳实践

```text
✓ LEAST PRIVILEGE — pipeline credentials should have only the permissions needed
✓ Prefer short-lived/temporary credentials (e.g. OIDC to assume a cloud role — no
  long-lived keys stored at all)
✓ ROTATE secrets regularly; rotate IMMEDIATELY if leaked
✓ Mask secrets in logs (platforms do this for stored secrets); audit secret access
✓ Separate secrets per environment (dev/staging/prod)
```

## 为什么这很重要

理解如何在 CI/CD 管道中处理 secrets 很重要，因为 **secrets 管理是一个关键的安全问题**，管道处理强大的凭证，如果泄露，可能会破坏整个系统，因此这是必要的安全知识。

管道需要 secrets（API 密钥、部署凭证、数据库密码）来构建和部署，但错误处理它们是一个**严重且常见的安全风险**。

理解基本规则至关重要——**永远不要在代码或管道配置中硬编码 secrets，永远不要将它们提交到 Git**（它们在历史中被暴露，即使稍后被