Vault Operations Patterns

HashiCorp Vault patterns I’ve actually used. Every entry has a date and context.

2026-04-03: Vault PKI Issue + jq Extract Pipeline

Problem: Need a repeatable workflow for issuing Vault PKI certificates and extracting components without manual JSON editing.

Context: P16g EAP-TLS deployment, issuing from Razer (Vault access) for P16g (no direct Vault path).

The Fix:

# Load Vault credentials
ds d000 dev/vault

# Issue cert — tee preserves full JSON, jq extracts summary
HOSTNAME="modestus-p16g"
vault write -format=json pki_int/issue/domus-client \
    common_name="${HOSTNAME}.inside.domusdigitalis.dev" \
    ttl=8760h \
    | tee /tmp/${HOSTNAME}-vault-cert.json \
    | jq '{common_name: .data.common_name, serial: .data.serial_number, expiration: .data.expiration}' \
    > /tmp/${HOSTNAME}-vault-summary.json

# View summary (doesn't expose private key)
cat /tmp/${HOSTNAME}-vault-summary.json | jq .

Rule: Always use -format=json and tee to a temp file. The summary jq filter gives you what you need for verification without exposing the private key in scrollback.

Worklog: WRKLOG-2026-04-03

2026-04-02: Vault SSH Certificate Signing (Blocked by VLAN Segmentation)

Problem: Vault SSH cert signing for machine-to-machine auth failed — workstation can’t reach Vault across VLANs.

Context: P16g on DOMUS-Secure VLAN, Vault on management VLAN. Anti-pivot firewall rules block cross-VLAN access to Vault port by design.

The Pattern:

# Generate a dedicated keypair on the new machine
ssh-keygen -t ed25519 -f ~/.ssh/id_ed25519_vault -C "vault-signed@modestus-p16g"

# Copy public key to a machine WITH Vault access (Razer)
scp -F /dev/null -i ~/.ssh/id_ed25519_d000 \
    evanusmodestus@10.50.10.126:~/.ssh/id_ed25519_vault.pub /tmp/p16g-vault.pub

# Sign it from the Razer (8h TTL)
vault write -field=signed_key ssh/sign/domus-client \
    public_key=@/tmp/p16g-vault.pub \
    valid_principals="evanusmodestus,admin,root" \
    >| /tmp/p16g-vault-cert.pub

# Send signed cert back to the P16g
scp -F /dev/null -i ~/.ssh/id_ed25519_d000 \
    /tmp/p16g-vault-cert.pub evanusmodestus@10.50.10.126:~/.ssh/id_ed25519_vault-cert.pub

# Verify the certificate on the P16g
ssh-keygen -L -f ~/.ssh/id_ed25519_vault-cert.pub

Vault SSH certs require a network path between client and Vault. VLAN segmentation blocks this by design. Two options:

Explicit firewall rule for Vault port from the new VLAN
Proxy signing — copy pub key to a machine with Vault access, sign there, copy cert back

Rule: VLAN segmentation may block Vault access. Plan firewall rules for Vault port when deploying to new VLANs. Each machine MUST have its own keypair — never share private keys across machines.

Worklog: WRKLOG-2026-04-02

2026-04-02: Vault SSH Certificate TTL and Renewal

Problem: Vault SSH certificates have an 8-hour TTL — need to re-sign daily.

Context: P16g deployment, Vault SSH cert-based auth to infrastructure hosts.

The Pattern:

# Re-sign daily (from a machine with Vault access)
ds d000 dev/vault

vault write -field=signed_key ssh/sign/domus-client \
    public_key=@/tmp/p16g-vault.pub \
    valid_principals="evanusmodestus,admin,root" \
    >| /tmp/p16g-vault-cert.pub

# Target hosts must have TrustedUserCAKeys configured
# /etc/ssh/sshd_config:
#   TrustedUserCAKeys /etc/ssh/trusted-user-ca-keys.pub

Rule: Vault SSH certs are short-lived by design. Without TrustedUserCAKeys on the target host, cert auth is silently ignored and falls back to key-based auth. Automate renewal with a cron job or script.

Worklog: WRKLOG-2026-04-02