That said, I hope that they continue to iterate on some fundamental design ideas:
(a) Attacks that can read arbitrary files from disk are far more common and simpler to execute than attacks that can read process memory. Leaving the unencrypted files available in a filesystem for a process to read leaves it open to this kind of attack, whereas using in-memory envelope decryption reduces the chance of this happening because there aren't remnants on the filesystem to deal with. Granted, this is difficult to do when depending on lots of open source software that expect secrets to be read from a file and is easier when you are building microservice daemons from scratch.
(b) It appears that the ability to acquire a secret is not revocable. Why is this useful? Often, you want a server to start, acquire secrets, and then drop the ability to acquire those secrets again. This reduces the risk of later attacks which get access to the system. Think of this as a similar pattern to how daemons will drop root privs after listening on a privileged port, or how nginx will drop privs after reading an SSL key.
(c) Keywhiz' uses a new service for managing the secrets. This presumably requires a server and other "big" components that exist alongside existing developer tools, and has a deployment burden for the host. Using envelope encryption would allow the secrets themselves to be stored in an encrypted form in the version control system, alongside the code they service. This gives you an audit log of changes to secrets that is integrated with the rest of your tools, rather than building a new system to do so.
Anybody interested in this space should definitely check out Amazon Key Management Service. I hope to see some open source implementations of AWS KMS in the near future!
