Repository navigation
Track external secret-manager integrations (1Password, Bitwarden, Vault, …) #168
Description
Loose tracking issue for external secret managers as candidate value-provider integrations once the v12 plugin SDK lands. Not a commitment to build any — a list to point at when people ask "can Fallout pull secrets from X?".
Background
ADR-0002 fixes the secret resolution chain:
CLI → env var → value-provider attribute → encrypted parameters file → CredentialStore → prompt
The third step is the integration point for external stores. One precedent in-tree:
AzureKeyVaultSecretAttributeatsrc/Fallout.Common/Tools/AzureKeyVault/— resolves[Parameter, Secret]values by fetching from a Key Vault at startup.
Anything fitting the same shape — a remote store reachable by API at build start, returning a string — can ride the same extension point. The v12 plugin SDK (milestone #7) is the natural delivery vehicle: each integration is one plugin, owned by whoever needs it, no upstream maintenance burden.
Candidate integrations (alphabetical, not prioritised)
| Tool | Why track it | Auth model | Notes |
|---|---|---|---|
| 1Password Connect / Service Accounts | Common in product/eng orgs; the maintainer's workplace uses it | Service-account token + Connect URL, or op CLI session |
CLI is lowest-friction; service-account API is CI-friendly |
| AWS Secrets Manager | Default for AWS stacks | IAM role / access keys | Mature SDK; trivial wrapper |
| Azure Key Vault | ✅ already exists | Managed identity / service principal | Reference implementation |
| Bitwarden Secrets Manager | Maintainer's preference; good for OSS / small teams | Access token + org ID | Distinct from the Password Manager — Secrets Manager is the CI-facing product |
| Doppler | Popular with smaller teams; nice DX | Service token | Single-binary CLI, simple REST API |
| GCP Secret Manager | Default for GCP stacks | Service-account JSON / workload identity | Symmetric with AWS / Azure |
| HashiCorp Vault | The "serious" enterprise option | AppRole / token / OIDC | Most complex auth; biggest payoff |
| Infisical | Open-source Doppler alternative; growing | Service token | Worth watching |
What the framework needs
Already in place:
- ✅
ValueInjectionAttributeBase— the base each provider attribute extends (cf.ParameterAttribute,AzureKeyVaultSecretAttribute). - ✅ Resolution chain documented in ADR-0002.
- ✅
[Secret]marker for log scrubbing (modulo the masking verification still open against the ADR review).
Plausibly needed:
- A small shared "secret value provider" base interface to cut boilerplate.
- Conventions for caching values within one build invocation (some stores are slow / rate-limited).
- A consistent error mode when a store is unreachable (fail-fast vs fall-through).
Scope
- In: keep the list current, accept suggestions, note community interest.
- Out: committing to any integration. Each gets its own issue + PR when someone builds it.
Closing condition: when ≥3 ship as v12 plugins and the pattern is proven. Until then, leave open.
Related
- ADR-0002 — Cross-provider auth and secret conventions
- v12 milestone — plugin SDK (delivery mechanism)
- Reference impl:
src/Fallout.Common/Tools/AzureKeyVault/
Activity