-
Notifications
You must be signed in to change notification settings - Fork 34
Open
Description
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
Metadata
Metadata
Assignees
Labels
No labels