Running Vault publicly / external / WAN IP

[Jason Antman]

At the moment we're running Vault in EC2, in a dedicated account and VPC that's peered to the other VPCs we use it from.

Long story short (I've questioned and debated this as much as I can, to no avail), we've received an edict from on high that our company wants to become cloud-provider-agnostic *and* split every environment of every application into its own account. This means that (1) we'll likely end up with > 125 VPCs (which exceeds the VPC Peering limit) and (2) we may have services deployed into other cloud providers (where peering isn't an option). We've been told that VPN isn't an option, every team is being ordered to make their inter-service APIs available over the public Internet with appropriate security (which is easy for most of our homegrown apps, as they have ReST APIs and we just put them behind Mashery or API Gateway).

So... is anyone running Vault publicly, like listening on a port that's available on the public Internet? If so, how do you handle security, DoS prevention, etc.? Just hope for the best, or put it behind a firewall with explicit IP ACLs and perhaps DoS protection or rate limiting or something?

Thanks in advance for any advice or input.

-Jason Antman

(PS - There's a lot in the above that doesn't really make sense me. I'm doing what I can to come up with a logical counter-point, but as it stands now, this is an architectural decision that has been made way above my pay grade, and it seems more likely that we'll be told to ditch our OSS solutions (Vault, Consul, etc.) in exchange for far less-capable, far more expensive hosted "Enterprise" solutions than see a change in this.)

[Craig Sawyer]

Hi Jason,

It's my understanding that recent vault (>0.6.3) limits each request to 32MB. 

I'd imagine you'd want to put your own limits in front of that for anything public facing. There is also another thread from earlier on public facing vault that might be of interest: https://groups.google.com/forum/#!searchin/vault-tool/public/vault-tool/6Y5WIaL94d4/-agQPZDLAwAJ (If the link doesn't work the thread subject is: "Vault + Bastion Host: Best Practices or Alternative?").
 
I'd definitely suggest hiding access to it as much as possible, if you can, security in layers is rarely a bad idea :)

I'm not running vault publicly accessible, but it's something we are exploring, so I have interest in this topic.

As a side note, Hashicorp offers an enterprise Vault solution, you can pay them to run it for you.

-Craig

[Jeff Mitchell]

Hi Jason/Craig,

I literally just wrote something similar on the list so I'll repeat it
here :-D But first, to correct something:

> As a side note, Hashicorp offers an enterprise Vault solution, you can pay
> them to run it for you.

We don't! Vault Enterprise isn't hosting, it's enterprise-focused
features. But I think there are some other companies out there that
will do hosting.

Here's my immediate list:

* Keep your Vault servers minimal -- have them be standalone with
nothing else running, especially network services. This helps keep the
attack surface low. In many modern infras this basically means
treating Vault servers like special snowflakes...but it's a worthwhile
tradeoff for a security product.

* Limit the number of accounts and/or people that can log in. A user
that can log in locally is one that can be attacked remotely.

* Use firewalls to restrict access to non-Vault services (e.g. SSH) to
local IPs rather than the world at large.

* Use advanced firewall features like connection tracking/limiting to
detect attacks and limit them before they hit the Vault server.

* Make sure any authentication backends you have enabled in Vault have
good configurations, e.g. if you are using App-ID you wouldn't want an
app/service id of "test" and "test".

Best,
Jeff