[blorgle]

I personally don't think iptables or switching ports is a viable solution and always use the following policy:

All the internal services should never be exposed to the internet and only accept connections from signed packets using IPsec or OpenVPN with TLS auth.

Yes, this means more key management.

[therealmarv]

Interesting approach. I only think that OpenVPN is not more secure than SSH, somewhere needs to be access point/loophole and SSH is pretty good tested for this. It also does not solve the problem when using a single CoreOS server where you need to run OpenVPN in a container (and I'm also not sure if you can access the host from this container).

[vidarh]

You can certainly give the container access to the host a number of ways. For something like OpenVPN --net=host passed to Docker will give OpenVPN full access to the host network.

I agree with you - ssh is fine. If you have multiple CoreOS boxes somewhere without a secure private network, though, OpenVPN, PeerVPN or similar solution works fine.

If you couple it with Flannel set to use host routing, you can give all containers their own IP addresses on non-colliding IP ranges (Flannel takes are of coordinating that via etcd) and Flannel doesn't add (in the host routing variant) extra overhead as it just adds suitable routes on each server.

You can set this up a in few different ways: CoreOS provides Flannel coupled with an "early" Docker daemon (so you'll have two) to run stuff that needs to run before the "real" Docker daemon, such as to set up a VPN etc. You could also use Rocket/ACI containers, or run it outside a container.

Alternatively newer versions of Docker supports network plugins, though I've not yet had time to test this with CoreOS as I already have working VPN setups based on Flannel + early-docker.

[blorgle]

OpenSSH in normal configurations will respond to all requests with an open socket regardless of whether that request is signed or not. Worst case scenario like OpenSSH Unprivileged Remote Code Execution, or Heartbleed style attack.

OpenSSH behind VPN technology like IPsec or OpenVPN (with TLS auth) means that only authorised (in possession of valid signing key) clients see the open socket.

OpenSSH does have "SSH certificates", but using VPN technology allows you to secure multiple internal services including those that don't support any encryption natively.

[girvo]

Is there a decent guide to this sort of infrastructure? It's something I've considered for a while but never looked into much.

[kchoudhu]

I have a couple of Ansible playbooks under development to do this -- but it's a very specific topology that may not work for you.

If you are interested, I could post them when they are done.

[girvo]

I'd definitely be interested! Thanks for the offer :)

[kchoudhu]

Oh, hooray. I'm not the only person who runs openvpn to create internal overlay networks.