Automatic assign new user to existing entity

[dlmorais-13]

I have a current scenario where I use Vault to store secrets that are used during Continuous Integration (CI) process.

In my use case, I have a GitLab instance that users authenticate using an Active Directory (AD) account, and in Vault I have two authentication methods: AD and JWT (for GitLab CI).

Users can authenticate into Vault UI using their AD account and create secrets on a KVv2 store called users, but they only have permission (read/write) on the path users/{username}/*. When the CI is running, the JWT issued by GitLab contains the username on a claim, and, as the authentication method is the same AD server used on Vault, the username matches with the one used to login on Vault UI. This way, I have a default policy that allows every issued token using JWT auth method to read secrets on the path users/{username}/*, thus allowing the CI process to read the secrets that the users have created for themselves.

All that is working great, until a new requirement entered the game.

Now, I have a scenario where I need users to be able to create some shared secrets and those are shared only with the users that are members of specific AD groups. This is was configured by associating policies with AD groups on AD auth method in Vault. But sharing secrets this way doesn’t allow the tokens created with JWT auth method to read the shared secrets, of course.

Now I wonder if is it possible somehow to instruct Vault to, whenever an entity is about to be created when using this JWT auth method, search for a entity where there is an alias from another specific auth method (AD in my use case) with the same name and instead of creating a new entity, create an alias to this existing entity.

Ps.: I am also open to another type of solution that I did not think of.

[maxb]

@dlmorais-13

Now I wonder if is it possible somehow to instruct Vault to, whenever an entity is about to be created when using this JWT auth method, search for a entity where there is an alias from another specific auth method (AD in my use case) with the same name and instead of creating a new entity, create an alias to this existing entity.

It would be really nice, wouldn’t it… I would have wanted that too, in a previous role.

Unfortunately it is not - you are, as far as I know, stuck with needing to periodically runs scheduled job which makes edits to entities using the Vault API.

Such a job might either act preemptively, for example by scanning AD and pre-creating entities before users log in, or reactively, merging entities after they have been created.

In the event that you choose to do this reactively, if you use Vault Enterprise, be aware you will be billed for both copies of a user, until you enter a new licensing period after merging them.

Also, doing it reactively implies that initial logins won’t have all the access set up, so some operations will fail initially.

Whether you do this preemptively or reactively, bear in mind that group membership will only be refreshed when the user logs in via the AD/LDAP auth method! If the user is added to or removed from groups, and then launches new GitLab CI processes that are expected to see the new access - they won’t, until the human user logs in to Vault again.