[armon]

We work with many Fortune 2000 customers, and having 500K secrets is on the extreme side and most certainly puts you in an infrastructure where you have 50K-100K+ machines under management.

In terms of the "compute cost", for an infrastructure of that size this is a negligible amount of overhead. For dynamic secrets that live 30 days, rotating 500K secrets works out to 1 secret every 5 seconds.

The advantage would be avoiding an incredible number of static credentials sprawled across a very large estate, plus having a unique audit trail that lets you identify points of compromise. Treating those credentials as dynamic will also reduce the human overhead of managing so many credentials, instead focusing on roles and high level intents.

I question if there is an non-disclosed bias given the anonymous user, created just in advance of the comment.

[whip113]

How is a dynamic secret that has a TTL of 30 days avoiding static credentials sprawled across the estate? It's static (for 30 days) and the only difference I see between rotating the password of an ID every 30 days and a dynamic secret with a TTL of 30 days is that when I cycle the dynamic secret I have to reassign entitlements to the new user ID and correlate this new user ID with my monitoring systems and Vault audit data. I disagree that the compute cost to doing all of that is a negligible amount of overhead.

Like I said, I think there is a use case here for dynamic secrets, but I have questions about what it looks like when it comes to trying to do them at scale. If you have solutions to the worries I outlined, I'd love to hear them.