Vault has a feature that I really want to use... they promise the opportunity to set expiration on keys that is shorter than the time it would take to crack the keys if they were compromised.
We would teach each service to regularly request new keys frequently.
Why do I want that?
Every deployment I've ever set out to automate starts down a relatively short path of yak shaving that stops cold at a secret. The secret then begs questions about where to store it and how to protect its transport from storage to deployment. Who gets to put the secret in storage? Who gets to move the secret into the deployment? Can we revoke the secret if we learn its been compromised?
Those questions pull against automation. They land at an intersection of concerns that defy the automation. In fact, there are security anti-patterns that emerge from the forces behind these questions. Often systems end up sharing secrets.
For example, a shared deploy account on production systems. Everyone knows that's as bad as storing passwords in plaintext, and yet many places still land there. The time and complexity and high-stakes of discussing security policy pulls against our development schedules. How many people should we bring into the conversation to define the policy? The people we need most are all too busy with more important things. We can skip all of that by reusing the implied security policy already encapsulated in existing credentials.
As soon as secrets are shared between systems, the secrets ensnare those systems. Rotating the secrets becomes a question of careful timing. I can't change the secret in one place without breaking access to the other.
A developer's training to share code works against good security practice. We want every secret to be unique. But uniqueness is what breaks automation.
How does frequent rotation of keys help?
This is one of many counter-intuitive lessons in devops practice. Difficult things improve when we do them _more frequently_ instead of following our impulse to avoid their difficulty.
Vault includes policies for every secret including a lifespan for the secret. If we make the lifespans short, we have to figure out how to get our systems rotating keys without intervention. That requires figuring out the who's and the how's of creation, storing, resetting. In short, security policy.
Reducing the lifespan in which keys are valid significantly reduces the risk of compromised keys. One-time passwords are the extreme end of the spectrum.
If systems are resetting keys, we are forced to isolate secrets to prevent one system from rotating the secrets out from under another.
The discussions of policy and time to automate key rotation also lead directly to explicit understanding of system inter-dependency. The security policies become a dependency map. That feels like friction. But explicit dependencies support robust systems. They also support security-in-depth. It brings security policy discussion earlier into a service design and relatedly leads to early relationship with security team.
Another win in my imaginary world... the vault audit logs become health check for our services. The logs of key rotation becomes a heartbeat on the health of _relationships between_ dependent services. As an added bonus, this leads to more eyes on the audit logs... another layer in security-in-depth.
Eyes on audit logs also connects to that story about Splunk at JeffCo Schools
.
Hashicorp has their own advocacy for short-lived secrets: blog 
A related concept is restarting containers frequently. Many deep security exploits depend on long-running, undetected root kits lurking and collecting behavioral data about people who frequent that network. If you frequently burn containers to the ground and restart them from known good state, it reduces the window of time in which such attacks can be mounted.