You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently the primary use case(s) of this chart is
Provide an isolated VPN inside of kubernetes allowing wireguard peers to communicate with each other and egress over the node WAN.
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
WG Server pods have a sidecar that can interface with wgctl, and touch/keep a kubernetes object alive representing an active peer connection
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.
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
The text was updated successfully, but these errors were encountered:
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.
Currently the primary use case(s) of this chart is
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
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
The text was updated successfully, but these errors were encountered: