Docs

Secrets Manager

The secrets manager resolves secret references when a policy is applied, so credentials live in your secret store rather than in agent.yaml. A policy writes a reference where the value would go:

scope:
  - driver: ios
    hostname: 192.0.2.10
    username: admin
    password: "${vault://secret/devices/password}"

One provider is active at a time, selected by orb.secrets_manager.active, and configured under sources:

orb:
  secrets_manager:
    active: vault
    sources:
      vault:
        address: "https://vault.example.com:8200"
ProvideractiveReference form
HashiCorp Vaultvault${vault://<mount>/<path>/<key>}
Dopplerdoppler${doppler://<project>/<config>/<secret>}
CyberArk (CCP)cyberark${cyberark://<Safe>/<Object>/<Field>}
Delinea Secret Serverdelinea${delinea://path/<folder>/<name>/<field>}
Delinea DevOps Secrets Vault (DSV)dsv${dsv://<secret-path>/<field-key>}

Each provider's page documents its own reference forms in full, since most accept more than one.

Leaving active unset or empty skips the secrets manager and the agent starts normally. A value that is set but not recognised fails startup with an error naming the supported types.

The provider and its settings can also be chosen entirely from the environment, without editing the YAML, which suits injecting them at deploy time. See Environment-Driven Configuration.

Rotation

Every provider takes an optional schedule, a cron expression for re-fetching secrets that have already been resolved. When a referenced value changes, the policies that used it are re-applied with the new value, so credentials can be rotated without restarting the agent. Each provider's page covers what happens when a re-fetch fails.

On this page