Custom VPN support for FlowForge applications

[MarianRaphael]

User Story

As a: FlowForge user

I want to: have the possibility to establish a VPN connection for my FlowForge project (edit: application)

So that: I have the possibility to manage devices and can access data sources in my private network.

Motivation

Almost always, industrial equipment is not in a public network or has free Internet access. This especially raises challenges for those who run FlowForge in a cloud environment or FlowForge cloud customers.

Licence

EE - Enterprise Tier feature

[hardillb]

First thoughts:

1. This will probably require a custom stack for each VPN type that includes the VPN binaries
2. Might require custom Kubernetes permissions to allow the setting up of network interfaces (need to asses the security considerations)
3. Need to be very careful about what IP address ranges are supported to prevent clashes with the Private IP address ranges that exist inside the K8s cluster
4. Need to ensure this is basically one way (no way for device on connected network to reach further than the single FF Project Pod)
5. How does this work with TCP/UDP nodes and allowing inbound connections?
6. Will need a way to convey VPN status to Node-RED (custom nodes?)
7. How will it be configured (possibly see point 6)

[hardillb]

We may be able to use a sidecar container to add the VPN support which makes things easier (simpler stack), but still need to work out how to configure

[hardillb]

I have successfully demonstrated a WireGuard connection set-up using a sidecar container from my test K8s cluster to my home network.

This works using the https://github.com/linuxserver/docker-wireguard container with the work around from https://github.com/linuxserver/docker-wireguard/issues/205#issuecomment-1308591466 to load the config/secrets from a ConfigMap.

This covers points 1 & 2 above, but all the other points still require addressing and we have the following extra points

1. How to securely capture and make use of the VPN secrets in the FlowForge environment
2. How to make this option only available on FlowForge with the Kubernetes driver as it will not work in Docker or LocalFS environment (Possible to use a K8s webhook to add sidecar if a label is added to the deployment, but still need to add UI to get config info)
3. This is per project, multiple projects in a given team would each need their own (separate) VPN connection/config

Still needs a LOT of security review

[hardillb]

Skeleton bare pod yaml

apiVersion: v1
kind: ConfigMap
metadata:
  name: wireguard-config
data:
  wg0.conf: |
    [Interface]
    Address = 10.9.0.3/32
    PrivateKey = xxxxxxxxxxxxxx

    [Peer]
    PublicKey = xxxxxxxxxxxxxx
    AllowedIPs = 10.9.0.0/24
    Endpoint = 192.168.1.64:54130

---
apiVersion: v1
kind: Pod
metadata:
  name: wireguard
spec:
  containers:
  - name: busybox
    image: busybox
    command: ["/bin/sh", "-ec", "sleep 1000"]
  - name: wireguard
    image: ghcr.io/linuxserver/wireguard
    securityContext:
      privileged: true
      capabilities:
        add:
        - NET_ADMIN
      readOnlyRootFilesystem: false
    lifecycle:
      postStart:
        exec:
          command: ['cp', '/tmp/wg0.conf', '/config']
    volumeMounts:
    - name: wireguard
      mountPath: /tmp/wg0.conf
      subPath: wg0.conf
  volumes:
  - name: wireguard
    configMap:
      name: wireguard-config

Still need to review minimum viable permissions

[Steve-Mcl]

Initial meeting notes here: https://docs.google.com/document/d/10Fylqt7myR3a18C3uEJ1Jgt9VjEJJTOQsaCtQ7y8jSc/edit#heading=h.61ho28kgm76

[hardillb]

We should review the network setup of the production K8s cluster to see if there are changes that could be made (if starting from scratch or being able to retroactive apply) that would make this safer and easier to implement (e.g. picking the most obscure RFC1918 address ranges that are large enough to meet our needs and not clash with customer networks, or maybe see if it is possible to run a totally IPv6 cluster.)

https://aws.github.io/aws-eks-best-practices/networking/ipv6/

[knolleary]

AS discussed, pushing this back onto the backlog.