Privileged access: vault-held credentials

Technicians can elevate on a device without ever seeing the password. They either type a credential, which the browser seals to the device, or name one held in a vault. For a vault credential, the server reads it, seals it to the device's per-session key at once, and forgets it. Only the account, action and outcome are audited.

A reference is <provider>:<name>. Every provider confines each tenant to its own area of the vault through a template that must contain {tenant}, the tenant's id. Names may only contain letters, digits and _ . - /, with no empty or .. segments, so a reference cannot reach another tenant's credentials. Configuration is checked at startup: providers must use https outside dev/test, and templates without {tenant} are refused.

Provider	Reference	Tenant area	Authentication
HashiCorp Vault / OpenBao (`vault`)	`vault:servers/admin`	`<vault_mount>/data/<vault_prefix>/{tenant}/…`; KV v2 with `username` and `password`	`vault_token`
CyberArk Central Credential Provider (`cyberark`)	`cyberark:srv-admin` (object)	the safe named by `safe_template`, e.g. `YARMA-{tenant}`	client certificate (`client_cert_file`, `client_key_file`, optional `ca_file`) and `app_id`
Delinea Secret Server (`delinea`)	`delinea:servers/admin`	folder `folder_template`, e.g. `\YARMA\{tenant}`, plus subfolders; fields `username` and `password`	application account (OAuth password grant)
BeyondTrust Password Safe (`beyondtrust`)	`beyondtrust:dc01/administrator` (system/account)	managed system named by `system_template`, e.g. `{tenant}-{system}`; checked out for `duration_minutes` (default 5) and checked in straight away	API registration key and `run_as` user
Azure Key Vault (`azure`)	`azure:servers/admin`	secret named by `name_template`, e.g. `yarma-{tenant}-{name}` (`/ . _` become `-`); value is the password, tag `username` the account	Entra app registration (client credentials)

pam:
  cyberark:
    url: https://ccp.example.com
    app_id: YARMA
    safe_template: "YARMA-{tenant}"
    client_cert_file: /etc/yarma/cyberark-client.crt
    client_key_file: /etc/yarma/cyberark-client.key
    ca_file: /etc/yarma/cyberark-ca.crt
  delinea:
    url: https://secretserver.example.com/SecretServer
    username: yarma-app
    password: ""            # YARMA_PAM_DELINEA_PASSWORD
    folder_template: '\YARMA\{tenant}'
  beyondtrust:
    url: https://pws.example.com
    api_key: ""             # YARMA_PAM_BEYONDTRUST_API_KEY
    run_as: svc-yarma
    system_template: "{tenant}-{system}"
  azure_key_vault:
    vault_url: https://contoso.vault.azure.net
    tenant_id: 00000000-0000-0000-0000-000000000000
    client_id: 00000000-0000-0000-0000-000000000000
    client_secret: ""       # YARMA_PAM_AZURE_KEY_VAULT_CLIENT_SECRET
    name_template: "yarma-{tenant}-{name}"

Give the YARMA identity read access only to the tenant areas above, and nothing else. A missing or forbidden credential is reported as "credential unavailable". Errors from the vault itself (5xx, throttling) are reported separately, so outages can be told apart from access problems.

Documentation for Yarma 0.1.0-alpha.4. Something unclear? .