search

bryopsida / wireguard-chart

A helm chart for wireguard
40 stars 26 forks source link

Add option to expose services running on peers to cluster workloads #57

Open bryopsida opened 2 months ago

bryopsida commented 2 months ago

Currently the primary use case(s) of this chart is

1) Provide an isolated VPN inside of kubernetes allowing wireguard peers to communicate with each other and egress over the node WAN. 2) Provide kubernetes service access to WG peers

There are other use cases that could be interesting as well.

Such as the use case mentioned in #38 where things inside kubernetes route and connect to services on the peer.

There may be a way to create service objects associated with wireguard peers.

Something like this

1) WG Server pods have a sidecar that can interface with wgctl, and touch/keep a kubernetes object alive representing an active peer connection 2) A separate deployment watches those objects and manages service objects and deployments that ultimately result in a iptable transform or other means of routing to get the traffic sent to the peer. 3) Unfortunately we cannot define port ranges on service objects so we likely would need to lean on the helm values to provide information on what port ranges should be available on the peer or globally and use templating/etc to create definitions for each port on the service

This in theory would make it so kubernetes workloads could discover/resolve the peers like this.

peer-name-alias.<wg service namespace>.svc

Perhaps haproxy could be used with hostname routing to limit the amount of pods created with large peer connection counts

bryopsida commented 2 months ago

Additional considerations.

1) The WG server pod with the client connection is the only network namespace that has the routing information to that peer. 2) Because of 1) the HAProxy would need to run as a side car 3) Because of 1) some means of coordination to which server pod holds which peer would need to be maintained.

bryopsida commented 2 months ago

Something else to consider, if a service mesh is leveraged, we could just watch the peer connections and register/update entries in the mesh, perhaps an option to embed a standalone istio (to share routing just across WG server ports) or interface with an existing one to expose to a large group of things.