Vault live
Which credentials the services hold now, for how long, and the one that never expires.
No service talks to Vault. A Vault Agent beside them logs in with its AppRole, asks Vault for each service's credentials and writes them into a file the service reads at each connection. A short-lived credential is a MySQL or RabbitMQ user Vault creates for one service: it lives 2 minutes, the agent renews it up to 6 minutes, then asks for a new one and rewrites the file; Vault drops the old user when its lease ends. A leak is worth minutes. The long-lived one is the Bank Partner's key: the bank issued it once, Vault only keeps it, the bank decides when it changes.
The page reads Vault with the console's own token: it lists leases and reads metadata, never a value. The page refreshes every 10 seconds; the bars run down in between. The full Vault UI is on localhost:8200 (token root, dev mode).
Short-lived: one user per service, replaced every few minutes
5 credentials alive nowdatabase/creds/hello-api
MySQL user on mycompany and orchestrator 路 lives 2 min, renewed up to 6 min
database/creds/order-worker
MySQL user on mycompany and orchestrator 路 lives 2 min, renewed up to 6 min
database/creds/identity-service
MySQL user on identity 路 lives 2 min, renewed up to 6 min
rabbitmq/creds/hello-api
RabbitMQ user publishing the order events 路 lives 2 min, renewed up to 6 min
rabbitmq/creds/order-worker
RabbitMQ user consuming and publishing them 路 lives 2 min, renewed up to 6 min
Long-lived: a key the bank issued
Metadata only, never the valueBank Partner API key long-lived
Issued once by the bank to us, its client; long-lived, rotated by the bank.
secret/bank-partner 路 version 1 路 written 25 s ago
The API sends it on each call to the bank (X-Api-Key); the acceptance tests read it from Vault too, with a token allowed this path only.