Skip to main content
Secret providers allow the Maverics Orchestrator to retrieve sensitive values — such as API keys, certificates, and database credentials — from external secret management systems at runtime. This keeps secrets out of configuration files and ensures they are managed according to your organization’s security policies.
Console terminology: In the Maverics Console, Orchestrator instances and configuration delivery are managed through Deployments. When working directly with YAML, configuration is managed as files delivered via the -config flag or MAVERICS_CONFIG environment variable.

​
How Secret Providers Work

Secret providers are configured via the MAVERICS_SECRET_PROVIDER environment variable or the -secretProvider CLI flag — not in YAML configuration. Only one secret provider may be active at a time. 
# Configure via environment variable
export MAVERICS_SECRET_PROVIDER="hashivault://vault.example.com:8200/secret/data/maverics?token=<token>"

# Or via CLI flag
maverics -config maverics.yaml -secretProvider "hashivault://vault.example.com:8200/secret/data/maverics?token=<token>"
Once a secret provider is configured, you reference secrets in your YAML configuration using angle bracket syntax: 
connectors:
  - name: my-idp
    oauthClientSecret: <maverics.client_secret>
At startup (and on config reloads), the Orchestrator resolves <maverics.client_secret> by fetching it from the configured secret provider. The namespace (maverics) and key (client_secret) map to the secret path and key in the provider.

​
Using Secret References in the Console

The same angle bracket syntax works in the Maverics Console. When configuring connectors, apps, or other resources in the Console, use secret references (e.g., <maverics.client_secret>) in any field that accepts a sensitive value. The Orchestrator resolves them at runtime just as it does with YAML.
Never enter actual secret values into the Console. Always use secret provider references instead. Configuration entered in the Console is stored as a deployment config — secret references ensure that sensitive values remain in your secret management system and are never persisted in the configuration itself.
This applies even during testing. While you could enter plaintext values for local testing against non-production resources, we recommend using secret references from the start to build good habits. The Secret File provider makes this easy — point the Orchestrator at a local YAML file and reference those secrets in the Console the same way you would in production.

​
Available Providers

ProviderURL SchemeUse Case
AWS Secrets Managerawssecretsmanager://AWS-native secret storage
Azure Key Vaultazurekeyvault://Azure-native secret and certificate management
CyberArk CCPcyberarkccp://CyberArk Central Credential Provider
CyberArk Conjurconjur://DevOps-oriented secrets for CI/CD and containers
Delinea Secret Serverdelinea://Enterprise privileged access management
HashiCorp Vaulthashivault://Enterprise secret management with dynamic secrets
Secret Filesecretfile://Local file-based secrets for testing

​
Provider Pages

AWS Secrets Manager

AWS-native secret storage

Azure Key Vault

Azure-native secret and certificate management

CyberArk CCP

CyberArk Central Credential Provider

CyberArk Conjur

DevOps-oriented secrets for CI/CD and containers

Delinea Secret Server

Enterprise privileged access management

HashiCorp Vault

Enterprise secret management with dynamic secrets

Secret File

Local file-based secrets for testing

Identity Fabric

Identity provider integrations

Config Sources

Where the Orchestrator reads its configuration