Opafra resolves secret:// references against a provider you connect. Four external
providers are supported, and an internal store is available when you do not have one.
Connecting a provider is the same shape every time: give Opafra a way to authenticate, tell it where secrets live, and reference them from plans.
The procedure#
- Open Inventory, then Secrets, then Vault
- Choose the provider and supply its connection details
- Save, and Opafra verifies the connection before storing it
- Reference secrets as
secret://<provider>/<namespace>/<key>
The credential you give Opafra is stored encrypted and never returned by the API.
HashiCorp Vault#
| Field | Notes |
|---|---|
| Address | The Vault server URL |
| Token | The token Opafra authenticates with |
| Mount path | Defaults to secret |
Give the token a policy scoped to the paths Opafra needs to read, rather than a root token. Opafra reads secrets; it does not need write capability for reference resolution.
Infisical#
| Field | Notes |
|---|---|
| Site URL | Defaults to https://app.infisical.com |
| Auth method | Service token, or universal auth |
| Project and environment | Which project and which of its environments to read |
| Secret path | Defaults to / |
Universal auth takes a client id and client secret; the service-token method takes a single token. Prefer universal auth where you have the choice, because the credential can be rotated without editing the connection.
Note that Infisical has its own notion of environment, and it is independent of an Opafra environment. One connection points at one Infisical environment.
AWS Secrets Manager#
| Field | Notes |
|---|---|
| Region | Required |
| Access key and secret | Optional |
| Session token | Optional |
Credentials are optional on purpose. Leave them empty and Opafra uses the ambient AWS credentials of the environment it runs in, which is the better option when Opafra runs on AWS: an instance role rotates on its own and there is no long-lived key to leak.
GCP Secret Manager#
| Field | Notes |
|---|---|
| Project ID | Required |
| Credentials JSON | Optional, a service account key |
As with AWS, leaving the credentials empty uses the ambient service account. Prefer that where Opafra runs on GCP.
The internal store#
When no external provider is connected, Opafra can hold secrets itself, encrypted at rest. It exists so a team without a secret manager is not forced to paste passwords into plans, which is the outcome it prevents.
It is a starting point rather than a destination. An external provider gives you rotation, audit, and access policy that Opafra deliberately does not try to reimplement. Connect one when you have one.
Choosing a provider#
If your team already runs a secret manager, connect that one. The point of provider support is that Opafra reads from where your secrets already are, rather than becoming a second place they live.
If you run on AWS or GCP and have no dedicated manager, their native service plus ambient credentials is the least moving parts. If you run Vault, use Vault.
Rotation#
Rotating a secret in your provider takes effect on the next run that resolves the reference. Plans do not need editing, because the plan names the reference and never the value.
This is the practical payoff of references: rotation is an operation on your secret store alone, not a change that ripples through automation.
Next steps#
- Secret references for the reference model itself
- SSH credentials for keys, which follow the same rules