secrets-and-pki: add real Vault evidence, expand access model
Access model now covers the narrowly-scoped read-only utility policies (ansible sync roles, metrics-reader, pki-reader) alongside the host-scoped svc-* pattern - the fuller picture confirmed live against Vault's actual ACL policy list, not just the original narrower claim. Added two real screenshots: the live policy list, and an actual audit log entry showing a KV read with every secret value as hmac-sha256:... instead of plaintext - proof for the audit-trail claim instead of just an assertion of it.
This commit is contained in:
3 files changed
+8
No files matched your search
Binary file not shown.
|
After Width: | Height: | Size: 85 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 72 KiB |
@@ -85,5 +85,13 @@ Ranking these mattered more than just listing them: a reader (or an attacker) ne
|
|||||||
|
|
||||||
One policy per host, scoped to exactly what that host needs — no host's credentials can read another host's secrets. Every host-scoped policy follows the same shape: a shared grant for lightweight self-registration, plus a private grant with full read/write access only to that host's own namespace. Onboarding a new host copies this shape rather than reinventing it — and the shared grant does *not* automatically imply the private one, so both get verified before assuming a host is fully provisioned. This same "shared + private" pattern shows up again in [`docs/iac-pipeline.md`](iac-pipeline.md)'s tag-driven Ansible model — a deliberate consistency, not a coincidence.
|
One policy per host, scoped to exactly what that host needs — no host's credentials can read another host's secrets. Every host-scoped policy follows the same shape: a shared grant for lightweight self-registration, plus a private grant with full read/write access only to that host's own namespace. Onboarding a new host copies this shape rather than reinventing it — and the shared grant does *not* automatically imply the private one, so both get verified before assuming a host is fully provisioned. This same "shared + private" pattern shows up again in [`docs/iac-pipeline.md`](iac-pipeline.md)'s tag-driven Ansible model — a deliberate consistency, not a coincidence.
|
||||||
|
|
||||||
|
Beyond the host-scoped policies, a handful of narrowly-scoped read-only policies exist for specific, single-purpose needs — an Ansible role reading one sync secret at playbook-run time, Prometheus/Alloy reading Vault's own metrics endpoint, an auditor listing issued certificates across both PKI mounts. Each one grants exactly one path and nothing else — the same least-privilege instinct as the host policies, applied at a finer grain.
|
||||||
|
|
||||||
|

|
||||||
|
|
||||||
|
That "HMAC-hashed, not plaintext" claim in the table above isn't just a description — it's what a real audit log entry actually looks like:
|
||||||
|
|
||||||
|

|
||||||
|
|
||||||
---
|
---
|
||||||
Related: [`docs/secret-distribution.md`](secret-distribution.md), [`docs/firewall-and-network.md`](firewall-and-network.md) · Stacks: [`stacks/identity-and-security/vaultwarden/`](../stacks/identity-and-security/vaultwarden/)
|
Related: [`docs/secret-distribution.md`](secret-distribution.md), [`docs/firewall-and-network.md`](firewall-and-network.md) · Stacks: [`stacks/identity-and-security/vaultwarden/`](../stacks/identity-and-security/vaultwarden/)
|
||||||
Reference in new issue
Block a user