2. 全局变量：在 GitLab Admin Area 设置实例级变量、适用场景、安全注意事项
全局变量（Instance-level CI/CD Variables）是 GitLab CI 变量分层治理体系中的最高层级。它们由 GitLab 实例管理员在 Admin Area 中统一配置，对所有项目、所有组、所有流水线全局生效。理解全局变量的设置路径、适用边界以及安全约束，是构建可靠变量治理体系的基石。
2.1 设置路径与操作步骤
全局变量的配置入口位于 GitLab 管理后台，仅实例管理员（Admin）可见。操作路径如下：
- 登录 GitLab 实例，点击左上角 ☰ 菜单 → Admin。
- 在左侧导航栏中选择 Settings → CI/CD。
- 展开 Variables 区域，点击 Add variable。
- 填写变量键（Key）、值（Value），并配置以下属性：
| 属性 | 说明 | 推荐值 |
|---|---|---|
| Key | 变量名称，大写字母、数字、下划线组成 | 如 GLOBAL_REGISTRY_URL |
| Value | 变量值，支持明文或掩码 | 根据实际配置 |
| Type | Variable（默认）或 File | 普通字符串选 Variable |
| Environment scope | 环境作用域，* 表示所有环境 | *（除非有特殊隔离需求） |
| Protect | 仅受保护分支可用 | 敏感变量建议勾选 |
| Mask | 在作业日志中隐藏变量值 | 符合掩码规则的变量建议勾选 |
操作提示： 全局变量一旦保存，所有项目的流水线都会立即继承。建议在添加前先在测试项目中验证变量名是否与项目级变量冲突，避免意外覆盖。
2.2 适用场景
全局变量最适合承载那些跨项目、跨组、不因业务逻辑变化而频繁修改的基础设施级配置。以下三类场景是全局变量的典型应用：
- 统一镜像仓库地址： 所有项目使用同一个内部 Harbor 或 Nexus 仓库，通过全局变量
CI_REGISTRY或GLOBAL_DOCKER_REGISTRY统一注入，避免每个项目重复配置。 - 全局代理与网络出口： 在受限网络环境中，所有构建作业需要通过统一的 HTTP/HTTPS 代理访问外网，全局变量
HTTP_PROXY、HTTPS_PROXY可一次性配置。 - 合规性证书与信任链： 企业内部 CA 证书、私有 GitLab Runner 的 TLS 证书等，通过全局 File 类型变量分发，确保所有作业的 SSL 验证行为一致。
场景对比： 全局变量 vs 组变量 vs 项目变量
| 层级 | 生效范围 | 典型用途 | 修改频率 |
|---|---|---|---|
| 全局 | 所有项目 | 基础设施配置、全局代理、统一证书 | 极低（季度/年度） |
| 组 | 组内所有项目 | 部门级密钥、共享数据库连接 | 低（月度） |
| 项目 | 单个项目 | 环境专属 、功能开关 | 高（按需） |
2.3 安全注意事项
全局变量拥有最大的传播范围，一旦泄露或配置不当，影响面将是全实例级别的。以下是必须遵守的安全红线：
- 最小权限原则： 只有实例管理员才能管理全局变量。任何非管理员人员不应拥有 Admin Area 的访问权限。定期审计管理员账号列表。
- 禁止存储个人凭据： 全局变量不应包含个人 API 、SSH 私钥等与具体人员绑定的凭据。应使用 Service Account 或机器人账号的凭据。
- 启用 Mask 与 Protect： 对于密码、、密钥等敏感值，务必勾选 Mask（确保值符合掩码格式要求：长度至少 8 位，且为 Base64 或纯字母数字组合）。同时勾选 Protect，限制仅在受保护分支（如 main、master）的流水线中暴露。
- 避免变量名冲突： 全局变量名应使用独特前缀（如
GLOBAL_、INSTANCE_），防止与 GitLab 预定义变量（如CI_JOB_）或项目级变量意外冲突，导致流水线行为异常。 - 定期轮换与审计： 建立全局变量轮换周期（建议最长 90 天）。通过 GitLab API 或 Audit Events 记录变量变更历史，确保任何修改可追溯。
高危操作警示： 切勿将数据库超级管理员密码、云服务商根账号 Access Key、或未加密的私钥设置为全局变量。一旦这些值被恶意用户通过作业日志、API 泄露或 Runner 日志获取，攻击者将获得整个实例的同等权限。建议使用 GitLab 外部的密钥管理服务（如 HashiCorp Vault、AWS Secrets Manager）配合 OIDC 认证，实现零信任变量分发。
2.4 全局变量治理检查清单
在将任何变量提升为全局变量之前，建议逐项核对以下清单：
| 检查项 | 通过标准 | 自检结果 |
|---|---|---|
| 必要性 | 该变量是否被 80% 以上的项目使用？ | □ 是 □ 否 |
| 不可变性 | 变量值是否至少一个季度内不会变化？ | □ 是 □ 否 |
| 敏感性 | 变量是否包含密码、 或密钥？ | □ 是（需 Mask+Protect） □ 否 |
| 命名合规 | 变量名是否以 GLOBAL_ 或 INSTANCE_ 开头？ |
□ 是 □ 否 |
| 轮换计划 | 是否已配置轮换提醒或自动化脚本？ | □ 是 □ 否 |
| 审计记录 | 是否已启用 Audit Events 并通知安全团队？ | □ 是 □ 否 |
最佳实践： 建议将全局变量数量控制在 10 个以内。过多的全局变量会增加治理复杂度和安全暴露面。每季度进行一次全局变量清理，移除不再使用的变量，合并重复用途的变量。