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.

IME, dynamic secrets don't scale well. First, you're going to have a tough challenge getting a large org to stop sharing secrets amongst apps/hosts. Tougher still is providing a justification for why host1 for Salesforce needs a unique credential from host2 for Salesforce that is doing the same thing. Second, ensuring privilege creep doesn't occur becomes nightmarish when you consider an environment today that has 500k secrets and having to audit the authorizations an ID was granted in multiple backend authentication systems after that ID has been deleted. Finally, generating dynamic ids for an environment like this is a staggering amount of compute workload. Taking that same 500k environment and breaking these out to unique credentials dynamically generated puts you into 7 figure numbers pretty quick. Even if we ignore the complexity of such an arrangement, just consider what the performance demands are going to be to generate an id, assign it privileges and a password, provide that to a client, then clean the same id up later. We'll ignore how this looks in an environment where you have to replicate the identity that was created across multiple authenticating backends. (think Active Directory domain replication)

In short, I think dynamic secrets will increase the threat surface dramatically, while simultaneously increasing complexity. Complex systems are expensive to maintain, hard to secure and notoriously fragile. There is a limited scope use case where dynamic secrets may be a good fit, but I for one wouldn't base a purchasing decision on whether or not my secret store can do dynamic secrets. Instead, I'd want a secret store that has some provision for secrets rotation that I can tailor to the needs of my specific use cases.

I have 500k ids today. Now you want me to make those ids dynamic and correlate how much Splunk data with Vault audit data? And what is my pattern matching regex going to look like when the ids I'm trying to match on are randomly generated? And how do I pick out anomalous behavior from the noise I just intentionally created because Terraform can't stop leaking my secrets? And what about the performance? How does Vault scale to generate that many identities? And how do I audit my authorizations since on Vault I'd just see what groups the IDs were added to but not the groups those groups belonged to? What about replicating my authentication backends? Active Directory replication takes minutes to replicate a password in some environments, it's going to take longer to replicate a new identity and its group memberships. And while I can revoke an identity after some time, that doesn't mean existing authenticated sessions are terminated, it just means subsequent authentication with the same secret will fail.