Vault — alert when a mount/secret engine disappeared
Someone ran `vault secrets disable` (debug or drift) — the pipeline reaches for DB creds and gets 404. Vault does not warn — for it this is a "normal admin action".
Recipe
#!/usr/bin/env bash
# /etc/cron.d/vault-mount
# */15 * * * * root /opt/vault-mount.sh
export VAULT_ADDR=${VAULT_ADDR}
export VAULT_TOKEN=${VAULT_TOKEN}
# Comma-separated list of expected mount paths
EXPECTED=${EXPECTED:-database/,kv/,pki/}
LIVE=$(vault secrets list -format=json | jq -r 'keys[]')
MISSING=""
IFS=',' read -ra MOUNTS <<< "$EXPECTED"
for M in "${MOUNTS[@]}"; do
if ! echo "$LIVE" | grep -qx "$M"; then
MISSING="$MISSING$M,"
fi
done
if [ -n "$MISSING" ]; then
curl -fsS "$HEARTBEAT_URL" --data-urlencode "missing_mounts=$MISSING"
exit 2
fi
echo "OK (all expected mounts present)"Same thing in Enterno.io
Wrap in an Enterno heartbeat — learn about Vault config drift before it breaks a prod pipeline.
Related recipes
A service VAULT_TOKEN is close to expiry (no auto-renewal, or non-renewable=true). The service hits Vault — and one day it gets 403 and loses access to its secrets.
Compliance mandates rotating DB credentials every 90 days. Vault static-creds engine should do it, but someone set max_ttl=0 — the secret lives forever. The auditor finds it first.
Compliance mandates rotating k8s Secrets (DB passwords, API tokens) every 90 days. Nobody auto-rotates, Secrets live since cluster creation. The auditor finds it first.