Add option on Network class to provision a bastion server

[lukehoban]

From @lukehoban on December 28, 2017 22:36

When setting up a private network, it would be very helpful to have the option to allocate a bastion host with SSH access using a provided key material.

This probably should be part of the Network layer, but could also in theory be part of a high level like the Cluster layer.

Copied from original issue: pulumi/pulumi-cloud#323

[lukehoban]

From @joeduffy on December 29, 2017 15:49

One of our customers needed a similar capability in their stack, except that they prefer to use OpenVPN. I believe this is so that they can access GUI endpoints, like their Kibana dashboard.

It would be nice if we somehow had the right customizability hooks to enable this. (Maybe it's as simple as having an SSH versus OpenVPN option, for the "simple things simple" use cases?)

[lukehoban]

There's sort of three levels support you could want here:

1. Bastion host: You have to SSH in for operational tasks, and access control is based on SSH access.
2. Client VPN: Client machines can VPN in to the VPC temporarily, and access control is based on VPN software configuration. AWS does not offer any first class solution here - so you need to use custom 3rd party software for both the VPN server inside the VPC and the client machine VPN client.
3. Corporate network VPN: Persistent VPN connection between a corporate network and the VPC. There are first class AWS offerings to support this.

Although they accomplish similar things, they are quite different. The good news is that all of these are possible to build manually on top of the Network abstraction - we don't strictly have to add them all (or any) as first class options on Network itself.

Option (2) is relatively more scary than the others because it involves a fairly complex piece of 3rd party code (most likely OpenVPN, though there are also a lot of other options users may in principle want to use based on existing use within their organization and IT support for various VPN technologies) with no managed service to take on the operational burden of security matches and maintenance.

Option (3) at least does have a managed service offering - AWS Managed VPN: http://docs.aws.amazon.com/AmazonVPC/latest/UserGuide/VPC_VPN.html. But it only makes sense when you have dedicated hardware/software on your corporate network.

I suggest we do two things:

1. Provide an option to expose an SSH bastion - as that is the "dumbest but still effective" thing we can offer as part of the Network construct.
2. Package up our OpenVPN component as a separate package which can install on top of any Network and make it another package in our package ecosystem.
3. Ignore persistent corporate network VPNs for now - if we find use cases for this, we can build additional packages for this pattern.

Alternatively - we could make (1) a separate component as well just for simplicity and orthogonality of concerns.

[lukehoban]

From @joeduffy on December 29, 2017 18:52

I like it. I do think an SSH bastion out of the box would hit the 80% sweet spot.

[lukehoban]

Going to close this out now - it's just a few lines of code to add a bastion host on top of existing Vpc primitives in this library - not sure there's anything more we want to do "automatically" here in the near term.