What does this mean: "the plugin method is mounted at the /auth/jwt path in Vault"?


The excerpt above is from this documentation. Could someone explain to me what it means?

Many thanks!

vault plugin list
shows you what plugins are available, and you can mount them on different paths with different options.
You then interact via that path to use the features of that plugin, be it a dynamic secret, a kv store, auth, etc.

Hi @aram ,

All right, thanks. What does it mean to “mount a plugin” on a “path”? What is the meaning of “mounting” and “path” in this context?


All interactions with Vault go via its HTTP API.

The paths in the URLs used are incredibly important, as they are what Vault policies use to determine who is allowed to access what.

When you enable a Vault auth method or secrets engine, this is also known as mounting - i.e. the operation of adding new functionality at a given sub-tree of an existing path hierarchy.

Hi @maxb ,

All right, thanks a lot. That’s much clearer!


Hi @maxb ,

As you probably guessed, I am trying to enable OIDC for Vault. I have a question regarding namespaces, and the documentation does not specify anything about namespaces. Do I need to enable OIDC for each namespace?


Well, no, you didn’t mention namespaces or OIDC at all before now.

Generally it is best to start a new topic for a new unrelated question. It helps readers know the conversation has shifted to something else, and lets you put a new more appropriate subject line on the new conversation.

To answer your question though… it depends what you are trying to do.

Vault namespaces are surprisingly complicated and easy to misuse. I will say a few things I would like to have known when I started working with them.

First and foremost, Vault namespaces exist to allow delegating the ability to configure Vault policies, within a subtree of the Vault path space.

If you’re using namespaces, but not intending to make use of delegating access to configure policies, it may be that you don’t actually need namespaces at all.

Second, even if you do want namespaces, it might still be appropriate to keep all your auth methods in the root namespace.

When you place an auth method in a child namespace, any entity logging in using it will be confined to only access things within the subtree of the child namespace.

This might be what you want - for example if you need to give separate business units entirely isolated private subtrees of Vault.

But, if your business units need to share secrets with each other - for example by one publishing secrets to a KV for another to read, this model doesn’t work.

Similarly, if you need to expose a secrets engine that is a common resource for multiple business units, you can’t do it, if everyone is logging in to auth methods in their own namespaces.

To satisfy these use-cases, the auth methods need to be in the root namespace - or at least, a namespace which is a parent to everything which needs to be accessed.

Another thing to think about when planning your auth methods is: will the same person or thing, need to log in to multiple namespaces? If the answer is yes, you need to plan on each login to a different namespace, counting as a separate client - contributing the usage of your Vault Enterprise licensed number of clients, and so increasing your license fees.

Hi @maxb ,

Sure, next time I’ll make sure to start a new thread.
Thanks a lot for your thoughtful answer, that’s very informative!