1. Guides
  2. Set up RestoreTrust
  3. Secrets
  4. Secrets overview
Website
  • Overview
  • Quickstart
  • How RestoreTrust works
  • Requirements
  • Organizations and projects
  • Project workers
  • Test schedules
    • File checks
  • Validation gates
  • Time zones and dates
  • Manual runs
  • Notifications
  • Check results
  • Execution logs
  • Reports
  • Evidence and verification
  • Team and roles
  • API keys
  • Billing and plans

Secrets overview

Register Kubernetes Secret metadata without sending credential or decryption values to RestoreTrust.

Loading documentation…

Project workers< PreviousSource credentialsNext >

Powered by heyo

On this page

Supported secret typesAdd secret metadata

RestoreTrust uses secret metadata to point a project worker to a Kubernetes Secret in your cluster.

You enter a display name, secret type, description, and Kubernetes Secret name in the console. You put the sensitive values and expected keys in the Kubernetes Secret in each selected worker's job namespace.

Supported secret types

PurposeSecret typeUsed for
Object storage credentialsS3 sourceS3-compatible sources
Username and passwordFTP, SFTP, or SMB sourceMatching network source
Archive passwordZIP passwordPassword-protected ZIP containers
Private identityage identityBackups encrypted to an age recipient
Passphraseage passphraseBackups encrypted with age passphrase mode

A source must use active source credential metadata of the same type. A schedule selects encryption metadata only when its artifact settings require it.

Add secret metadata

  1. 1

    Create the Kubernetes Secret

    In the project worker's job namespace, create a Kubernetes Secret with the required keys. Use a DNS-compatible Kubernetes object name.

  2. 2

    Register the metadata

    Open Secrets in the active project and choose Create. Select the correct type and enter the exact Kubernetes Secret name. Do not paste a credential or passphrase into description fields.

  3. 3

    Use it in a resource

    Select source credentials while creating a source, or select backup encryption credentials while configuring a schedule. If multiple workers can run that schedule, create an equivalent Kubernetes Secret in each worker's job namespace.

Metadata and values have separate lifecycles

A secret referenced by any source or schedule cannot be paused or deleted, even if that source or schedule is paused. Replace or remove those references first. Pausing or deleting unused metadata does not change or delete the Kubernetes Secret; rotate and remove cluster values through your normal Kubernetes secret-management process.

Use least-privilege source accounts and dedicated validation decryption material. Avoid sharing credentials between unrelated projects.

Related topics

  • Source credentials
  • Backup encryption
  • Project workers