Connecting a provider lets plans resolve secret:// references against the secret store
your team already runs, instead of holding credentials in Opafra.
Before you begin#
You need the Operator role or above, and a credential for the provider that can read the paths Opafra needs. Read access is enough: Opafra never writes to your store.
1. Open the vault#
Open Inventory, choose Secrets, then Vault. Connected providers appear first, with the catalogue of connectable ones beneath.
2. Choose the provider and enter its connection#
Select the provider and fill in its fields. Only these are required:
HashiCorp Vault
Address https://vault.example.com
Token hvs.CAESIJ...
Mount path secretInfisical
Site URL https://app.infisical.com
Auth method universal_auth
Client ID 7f2a...
Client secret ...
Project ID b41c...
Environment prod
Secret path /AWS Secrets Manager
Region eu-west-1GCP Secret Manager
Project ID acme-prod3. Save#
Opafra verifies the connection before storing it. A credential that cannot read is rejected at this point rather than at the first run that needs it.
Verify it worked#
The provider moves into the connected list, showing only its non-sensitive metadata:
HashiCorp Vault connected https://vault.example.com mount: secret
Internal Vault built-inThe token itself is never shown again, by you or anyone else.
Then prove a reference resolves end to end. Add a step to any plan and dry run it:
- name: Check the reference resolves
tool: ssh.cmd
args:
command: "test -n 'secret://hashivault/prod/api_key' && echo resolved"Step 1 Check the reference resolves ssh.cmd
web-01 will run (not simulated)
test -n 'secret://[redacted]' && echo resolvedsecret://[redacted] is the proof. The reference was recognised and masked. A reference
that failed to resolve appears unredacted and unchanged, because Opafra never matched it.
Next steps#
- Secret references for the reference model
- Secret providers for per-provider detail and rotation