Add support for pod Wireguard sidecar
This PR adds a sidecar which can be added to a pod by the controller when the annotation:
vpn.example.com/sidecar-enable: true is set and vpn.example.com/sidecar-wireguard-ref: is a valid wireguard reference
The wireguard sidecar is automatically configured for the vpn and a peer is created automatically.
@jodevsa can I get a cursory review on this? My Go is awful, so just want to know I am heading in the right direction
Sure, Can you please elaborate on the use cases of this feature?
Sure, the use case would be to put the individual pods on a WireGuard network for secure communication with services elsewhere in the mesh.
See: https://github.com/jodevsa/wireguard-operator/issues/27
@jodevsa can I get some help on why the e2e tests are failing, this code is still unfinished because I had to do some work to improve and fix up the makefile for local development.
Hello, @Matthew-Beckett
how this would work to route multiple pods to a single wireguard peer interface ?
Having this scenario: Wireguard is deployed as a peer that connects to a remote server. In that case, if i'm not wrong you have wg0 created inside the wireguard deployment (or better, inside the pod of the deployment).
In order to have another pod (your application) to route its traffic to that network interface, would this PR solve this scenario?
As far as I know, you need a multi-homed pod (like using multus) and bridge a dummy interface, otherwise your application pod will not connect or route to another interface (wg0) inside another pod.
Has this been tested? Aren't pods immutable? I believe other projects use admission webhooks to patch pod specs before they're actually created.
https://github.com/linkerd/linkerd2/blob/1fed61edc945a39612c1c9bc6fec340dbeb0f15d/controller/proxy-injector/webhook.go