0

Context:

  • We're working on an integration with one of our clients
  • In order to get access to their systems, we need to establish a VPN connection
  • For security reasons, we need to bind this VPN connection to a static IP on our side (basically, layer 4 security check enforced by a Juniper router; we use OpenSwan to connect to it).
  • To do that, we must be connecting from that IP ; that is, we need to establish a socket connection, where the source IP corresponds to that static IP from the router's perspective (and, of course, that needs to route back to our pod successfully)
  • Client's side has very limited resources ops-wise, so this security hoop is the only way to connect to their systems

While our current system is running (AWS) Kubernetes, which is:

  • Made out of transient pods, transient nodes, with shifting IPs
  • Can assign an ExternalIP to a service (which, in turn, can route it to a pod); however that, by default, makes no guarantees about the originator IP of the traffic initiated by that pod

For this reason, we set up an external box & assigned Elastic IP to it, as a binding for the VPN, exposing endpoints, and calling our Kubernetes Services. This introduces a single point of failure -if that box goes down, so does our integration.

Question: in what ways can this be made HA within the Kubernetes world, given the constrains on the first list above?

Silver Dragon
  • 5,480
  • 6
  • 41
  • 73
  • You might want to consider putting a Load balancer like nginx or haproxy in between and assign it your External static IP and then route them to your internal pods which can be replicated for HA. However , this still has the Single Point of Failure problem as you mentioned on the LB side , but it can be contained more easily than having this problem on your application side. Also, try to consider having two static IPs instead of one on the LB side , which can also provide a better HA architecture. – fatcook Nov 28 '18 at 04:52
  • @fatcook this does not solve the problem, whereby an outgoing connection needs to be originating from the static IP. A connection made from the pod, from an outsider perspective, will always carry the node's IP (which is transient, and can change any time). – Silver Dragon Nov 28 '18 at 07:54
  • I am not sure I get the use case clearly then , using a reverse proxy mechanism you should be able to manage to show the connection is originating from your application itself. – fatcook Nov 28 '18 at 11:08
  • Except the connection is not HTTP, openswan requires an _outgoing_ TCP connection, which appears to be initiating from that external IP. – Silver Dragon Nov 28 '18 at 11:54

0 Answers0