Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
bryopsida opened this issue Aug 31, 2024 · 2 comments
Open

Comments

@bryopsida
Copy link
Owner

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
Copy link
Owner Author

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
Copy link
Owner Author

bryopsida commented Sep 1, 2024

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant