Password manager based on Vault?

[Jakob Gillich]

Thinking about building a password manager on top of Vault, but there are a few things that make me question if that is a good idea:

1. Whoever has the root token can read all secrets, right? Or a MITM? I'd like secrets to be readable by a single owner/token only, even if the server gets compromised.

2. What is the best way to create a prefix for each user? The user/pass backend is what I would use, which I think generates a new token on auth, so cubbyhole isn't an option. But creating a new policy for each user doesn't really scale.

3. The key to scaleability with Consul is simply add more servers? :)

Thanks!

[Jeff Mitchell]

Hi Jakob,

1) Root tokens cannot directly read all secrets -- it depends on what
secrets you're talking about and where they're stored -- but using the
/sys/raw endpoint they can in theory (along with knowledge of the
underlying data store) look up anything stored in Vault. There is a
reason we discourage root token usage. :-) At the same time, there
has to be something that can be used for initial setup and/or in a
break-glass scenario.

2) Right now the only option I can think of would be creating a new
policy for each user. One way that this may be able to be enhanced
would be for the policy language to support templating, which it
doesn't now but could be an interesting addition. Then you could carve
out chunks of storage based on things like the token value, or the
display name on a client token.

3) No, Consul doesn't simply scale by adding more servers. You need an
odd number of servers, and with too many the replication information
for the Raft log ends up becoming a bottleneck. I believe even some of
the largest installs we know of are using five servers, and most use
three.

Let me know if you have more questions!
--Jeff

> --
> This mailing list is governed under the HashiCorp Community Guidelines -
> https://www.hashicorp.com/community-guidelines.html. Behavior in violation
> of those guidelines may result in your removal from this mailing list.
>
> GitHub Issues: https://github.com/hashicorp/vault/issues
> IRC: #vault-tool on Freenode
> ---
> You received this message because you are subscribed to the Google Groups
> "Vault" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to vault-tool+...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/vault-tool/3405a8cb-73b6-456d-9d53-01cccc0ace77%40googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

[Jakob Gillich]

Hi Jeff,

thanks, that helped a lot!

1) That makes sense, although when it comes to storing all your passwords on some server, I'd prefer the breaking-glass scenario to be all secrets inaccessible. But that's obviously not what Vault was designed for.

2) Templating in policies would be really neat.

3) Sorry that question was a bit silly. ;) What I meant to ask is if the consul limits are any different with Vault, but I take from your answer that they aren't.

[Jeff Mitchell]

Hi Jakob,

On Sun, Nov 22, 2015 at 2:01 PM, Jakob Gillich <jakob....@gmail.com> wrote:
> Hi Jeff,
>
> thanks, that helped a lot!
>
> 1) That makes sense, although when it comes to storing all your passwords on
> some server, I'd prefer the breaking-glass scenario to be all secrets
> inaccessible. But that's obviously not what Vault was designed for.

You can revoke the root token. So you could, for instance, set up a
series of tokens with sudo privileges to needed paths, and revoke the
root token, thereby ensuring that no token has access to /sys/raw. The
root token is required in order to perform initial setup -- set up
auth backends, for instance (or to make other tokens to do that) --
but other than an initial way to get things set up, it's a token like
anything else. So your break-glass scenario could certainly be to make
all secrets inaccessible, and Vault is totally designed for that to be
a possible scenario...it just requires you to set things up that way.

> 2) Templating in policies would be really neat.

Agreed. Right now, I don't think this will come in the next couple of
releases, but it would be cool if we could eventually get it in there.

> 3) Sorry that question was a bit silly. ;) What I meant to ask is if the
> consul limits are any different with Vault, but I take from your answer that
> they aren't.

Vault and Consul don't scale the same because they don't use the same
mechanism for leader election...Vault piggybacks on Consul's Raft log.
So Consul requires an odd number of nodes and generally you don't want
this to be past 7 at the most because of coordination needs -- but you
can throw Vault on 1k servers and it won't matter, because whichever
node gets the lock (using Consul's atomic lock capability) is the one
that is leader. Generally 2 Vault nodes is enough, but many like to
run 3 just in case.

--Jeff

[Jakob Gillich]

Hi Jeff,
 
> You can revoke the root token. So you could, for instance, set up a
> series of tokens with sudo privileges to needed paths, and revoke the
> root token, thereby ensuring that no token has access to /sys/raw. The
> root token is required in order to perform initial setup -- set up
> auth backends, for instance (or to make other tokens to do that) --
> but other than an initial way to get things set up, it's a token like
> anything else. So your break-glass scenario could certainly be to make
> all secrets inaccessible, and Vault is totally designed for that to be
> a possible scenario...it just requires you to set things up that way.

Right, but I'd need the ability to create policies for new users and if
I'm correct, that means r/w to /sys/policy and therefore access to
everything.
What I'm looking for is a way to cryptographically ensure each user gets
his own storage area that under no circumstance anyone else can read
(like the hosting provider, governments or whoever). Although the best solution
is probably to just encrypt everything client-side instead of crippling
Vault.