Vault authentication: adding the correct entity alias for new users

Use case: I’d like to be able to invite specific individuals to my Vault system. I can assume that those users have an account on a well-known IDP (e.g. Google/Gmail or Github) that they can use to authenticate.

In an ideal world I’d just create an entity with an entity alias in advance, and that would be it. Unfortunately, I have no idea what the entity alias will be. For example, with Google, the “sub” claim is just a very long integer account ID. Even the user probably doesn’t know their own account ID.

I could instead just wait for them to connect the first time. The documentation says:

When a client authenticates via any of the credential backend (except the Token backend), Vault creates a new entity and attaches a new alias to it, if a corresponding entity doesn’t already exist.

That indeed works as described, but there are two problems with this:

  1. It allows random users on the Internet (who have Gmail accounts) to connect and create entities. Whilst those won’t have any authorization data associated with them - e.g. they won’t be in any groups - it’s still annoying.
  2. I have to fish through these auto-created entities, and find the one which belongs to the user that I invited, so that I can add authorization data to that entity. I have to convince myself that I’m authorizing the right one, and not some random bod on the Internet.

I was wondering about how this flow could be handled automatically. If there’s some existing mechanism which can do this, I’d really like to know it.

Otherwise, I think an ideal flow would work something like this:

  1. I create an entity in Vault, and add appropriate authorization (e.g. groups and metadata). At this point it has no aliases.
  2. I send a special token in an E-mail, to the E-mail address I know belongs to the user I want to invite.
  3. The user somehow combines this token with an OpenID login to Vault, such that when they login, it creates an alias attached to the entity referred to in the token, instead of creating an alias to a new entity.
  4. I’d also like to disable the automatic creation of new entities completely, so that entities have to be pre-created, and random users trying to login don’t create new entities.

Vault has multiple facilities for creating tokens (wrapped and unwrapped). Such a token could be used to authenticate temporarily as that particular user, and the user could have a policy which allows them to add their own entity alias. However, I still can’t see how the user would know their own alias ID. I’d like to combine this with the act of them authenticating to Vault, so that as I said before, it would attach their newly-detected alias to the existing entity.

Another option might be to merge the entity which I created manually, with the entity created dynamically by their OIDC login. However I can’t see how you could make a policy to allow the client to merge entity A with entity B, if the client can authenticate to Vault either as A or B. As far as I can see, the policy permits /identity/entity/merge for all entities, or not at all.

Any ideas or clues? Thanks!

I’m just going to mention that exposing your vault to the internet is probably not the best idea.
Maybe drop it behind a firewall and use VPN/Boundry to give the people you want access rather than any rando. It’s a little more setup work but then you’ll be a lot better off and less chance of secret exposure.

I have to ask @aram - why would you not expose it directly to the Internet?
I mean obviously if you don’t have to then you shouldn’t. But if I am trying to bridge different cloud VPCs etc that can’t be joined with some elaborate network level security - vault by design should be safe right?

See “log4j CIRT” as a example of unforeseen exposure.

My mindset is never expose anything unless you absolutely have to, use vpn if the users are a known quantity if you need multi-cloud access. You have to make the decision of “have to” or not.

That said, I know of no vulernabilities in Vault that prevent me from deploying it out… I mean HCP exists and the vault you build there is exposed, so Hashicorp believes that it is secure as well.


My bigger concern would be a denial of service attack against the exposed Vault service, rather than any secret leaks.