thesabear/public
1
0 Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

fix: redact live identity/CA specifics from today's SSH-CA command output

Browse Source 
Two command-block "evidence" snippets added earlier today pasted real,
live-captured values verbatim: the exact cert file path, the fleet's
actual CA fingerprint, today's real issuance timestamp, and the live
Vault role/principal name. All of it identified real infrastructure
in a way the rest of this repo's established redaction convention
(see docs/firewall-and-network.md's [admin workstation]-style
placeholders) already exists specifically to avoid. Redacted to
bracket placeholders; the structural/format evidence (cert type,
extensions, TTLs) stays genuine.
This commit is contained in:
automation-bot committed 2026-09-05 09:46:39 +03:00
1 parent ff3ca1d8f1
commit 2c865f90f0
2 files changed
+11 -11
Download Patch File Download Diff File Expand all files Collapse all files

No files matched your search

docs/secret-distribution.md
+7 -7
View File
@@ -27,23 +27,23 @@ The obvious simpler design is one universal "secret goes in, secret comes out" p
| | |
|---|---|
| **Law** | The automation identity never holds a static, standing-access SSH key. Only a Vault-signed certificate, valid for hours, ever grants it access to a fleet host. |
| **Flow** | Its own systemd timer (2h interval) → reuses Vault Agent's already-authenticated token → `vault write ssh-client-signer/sign/sign-ansible` → certificate installed next to the identity's own key on the one host that needs it → every fleet host's sshd trusts the CA directly, no per-host secret involved |
| **Flow** | Its own systemd timer (2h interval) → reuses Vault Agent's already-authenticated token → `vault write ssh-client-signer/sign/[role name]` → certificate installed next to the identity's own key on the one host that needs it → every fleet host's sshd trusts the CA directly, no per-host secret involved |
| **Failure behavior** | A single missed refresh is harmless — the timer fires every 2 hours against a 6-hour certificate, so there's hours of margin. A sustained outage spanning several missed cycles eventually locks the automation identity out of certificate-based SSH entirely, with no static key to fall back to — an accepted tradeoff, not an oversight (see [`docs/secrets-and-pki.md`](secrets-and-pki.md)) |
This is the real signed certificate, not a description of one — installed and ready to use, principal and validity window both visible:
This is the real shape of a signed certificate from this flow, not a description of one — host path, CA fingerprint, and validity window redacted since they identify live infrastructure, everything else genuine:
```
$ ssh-keygen -Lf /home/ansible/.ssh/auto-cert.pub
$ ssh-keygen -Lf [cert path]
Type: [email protected] user certificate
Signing CA: RSA SHA256:vcGM3I3hc5AYm9ji1lXYBx1yhVuxR3Gj/3CFdRRkjOo (using rsa-sha2-512)
Valid: from 2026-09-05T08:55:53 to 2026-09-05T14:56:23
Signing CA: RSA SHA256:[fleet's CA fingerprint] (using rsa-sha2-512)
Valid: from [issued] to [issued + 6h]
Principals:
ansible
[automation identity]
Extensions:
permit-port-forwarding
```
**Invariants:** exactly one identity (`ansible`) is ever signed for. Vault's role config enforces this independently of the script that calls it — a compromised or buggy script still can't get a certificate for any other principal. Every host trusts the CA's public key directly; none of them store the automation identity's actual key material at all.
**Invariants:** exactly one identity is ever signed for. Vault's role config enforces this independently of the script that calls it — a compromised or buggy script still can't get a certificate for any other principal. Every host trusts the CA's public key directly; none of them store the automation identity's actual key material at all.
## 3️⃣ Application Secret Flow