密钥仓库是云原生构建提供的高安全等级仓库，专用于存储和管理敏感信息（如密码、API 密钥、证书、令牌等），通过严格的访问控制、操作限制、审计日志与水印等多重安全机制确保安全。

创建密钥仓库

1. 进入创建页面 登录账号后,点击此处进入仓库创建页面。

2. 选择仓库类型并填写信息 在仓库类型中选择 密钥仓库,填写仓库名称与描述。

   

   创建密钥仓库

3. 完成创建 点击创建按钮即可完成。

核心特性

1. 操作限制

密钥仓库相比普通仓库有严格的操作限制：

能力	普通仓库	密钥仓库	说明
Git Clone 到本地	✅	❌	禁止将敏感数据下载到本地环境
本地推送代码	✅	❌	禁止从本地推送更改，防止引入风险
Web 界面编辑文件	✅	✅	所有更改必须通过受审计的 Web 界面进行
创建分支/Tag/PR	✅	✅	支持在受控范围内进行代码管理
被流水线引用	✅	✅	核心功能，支持在流水线中安全使用密钥

2. 安全增强机制

• 动态水印: 所有页面自动添加当前用户名的半透明水印，防止截图泄露并支持追溯。
• 完整的审计日志: 记录所有文件引用记录（何时、被哪条流水线引用），支持全链路溯源。
• 强制 Web 端操作: 仅支持在平台 Web 界面编辑文件，杜绝本地环境泄露风险。
• 严格的权限控制: 遵循系统统一的角色权限模型，精细化管控访问权限。
• 声明式访问范围: 可通过配置精确控制密钥文件的被引用条件，详见权限检查。

在流水线中引用

1. 存储密钥文件

在密钥仓库中,通常使用 YAML 或 JSON 文件来结构化存储密钥。

# env.prod.yml
# 生产环境密钥
DOCKER_USER: "prod_username"
DOCKER_TOKEN: "prod_token_123456"
DOCKER_REGISTRY: "registry.prod.com"

# env.dev.yml
# 开发测试环境密钥
DOCKER_USER: "dev_username"
DOCKER_TOKEN: "dev_token_123456"
DOCKER_REGISTRY: "registry.dev.com"

2. 注入为环境变量

在流水线配置 (.cnb.yml) 中，通过 imports 引用密钥仓库中的文件，将其内容自动注入为环境变量。

.cnb.yml

main:
  push:
    - services:
        - docker
      imports:
        # 引用密钥仓库中的特定文件
        - https://cnb.cool/<your-repo-slug>/-/blob/main/env.prod.yml
      stages:
        - name: 构建并推送镜像
          script: |
            # 注入的环境变量可直接在脚本中使用
            echo "登录到镜像仓库..."
            docker login -u $DOCKER_USER -p "$DOCKER_TOKEN" $DOCKER_REGISTRY
            echo "构建镜像..."
            docker build -t $DOCKER_REGISTRY/$CNB_REPO_SLUG_LOWERCASE:latest .
            echo "推送镜像..."
            docker push $DOCKER_REGISTRY/$CNB_REPO_SLUG_LOWERCASE:latest

3. 引用鉴权与范围控制

默认情况下，只有密钥仓库的管理员和负责人成员触发的流水线才有权引用该仓库中的文件。

若需允许更广泛成员触发的流水线引用，必须在密钥文件中声明 allow_* 字段进行精细化授权：

• allow_slugs: 限制只有特定仓库的流水线可以引用。

• allow_events: 限制只有特定事件(如 tag_push)触发的流水线可以引用。

• allow_branches: 限制只有特定分支(如 main, prod)的流水线可以引用。

• allow_images: 限制只有特定镜像的插件任务可以引用。

  注意：一旦配置了 allow_* 规则，系统将忽略触发者的角色权限，完全依据规则校验。所有规则均需通过才允许引用。

  详情请参阅权限检查。

4. 防范流水线内泄漏

密钥仓库本身是安全的，但密钥注入流水线后仍需警惕脚本中的泄漏风险（如误将环境变量打印到日志中）。

防护建议:

1. 保护流水线配置: 将包含 imports 的流水线配置存放在独立的、权限受控的仓库中，通过 include 方式提供给其他仓库使用，限制修改人员范围。
2. 使用保护分支: 结合 allow_branches 规则限制为保护分支使用。对保护分支的修改需通过 Pull Request 进行代码评审，增加人工审计关卡。
3. 审计与日志监控: 定期检查流水线日志,关注异常行为。

最佳实践

1. 分离与分类

   • 环境分离: 为生产、预发布、开发测试等环境分别创建不同的密钥仓库或文件。
   • 项目分离: 不同项目使用独立的密钥仓库，隔离权限和影响范围。
   • 集中管理: 在独立组织中统一管理密钥仓库，严格限制访问权限。

2. 最小权限原则

   • 角色控制: 审慎分配密钥仓库的「管理员」和「负责人」角色，按需授权。
   • 范围控制: 使用 allow_* 配置为每个密钥文件声明最小化允许范围。
     • allow_slugs: 限定只能被哪些项目引用。
     • allow_events: 限定只能由部署事件 (tag_push、tag_deploy.*) 触发,而非每次代码推送都触发。
     • allow_branches: 限定只能在稳定的保护分支上使用。

3. 降低配置泄露风险

   • 将包含敏感引用的流水线逻辑封装在受控的公共配置库中，通过 include 提供给其他项目使用，将风险控制点收敛到少数仓库。

4. 定期轮换与审计

   • 密钥轮换: 建立定期轮换机制，在密钥仓库 Web 界面更新文件内容即可，所有引用此文件的流水线将自动获取新值。
   • 权限审计: 定期审查审计日志，清理无效引用和授权规则，撤销离职或转岗成员的访问权限。

上一页产品介绍

下一页元数据