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. Use on Demand

   • Assign administrator and owner roles with caution.
   • Check pipeline configurations for any misuse or leakage of keystore repository file contents.
   • Properly configure the allow_* attributes for keystore repository files. For example:
     • Configure allow_events to only allow pipelines triggered by Tag-related events to reference them.
     • Configure allow_branches to specific protected branches, ensuring PRs must undergo review.
     • Configure allow_slugs to designated repositories, allowing other repositories to use sensitive information by triggering pipelines in the specified repository.
     • Designate or create plugins for publishing or deployment, and configure allow_images to only allow these plugins to reference them.

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.