# Secret providers

Connect Vault, Infisical, AWS Secrets Manager or GCP Secret Manager, and Opafra resolves references against your own store.

Source: https://opafra.com/docs/access/secret-providers

---

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

1. Open **Inventory**, then **Secrets**, then **Vault**
2. Choose the provider and supply its connection details
3. Save, and Opafra verifies the connection before storing it
4. Reference secrets as `secret://<provider>/<namespace>/<key>`

The credential you give Opafra is stored encrypted and never returned by the API.

> **Important**
>
> Only the non-sensitive part of a connection is readable afterwards: the address and mount
> path for Vault, the region for AWS, the project for GCP, and whether static credentials
> are in use. The token, key or client secret itself cannot be read back, by you or by
> anyone else.

## 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](/docs/inventory/environments). 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](/docs/access/secret-references) for the reference model itself
- [SSH credentials](/docs/access/ssh-credentials) for keys, which follow the same rules