Vault — alert when a secret has not rotated in N days
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.
Recipe
#!/usr/bin/env bash
# /etc/cron.d/vault-rotation
# 0 6 * * * root /opt/vault-rotation.sh
export VAULT_ADDR=${VAULT_ADDR}
export VAULT_TOKEN=${VAULT_TOKEN}
PATHS=${PATHS:-database/static-creds/app1,database/static-creds/app2}
MAX_DAYS=${MAX_DAYS:-90}
NOW=$(date +%s)
STALE=""
IFS=',' read -ra LIST <<< "$PATHS"
for P in "${LIST[@]}"; do
TS=$(vault read -format=json "$P" 2>/dev/null \
| jq -r '.data.last_vault_rotation // ""')
[ -z "$TS" ] && continue
EPOCH=$(date -d "$TS" +%s 2>/dev/null || echo 0)
DAYS=$(( (NOW - EPOCH) / 86400 ))
if [ "$DAYS" -gt "$MAX_DAYS" ]; then
STALE="$STALE$P=${DAYS}d,"
fi
done
if [ -n "$STALE" ]; then
curl -fsS "$HEARTBEAT_URL" --data-urlencode "stale_secrets=$STALE"
exit 2
fi
echo "OK (all secrets rotated within ${MAX_DAYS}d)"Same thing in Enterno.io
Wrap in an Enterno heartbeat with 365-day retention — the auditor sees "we knew and fixed it" instead of "found on audit day".
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.
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".
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.