At my employer we considered Vault. It's easily the best-in-class right now for free vaulting of credentials but it's missing a number of features and I disagr

At my employer we considered Vault. It's easily the best-in-class right now for free vaulting of credentials but it's missing a number of features and I disagree with a few implementation details... Firstly, it doesn't actually manage credentials for you (other than with AWS, a bunch of databases, and a few other things). It's not going out and logging into your 10s of thousands of Linux hosts making sure all the root passwords are vaulted, unique, and must be checked out before use. This is where products like CyberArk's come in (we use CyberArk and it's crap to be honest; it doesn't scale, its API is broken--REALLY broken--and its architecture is some of the worst junk I've seen in years and that's just scratching the surface of how bad it is!). Another problem with Vault is that it exposes too much information about the secrets via their URL/path. This is a very minor concern of mine and probably shouldn't impact your decision to use the product but here's what I'm talking about: The article author says that they're going to use this model for their paths: http://<vault>/secret/ENVIRONMENT/APP/KEY Here's my problem with this: If any configuration information is ever exposed an attacker will know that this application is part of ENVIRONMENT and has access to the keys for APP. If the host or container running this application were compromised this isn't really of concern since the attacker will probably be able to figure these things out anyway but my concern has more to do with configuration management systems. It's easy to imagine the ability to map out who-has-access-to-what in the vault just by examining their configurations. It's the difference between a config file with this: "secret_url": "http://<vault>/v1/secret/ENVIRONMENT/APP/KEY", "certificate": "/path/to/vault/client_cert.pem" ...and this, my preferred way (I split the vault_url and secret below just to save space since indented lines don't get wrapped on HN): "secret": "2a9ac85d-f6f1-4ef5-8d36-65331708623a", "vault_url": "https://<vault>/api/v1/secret/{secret}", "credential": "whatever" // I'd support multiple auth options The latter doesn't give an attacker much info at all about what that credential is. Even if they're able to retrieve it all they'll get back is, "<the secret>". "Great, now what do I do with this?" How I would do things different: * Secrets may only be accessed via their unique (e.g. UUID) object identifier. This means that if you want the credential for ENVIRONMENT and APP you must have the object ID. It cannot be inferred by the path. * Access to credentials will be controlled via attributes (extra keys/values attached to the same record as the secrets). This is mostly standard attribute-based access control (ABAC) with one exception... * Attributes can exist in namespaces that are controlled via independent groups. So you can imagine an internal team controlling namespace FOO and attaching `{"foo.admin":['userx']}` to the secret record for X. So if the FOO team wants to grant admin access to their app they can add a user (aka a subject) to their little "foo.admin" attribute on that particular secret. The point being that the FOO team doesn't need to open a ticket with the one true attribute authority (i.e. traditional ABAC) they can make the change themselves; the whole thing would be entirely self-service. There's zillions of ways to handle namespaced attributes like this but I personally prefer to just stick them right in the secret record itself and control access at the application layer. At my current employer I've been tasked with writing a vaulting and management application from scratch because nothing in the market will suit our needs. We (me specifically) tried really hard to avoid this situation but it seems that nothing that exists currently can do everything. Most notably: 1. Sane architecture (i.e. something that doesn't send all its logs to the same database as the secrets and doesn't run on Windows, gahh! Among other things) 2. Secure vaulting of secrets (aka "dumb vault") 3. Can *manage* credentials for various platforms 4. Provides a user interface for "checking out" secrets Hashicorp Vault does a great job with #1 and #2 but it doesn't do #3 or #4. We had initially planned to use it as a "dumb back end" for a custom system but it didn't work out for reasons that have nothing to do with faults in the product. That just isn't really what it was meant for. For reference, here's some of the problems we had with Vault that most won't run into: * Uses its own Certificate Authority (my employer only allows *one true authority*, sigh). * Written in Go which isn't approved. There were others as well but they were mostly bureaucratic. Note: In theory Hashicorp's Vault can do full credential management for anything but at this point in time it does not support writing your own custom back-ends. That feature is essential for managing zillions of disparate and possibly proprietary systems. For example, say you wanted to manage admin/root credentials for all Unix-like OSes at your company. All you'd need is a generic SSH back-end that can be scripted (e.g. expect or state machine scripts like CyberArk). Why they haven't added this is beyond me. The vault we're writing at my employer is actually pretty damned awesome and innovative. I wish I could share more about it but I can't. I'm pushing to make it open source but that probably won't happen.