I’m working on integrating Vault with one of my project. It is desktop application which works completely on client side (think CLI). The integration will allow my application to fetch secrets from Vault on user’s behalf (instead of them having to copy and paste the secret).
An OAuth like flow to grant access would’ve been ideal. But as far I know Vault can only provide identity not the authorization to third-party applications.
An alternative I see is Vault Agent, where user sets it up on there machine and my application just reads the token and continue working. But I don’t know if Vault Agent os recommended for Desktop usage or is it designed for keeping servers in mind only?
Asking vault admins to create an AppRole and sharing the credentials with all the users seems a subpar choice due to bad UX and the security risks associated with same secret being present at multiple places (i.e. each user’s machine).
What would be the recommended way for building such applications which require access secrets on user’s behalf and are completely client-only?
Thanks for any help. Please let me know if some part is unclear or more details might help.
Do the users already know about Vault and log into it themselves, or is it supposed to be an internal part of this system, invisible to users?
Is the aim here to simply allow the client-side application to access Vault as if it was the user, with the user’s full permissions? Or are you attempting to find way to give it restricted rights?
What methods of authentication are currently used within your organization?
Although not strictly necessary, it would help a lot to have a basic idea of what the application does and how users are expected to operate it, as that tends to lead to discussing those other details.
@maxb Thanks for the response. I’m sorry for missing details.
Do users already know about vault
Yes, users are supposed to be already using vault and should be able to login by themselves.
Is the aim here to simply allow the client-side application to access Vault as if it was the user, with the user’s full permissions? Or are you attempting to find way to give it restricted rights?
Ideally it would be restricted access on behalf of user. For example if user has access to N secret engines, they should be able to selective give access to application. Although having full-access on user’s behalf will also be acceptable.
What methods of authentication are currently used within your organization?
This will vary from user to user, but I expect most to be using OIDC or one of the cloud authentication methods.
Although not strictly necessary, it would help a lot to have a basic idea of what the application does and how users are expected to operate it, as that tends to lead to discussing those other details.
I can provide some rough idea. The application is somewhat similar to the Docker CLI, where instead of connecting to container registries it connects to other third-party services and uploads/downloads the data from their. And to connect it requires the relevant credentials, which user are most likely to already have defined in their vault.
This is quite surprising - you have multiple authentication methods used by different users in the organization? Doesn’t that make central management, and deactivating accounts for people leaving the organization rather chaotic?
If the answer was OIDC only, I was going to propose that you might be interested in replicating in your own code, the process that vault login -method=oidc goes through, to receive a token.
But, since you have multiple auth methods in play, I think you might be better off just instructing users to log into Vault CLI by themselves first, and then you can just execute vault print token to grab the token for direct use in another application.
This is quite surprising - you have multiple authentication methods used by different users in the organization?
Not specifically in our organization, but people outside our organization will also be using the application.
I think I wasn’t able to communicate the problem clearly. Any vault user not specifically in our organization might want to use the application. Having them copy the token and pasting seems to be worth considering.
Currently I’ve experimented with an approach where Vault acts as an Identity Provider for itself. Basically application asks user to go through OIDC flow and gets the id_token from Vault. Then uses this id_token to login using jwt method into the Vault.
I’m not sure if this raises some security concerns, but it seems to be a one-time setup for each vault and after that behaves similar to an Oauth flow for all users.
It’s pretty unusual for Vault to be deployed in a way where people outside of an organization have access
It’s bring your own vault for users.
That sounds mad to me - extra complexity providing you with little benefit. It is likely to prove confusing to your users too, IMO.
I agree it’s very complex. But I can’t seem to find any other way in which an org can use my application and each user of org does not have to do their own credential setup. Your suggestion regarding copying the token makes sense, but having a flow that seems like OAuth is much easier for user then copying the token IMO.
In this setup they don’t have to trust me with any credentials, everything is client-side only.
