GitLab CI/CD 中的密钥管理

GitLab CI/CD 为自动化软件交付 Pipeline 提供了强大的平台，但要在其中安全地管理 secrets，需要在安全性、自动化和开发者体验之间取得平衡。在本指南中，我们将探讨在 GitLab CI/CD 中管理 secrets 的最佳实践，并回顾与 Infisical 的集成模式，以帮助你构建安全且高效的 CI/CD Pipeline。

在 CI 系统中管理 secrets 的挑战

CI 系统通常依赖变量来执行任务，无论是为了控制任务和 pipelines 的行为、存储常用值，还是为了避免在声明指令的文件中硬编码这些值；在 GitLab CI 中，这个文件就是 .gitlab-ci.yml。

然而，对于像 secrets 这样的敏感变量，CI 系统通过环境变量存储和暴露这些值的内置机制既不安全，也不实用。你应该尽快将其替换为适当的 secrets 管理方案，以防止随着业务或团队增长而出现问题。

很明显，为什么 CI 系统并不是为存储 secrets 而设计的：

• 它们无法在单一安全位置集中管理你的 secrets，从而导致 secrets 在不同项目中重复，并增加供应链攻击面。
• 它们不提供遵循最小权限原则所需的细粒度访问控制。
• 它们缺乏自动轮换机制，当 secrets 需要轮换时会产生巨大的运维开销。
• 它们不提供合规和事件响应所需的审计能力。
• 它们通常不够安全，一旦被攻破就会成为薄弱环节，正如 2022 年 CircleCI 泄露事件所展示的那样，该事件暴露了其所有客户的 secrets。

当今的云系统需要一种更好的方式来处理 secrets。下面我们来看看如何使用 Infisical 实现这些理念。它是一款为现代 CI/CD 工作流构建的新型 secrets 管理工具。

Infisical 简介

长期以来，secrets 管理领域一直由 HashiCorp Vault 主导，但自从 HashiCorp 在 2023 年将 Vault 从 MPL 切换到 BSL 许可证以来，许多团队一直在寻找替代方案。Infisical 已成为开发者的自然选择，它提供了几个关键优势：

• 开发者优先的方法，可随团队规模扩展
• 用于配置、版本控制、访问控制和轮换的一体化解决方案
• 用于无缝开发工作流的直观 UI/CLI
• 适合你现有基础设施的可适应架构
• 采用 MIT 许可证的开源项目（可自托管）
• 积极维护，拥有 17k+ GitHub stars
• 跨 CI/CD 平台和工具的广泛集成

了解 Infisical 的核心功能

Infisical 提供了几个强大的功能，使其特别适合 GitLab CI/CD 环境：

1. 特定环境的 secrets - 为开发、暂存和生产环境分别管理 secrets
2. Secret 引用 - 使用 ${SECRET_NAME} 等语法在其他 secrets 中复用 secrets
3. 细粒度访问控制 - 精细控制谁可以访问哪些 secrets
4. 审计日志 - 跟踪对 secrets 的所有访问和修改
5. 多种身份验证方式 - 支持 OIDC、Token 和服务账户

使用 Infisical 构建安全的 GitLab CI/CD Pipeline

下面我们将逐步了解如何将 Infisical 与 GitLab CI/CD 集成。我们将探讨两种主要的集成模式：

1. 原生集成 - 将 secrets 同步到 GitLab CI/CD 变量
2. Pipeline 集成 - 通过 OIDC 身份验证直接从 Infisical 使用 secrets

原生集成：快速入门

标准集成会自动将 secrets 从 Infisical 同步到 GitLab CI/CD 变量，这使你只需进行少量配置即可快速开始：

1. 在 Infisical 仪表板中，进入你的项目，选择 Integrations > Native Integrations，然后点击 “Add Integration”。
2. 从集成列表中选择 “GitLab”。
3. 授权该集成将 secrets 从 Infisical 同步到 GitLab。
4. 选择环境（例如 Development、Staging、Production）。
5. 选择你的 GitLab 项目。
6. 可选：在 “Options” 选项卡中配置前缀/后缀设置。
7. 保存该集成。

配置完成后，Infisical 将自动在你的 GitLab 项目中创建 CI/CD 变量，在 GitLab 中为变量名添加前缀/后缀，并同步 secrets。这样一来，secrets 就可以像普通环境变量一样在你的 CI/CD pipelines 中使用：

虽然这种方法提供了简单的入门体验，但它仍然会将 secrets 存储在 GitLab CI/CD 中。为了进一步增强安全性，我们来看看一种更高级的集成模式。

使用 OIDC 身份验证的 Pipeline 集成

为了实现最高级别的安全性，我们可以直接在 pipeline 中使用 Infisical CLI，并通过 OpenID Connect（OIDC）进行身份验证。这样就完全无需在 GitLab CI/CD 中存储 secrets。

设置 OIDC 身份验证

首先，我们需要配置 GitLab 和 Infisical 之间的 OIDC 身份验证：

1. 在 Infisical 中，进入 Organization Settings > Access Control > Identities。
2. 创建一个角色为 “Member” 的新身份。

3. 删除默认的 “Universal Auth” 配置。
4. 添加一个新的 “OIDC Auth” 配置。
5. 根据需要配置 audience 和自定义 claims。

了解更多：

• 创建身份并将其添加到项目，然后使用该身份在 GitLab CI 中访问 Infisical
• 使用 GitLab OpenID Connect 作为身份验证提供者
• GitLab id_tokens

在 GitLab CI/CD Pipeline 中使用 Infisical

现在，我们可以 删除 GitLab CI/CD 变量中已同步的 secrets，并配置 pipeline 以使用带有 OIDC 身份验证的 Infisical CLI：

image: python:3.13

stages:
  - test

before_script:
  - apt update && apt install -y curl
  - curl -LsSf https://astral.sh/uv/install.sh | sh
  - curl -1sLf 'https://dl.cloudsmith.io/public/infisical/infisical-cli/setup.deb.sh' | bash
  - apt-get update && apt-get install -y infisical
  - pip install uv

test:
  id_tokens:
    INFISICAL_ID_TOKEN:
      aud: https://infisical.example.com
  script:
    - export INFISICAL_TOKEN=$(infisical login --method=oidc-auth --machine-identity-id=<your-machine-identity-id> --oidc-jwt=$INFISICAL_ID_TOKEN --silent --plain)
    - infisical run --projectId=<your-project-id> --env=dev -- uv run -- pytest

这个 pipeline：

1. 使用 Python 镜像作为基础，并安装 Infisical CLI、UV（用于测试）以及相关依赖。
2. 为 OIDC 身份验证设置一个 GitLab ID Token。
3. 安装 Infisical CLI。
4. 使用 OIDC 身份验证登录。
5. 使用 infisical run 将 secrets 作为环境变量注入到后续命令 uv run -- pytest 中。

这意味着 secrets 是动态注入的，完全不会存储在 GitLab CI 中！这种方法带来了几个显著的安全优势：

• Secrets 永远不会存储在 GitLab CI/CD 中，从而降低了供应链攻击的风险。
• 身份验证使用短期 Token，而不是长期凭据。
• Secret 访问仅限于需要它们的特定命令。
• 所有访问都会记录在 Infisical 的审计系统中。

使用 Terraform 进行基础设施配置

在进行基础设施配置时，Infisical 与 Terraform 无缝集成，以管理云凭据和其他敏感基础设施数据。Terraform 1.10 引入了一个名为 “ephemeral resources” 的强大新功能，完美补充了 GitLab CI/CD 的安全实践。

Ephemeral resources 是临时资源，不会持久保存在 Terraform state 或 plan 文件中——它们仅在执行期间存在，因此非常适合处理 secrets。Infisical Terraform provider 支持此功能，使你能够在基础设施配置期间安全地访问 secrets，而无需将其存储在 state 文件中。

有关 Terraform ephemeral resources 的详细说明以及如何将其与 Infisical 配合使用，请查看我们的深入指南：关于 Terraform Ephemeral Resources 你需要知道的一切

使用 Infisical 进行 Kubernetes 部署

对于基于 GitOps 的持续部署工作流，Infisical 提供了多种与 Kubernetes 的集成选项，以确保安全且高效的 secrets 管理。当使用 GitLab CI/CD 将应用部署到 Kubernetes 时，你可以利用这些方法在增强安全性的同时保持 GitOps 原则。

Infisical 为 Kubernetes 提供了三种主要的集成方法：

1. Infisical Kubernetes Operator - 一种原生 Kubernetes 方案，带有用于同步、推送和管理动态 secrets 的自定义资源。
2. External Secrets Operator - 与流行的 ESO 框架集成，用于从外部提供者获取 secrets。
3. Secrets Store CSI Driver - 直接在 Pod 级别挂载 secret，无需中间的 Kubernetes secrets。

每种方法在声明式配置、安全性和运维复杂性之间都有不同的权衡。有关使用 Kubernetes 实施安全 GitOps 工作流的完整指南，请参阅我们的详细文章：安全的 GitOps 工作流：Secrets 管理实用指南

GitLab CI/CD Secrets 管理的安全最佳实践

实施最小权限访问

为什么这很重要： 安全漏洞通常会因权限过大而扩大。最小权限访问可以最小化你的攻击面，并限制潜在安全事件的影响。

关键考虑因素：

• 为不同的 pipeline 阶段创建细粒度的服务账户。
• 为管理任务使用临时提升的访问权限。
• 定期审计并撤销未使用的权限。
• 建立清晰的访问申请流程。

定期轮换 secrets

为什么这很重要： 静态 secrets 会随着时间推移因暴露和凭据共享而变得脆弱。定期轮换可以降低潜在泄露带来的影响。

关键考虑因素：

• 使用 OIDC 身份验证以消除长期凭据。
• 实施自动轮换

• 原文链接： infisical.com/blog/gitla...
• 登链社区 AI 助手，为大家转译优秀英文文章，如有翻译不通的地方，还请包涵～