CORS headers

[jgillich]

A way to set CORS headers like Access-Control-Allow-Origin would be great.

[jefferai]

Agreed. Not sure when it will happen, but it should be supported.

[certifiedloud]

Until Vault supports this, you can get around the issue by using nginx (or something) as a reverse proxy that sets the headers for you.

Of course this doesn't work in every situation, but it has worked great for me.

[jgillich]

That's exactly what I'm doing (I even, erm, "documented" it). IMO Vault should just allow everything in dev mode, having to deal with CORS is sooo annoying.

[jefferai]

@certifiedloud @jgillich Unfortunately, that's not a solution that works for anyone sensitive to transitive trust issues, since it implies that the reverse proxy must decrypt and then re-encrypt the traffic.

[LeftyBC]

+1

Vault having a HTTP REST API but then not having CORS support is an issue for us as well.
I'm working on a frontend for replacing our team's password spreadsheet with something that is a lot more secure and role-based (as vault is exactly intended to do).

I'll install nginx, but that's a bit of a heavy dependency for just injecting a single header.

[naunga]

Having this feature would be great.

As I see it a moderately skilled Gopher could add this functionality in a PR, which leads me to wonder why it was not included from the start?

Does it cause anymore of an insecurity than having a proxy handle it?

Hell, I'd be happy to do it, but if there's something I'm not seeing...

Anyhow. I look forward to a response.

Cheers.

[jefferai]

@naunga There are many, many things that it would be nice if Vault had from the start. If we took the time to implement all of those, there would never be a release of Vault, ever :-)

[naunga]

Yep I totally get that.

Which is why I mentioned that I'd happily submit a PR to implement it. That being said there is no sense in submitting a PR that'll be rejected for a reason like, "we discussed this for weeks and decided to never implement it, because of these reasons..."

My previous question was aimed at seeing if a PR to implement this feature would have a chance at being accepted.

[jefferai]

Honestly, this hasn't been discussed as it's been very low priority -- the vast majority of Vault usage is not via direct browser calls, so CORS isn't paid attention to.

I think one item that would need to be figured out is whether such headers are configured in Vault's config file or at runtime. In general we try to keep security-sensitive items outside of Vault's configuration file but rather behind ACL'd APIs.

[naunga]

Ran into a blocker at work today where a proxy just won't work for us. It's a matter of we have close relationship with the engineers who run the vault installation, but they aren't interested in running a proxy for us. However they'd be fine with enabling CORS if Vault supported it.

So I've forked the repo and got it working. Not ready for a PR yet, because I want to put the CORS option inside the global configuration.

Certainly open to thoughts on things.

[benjic]

@jefferai Would the CORS settings fall into the core/ namespace? The LRU cache ignores this part of the namespace. Seeing as the CORS parameters would be needed per request it wold seem not feasible to do a full physical backend query without performance implications. The physical backend mechanism seems like it would be necessary to ensure HA would consistently support CORS parametrization as well.

Is there another example of a runtime parameter that is stored by vault outside of it's configuration?

[jefferai]

They'd be stored there but it's reasonable to keep the current values in memory. No reason to hit the physical layer every request, cache or no, because it still requires description in that case.

[benjic]

I'm not sure how you would maintain a consistent CORS setting across all HA instances if the value is strictly kept in memory.

[jefferai]

Only the active node responds to requests...

[PhillippOhlandt]

Any news on this?

[jefferai]

It's being implemented in #2021 -- in fact, I should just close this in favor of it.

[PhillippOhlandt]

@jefferai cool. any ETA on the merge + release?