Hacker News Reader

Comment by jwilliams | Hacker News Reader

This links to a HN discussion on the relative merits of VPN access versus bastion/jump boxes (https://news.ycombinator.com/item?id=8637154).

This conversation didn't ever seem to bottom out to conclusion? In particular I was wondering how servers connected _outwards_ in the VPN scenario.

View on HN

In either case—assuming you run a VPC—you usually configure one or more NAT instances to allow EC2 instances to communicate with the internet (http://docs.aws.amazon.com/AmazonVPC/latest/UserGuide/VPC_NA...). I suppose a bastion could do double-duty as a NAT, but in most cases you want one per availability zone to add isolation and redundancy.

You can also configure HA NAT with an ICMP heartbeat: https://aws.amazon.com/articles/2781451301784570

Doesn't this -somewhat- mitigate the advantage of having zero-surface area?

I'm using a Bastion setup, so don't get me wrong, just want to understand how strong the pros are for the VPN route.

On your last note. I just run one Bastion as a general rule. They're quick enough to spin up another instance (in a different AZ if necessary). Generally our services won't die if the Bastion or NAT is down.

We (Appuri) use VPCs exclusively. There are pros and cons. I'll try to list the top:

Pros: - Logical isolation. You can put instances (and RDS, Redshift) etc. inside logical subnets that are not addressable from the outside world. - VPNs. If you really want extra security, you can wire up VPN so one of your VPC subnets shows up on your corporate subnet.

Cons: - A complete pain to manage with SSH-based tools. Most deployment tools (Ansible, for example) and even lower-level tools like fleetctl don't play well (if at all) with jump boxes. Example - Ansible Tower requires instances that are publicly addressable OR placing a Tower instance inside a VPC (which means we can't use it to manage multiple VPCs) - We have had to write our own workarounds for the above con. - Complexity. There are more concepts to learn about. - Lack of portability. I don't know if all cloud providers (Azure, DO etc.) even support VPCs the same way AWS does. This makes our infrastructure less portable than I'd like

I think you'll find you can solve this via ssh config. Specifically using ProxyCommand -- in the case of Ansible anyway. You can then ssh reference an internal address.

I was asking less about VPCs in general, more the use of the VPN->VPC or Bastion approach to bridge into that network.

We use fleet within a VPC and our approach is to just have a single "ops" box in the public subnet and then use $ETCD_ENDPOINT (or whatever the environment variable is) so that etcdctl/fleetctl can connect to one of the boxes in the etcd cluster.

We disable password login on the ops box and set up 2FA on SSH connections. We haven't taken the step of whitelisting IPs but it's probably something we should do.

I just finished moving our last EC2-Classic service into VPC. It's been less of a headache than I anticipated.

If you need a VPN, you'll know it. My advice if you don't need a VPN now is to leave a few smallish subnets in your VPC for NAT'ing if you need to setup a VPN in the future. Then, just white-list the IP's that have access to your bounce boxes. Create a Temp security group and add your home/hotel IP on demand, blow all the rules away regularly. You have essentially have a multi-factor protected white-list for your bounce boxes at this point.

The logic here being you'll only need certain things on the VPN, and you can put them or give access to them through the small subnets. You can simply use NAT to translate a /28, /29, or whatever to an available block in your corp network. This won't work for everyone, but I think for a lot of cases you don't need full access to the VPC via VPN and you'll know pretty early on if this will work for you or not.

Reply on news.ycombinator.com