mrcharles
b43bc55963
Introduce the single Backend interface every credential source implements.
v0 ships two working backends: file (0600 KEY=VALUE env files, parsed in
pure Go, never sourced; looser permission masks refused before read) and
env (process-environment indirection). Bitwarden Secrets Manager and
HashiCorp Vault ship as explicit not-implemented stubs behind the same
interface so the phase-3 connectors are drop-ins. All failures are typed
ResolveErrors carrying only the ref, backend, and a fixed reason enum —
never material.
💘 Generated with Crush
Assisted-by: Crush:glm-5.2
mopac-keyproxy
A key-material proxy where the vault stays authoritative. Consumers receive opaque placeholder keys; real secrets live only in Bitwarden Secrets Manager and/or HashiCorp Vault and are resolved to real material at the wire, in memory, never persisted, with no admin UI to attack.
Status: 2026-08-28 — spec seed; design frozen, no code yet.
Scope
- Placeholders in, real keys on the wire out: consumers (harness, CLIs,
containers) hold
mpk_...opaque refs only. A leaked placeholder is revoke-and-remap, not an incident — zero upstream exposure. - Backends: Bitwarden Secrets Manager REST (machine accounts) and HashiCorp Vault KV v2 + AppRole (official Go api pkg is MPL-2.0, vendored). Stdlib-first; NO official Bitwarden SDK (its source-available license is AGPL-incompatible).
- Two shapes, one resolver: an HTTP hop for services, and a CLI
(
keyproxy get <ref>) for exec-style plumbing. - Memory-only material handling: fetch-on-demand, short TTL, never persisted, never written to logs; ref redaction everywhere.
- Config-driven: generic, no organizational hosts/paths/defaults baked into code.
Non-goals
- No admin UI — there is no admin surface at all; configuration only.
- Not a secrets manager: the vault stays authoritative; keyproxy never becomes a second place secrets live.
- No persistence of key material to disk, cache files, or crash dumps.
- Not org-specific: TSYS policy lives outside this repo (loose-coupling rules for the MOPAC tool family).
Today vs planned
| State | |
|---|---|
| Today | Spec only (this README + LICENSE). Design carried in the MOPAC harness DESIGN.md "Key proxy" section. |
| Planned | Go implementation: placeholder->material resolver, Bitwarden Secrets Manager + Vault connectors, HTTP hop + get CLI, ref-redaction rules. |
Design references
- MOPAC harness DESIGN.md — Key proxy: placeholders only, material never leaves the vault
- MOPAC harness DESIGN.md — Tooling = standalone public FLOSS repos
- Exposure-minimization protocol (crush porting notes)
- Sibling: mopac-bitwarden-go — how material gets INTO the vault
- Parent: ukrrs/MOPAC — the harness this serves
License
AGPLv3 — see LICENSE. (MIT fallback only if a license conflict still arises; none known today.)