The Keystore is a secure code repository provided by Cloud Native Build, specifically designed for storing sensitive information such as passwords, API keys, certificates, etc. It ensures the secure storage and compliant use of sensitive data through strict access control, page watermarks, audit trails, and other mechanisms.

Creating a Keystore

1. Access the Repository Creation Page
   Click here to create a Keystore (requires login).

2. Select Repository Type
   Choose Keystore as the repository type, and fill in the repository name and description.

   

   Create Keystore

3. Create
   Click the create button to create the Keystore.

Core Features of Keystore

1. Security Restrictions

Feature	Regular Repository	Keystore
Git Clone to Local	✅	❌
Local Code Push	✅	❌
Page File Editing	✅	✅
Create Branch/Tag/PR	✅	✅
Referenced by Pipelines	✅	✅

2. Enhanced Security Features

• Dynamic Watermark: Automatically adds a semi-transparent watermark of the current username to the page to prevent screenshot leaks.
• Reference Audit: Records all pipeline logs referencing files in this repository, supporting traceability.
• Enforced Page Operations: Only allows file editing via the web interface, prohibiting local operations.
• Strict Permission Control: Refer to Permission Description.
• Declarative Usage Scope: Refer to the pipeline file for Permission Check.

Referencing Keystore Files in Pipelines

Adding Files to Keystore

# env.yml
DOCKER_USER: "username"
DOCKER_TOKEN: "token"
DOCKER_REGISTRY: "https://xxx/xxx"

Importing as Environment Variables

In the pipeline configuration, reference the Keystore file via the imports field to automatically inject it as environment variables:

# .cnb.yml
main:
  push:
    - services:
        - docker
      imports:
        # Reference Keystore file
        - https://cnb.cool/<your-repo-slug>/-/blob/main/xxx/env.yml
      stages:
        - name: docker push
          script: |
            docker login -u ${DOCKER_USER} -p "${DOCKER_TOKEN}" ${CNB_DOCKER_REGISTRY}
            docker build -t ${DOCKER_REGISTRY}/${CNB_REPO_SLUG_LOWERCASE}:latest .
            docker push ${DOCKER_REGISTRY}/${CNB_REPO_SLUG_LOWERCASE}:latest

Pipeline Reference Authentication

By default, the keystore repository files can only be referenced by pipelines triggered by administrators or owners. For details, refer to Role Permissions.

If you want pipelines triggered by regular team members to also reference the keystore repository files, you can configure additional fields such as allow_slugs, allow_events, allow_branches, and allow_images to control the access scope.

In this case, the system will ignore whether the triggerer has permissions for the keystore repository and instead sequentially check the declared allow_* attributes. Only if all checks pass will the secrets be imported as environment variables. For more information, refer to the file reference Permission Check.

Best Practices

1. Classify and Store Sensitive Information

   • Split different Keystore Repositories by environment (prod/dev) or project.
   • Use yaml, json, or other file formats to manage secrets.
   • Create a new organization outside the business organization to manage Keystore Repositories, reducing the scope of members who can access them.

2. On-Demand Usage

   • Carefully allocate administrator and responsible roles.
   • Check pipeline configurations for misuse and leaking of key repository file contents.
   • Properly configure key repository files with allow_* properties. For example:
     • Configure allow_slugs to be referenced only by specified range of repository pipelines.
     • Configure allow_events to be referenced only by Tag-related event pipelines.
     • Configure allow_branches for specific protected branches that require PR approval.
     • Specify or create plugins for release and deployment, configuring allow_images to be referenced only by these plugins.

3. Regularly Rotate Secrets
   After updating secrets via the page editing feature, all pipelines referencing this file will automatically retrieve the new values.

4. Audit and Review
   Check audit logs, clean up invalid references, and revoke permissions for departed members.