Feedback - this is a great idea
cameronbraid opened this issue · comments
I couldn't find any other forum to post feedback so I though I would leave a comment here.
I think that drago is a fantastic idea.
Id like to build something based on drago to run in my bare metal kube cluster and use https://metallb.universe.tf/ to expose services to developers.
Also, using a tool like drago as a base for implementing a VPN will mean no more having to update peer configs on all the peers when a new peer is added - fantastic.
Would be great to combine this with https://github.com/asticode/go-astilectron and https://github.com/kardianos/service to make a cross platform GUI VPN client
Are there plans to implement auth for the management api endpoints, something like oidc ?
I think that drago is a fantastic idea.
Thanks a lot for the kind words! I'm glad to hear that you too see potential in Drago.
Id like to build something based on drago to run in my bare metal kube cluster and use https://metallb.universe.tf/ to expose services to developers.
Cool! Can you share more about this setup? Where do you plan to run the bare metal nodes? Do you need to manage who has access to the VPN? Do you need to maintain different network environments? Any other requirements you can think of?
Would be great to combine this with https://github.com/asticode/go-astilectron and https://github.com/kardianos/service to make a cross platform GUI VPN client
It would indeed be super cool to have a cross platform client. This could be implemented as you described, or by having the client daemon serve a configuration (web) UI. In the near future we will be also adding more CLI commands soon for facilitating the configuration. Maybe we can sketch some specifications together based on your requirements. Feel free to share your thoughts on this. Of course, if you still think there is need for a desktop client, and decide to start building this, we would be happy in supporting with anything we can.
Are there plans to implement auth for the management api endpoints, something like oidc ?
Yes, we do plan to implement authentication for the management API. Actually, this is quite important. We are considering OIDC, but remain open for suggestions.
Cool! Can you share more about this setup? Where do you plan to run the bare metal nodes? Do you need to manage who has access to the VPN? Do you need to maintain different network environments? Any other requirements you can think of?
It's a pretty simple setup, currently a single node, hosted at ServersAustralia. We were on IBM cloud with a 3 node cluster for a few years but due to a downturn in the travel industry (covid19) we had to scale back costs, and plan on scaling back up.
I used to have a ZeroTier VPN to connect some developers to the cluster. ZeroTier has been quite a simple VPN to run, having desktop clients and a web ui for configuration. But have had some issues with it (it does strange things with ARP which prevents metallb working with it). I've now setup a WireGuard VPN and its working well and I'l working towards switching over.
The main thing I need is an automated client - where someone with less technical skills can run a desktop binary, paste in some data and then the config is managed for them - Drago !
Do you need to manage who has access to the VPN?
Yeah though I think I can do that by controlling who I issue tokens to? Is there a way to revoke a token ? Or is the plan for tokens be short lived and automatically renewed ?
Do you need to maintain different network environments?
I don't but I would imagine that other users would want this ability.
I think the Drago client agent needs to support #21
a) work well with other wg based vpn configurations (not clobbering other wg devices)
b) to support more than one configuration/token/server at a time - e.g. connect to my cluster's VPN, as well as some another Drago VPN - may need some logic in the daemon to detect routing conflicts and warn the user
I would think that the desktop client would be pretty basic.
- would install the daemon (linux-systemd, osx launchd etc..) when started
- would provide a means to uninstall the daemon
- would provide status of running configurations
- would provide a way of setting up a new configuration
- would use a http/grpc api to talk to the daemon
I think the simplest idea for on boarding a new VPN user is
- I would create a new token for the VPN user
- I provide the token to the VPN user out of band
- the VPN user runs the desktop client and pastes in the token
- they are connected
I would think that token can contain the Drago server URL, and a user friendly name of the VPN, as claims so that there is no other metadata required for the VPN user to enter.
Id like to build something based on drago to run in my bare metal kube cluster and use https://metallb.universe.tf/ to expose services to developers.
Would love to hear more about this as well nvm, you already answered
I for one would love to see drago as an operator which could seed kubernetes edge workers. Something in combination with metal3
This could be killer functionality for the cloud-native space as it approaches SD-wan like functionality (especially with your roadmap with discovery and auto assigned IPs etc.)
Am now leaning towards using https://wails.app for UI
I for one would love to see drago as an operator which could seed kubernetes edge workers. Something in combination with metal3
This could be killer functionality for the cloud-native space as it approaches SD-wan like functionality (especially with your roadmap with discovery and auto assigned IPs etc.)
Could look to integrate with https://github.com/squat/kilo ?
At the moment using metallb and a CIDR that is within my WG VPN, I can create a LoadBalancer Service and access my services via vpn. Works well.
Could look to integrate with https://github.com/squat/kilo ?
Oh my that looks interesting, thanks!
I have some reading to do this evening.
/update Kilo would need some work in my case since I rely on Calico.
@cameronbraid thanks for the detailed description.
The main thing I need is an automated client - where someone with less technical skills can run a desktop binary, paste in some data and then the config is managed for them - Drago !
I understand. Do you need a desktop client, or would it be ok to have the (simple and easy to install) Drago client serve a configuration UI on a specific port for the less technically skilled user to access? More advanced users would still be able to configure everything through the CLI. I'm asking because adding an UI to Drago in the way you're describing is out of scope, and from my perspective should be done in a separate project. If you agree with the option involving the client web UI, it should be relatively straightforward to implement, depending on the configuration options you need. I assume that at first they will simply involve pointint the client to a Drago server and providing it with access credentials. Would you kindly confirm this?
Yeah though I think I can do that by controlling who I issue tokens to? Is there a way to revoke a token ? Or is the plan for tokens be short lived and automatically renewed ?
Yes, sounds good. Token revocation will be implemented in the next week or two, but we will still allow for configurable expiration times, even for management tokens.
I think the Drago client agent needs to support #21
I completely agree. @mkwinter is already working on it. Should be done in 1-2 days.
b) to support more than one configuration/token/server at a time - e.g. connect to my cluster's VPN, as well as some another Drago VPN - may need some logic in the daemon to detect routing conflicts and warn the user
This could be accomplished by maintaining a local configuration for additional interfaces which are not managed by the Drago server, and letting users alter it from the client (web?) UI. Unless you need to be able to synchronize these interfaces and want to eventually be able to manage them from the server as well.
I think the simplest idea for on boarding a new VPN user is...
Agreed.
I would think that token can contain the Drago server URL, and a user friendly name of the VPN, as claims so that there is no other metadata required for the VPN user to enter.
We're currently keeping information required on the client side as configuration, and issuing claims only for what's needed on the server. In this scenario, the client would have to be configured as below:
client {
enabled = true
data_dir = "/opt/drago/client"
servers = [ <server_addr> ]
token = <jwt_token>
}Does this make sense to you? Do you see any issue?
@hansbogert kilo seems to be what you're looking for. I suggest you watch this introductory video. The goal is quite similar to Drago, but as you'll see, the approach is different.
I understand. Do you need a desktop client, or would it be ok to have the (simple and easy to install) Drago client serve a configuration UI on a specific port for the less technically skilled user to access?
That would work
More advanced users would still be able to configure everything through the CLI. I'm asking because adding an UI to Drago in the way you're describing is out of scope, and from my perspective should be done in a separate project.
Totally agree
If you agree with the option involving the client web UI, it should be relatively straightforward to implement, depending on the configuration options you need. I assume that at first they will simply involve pointint the client to a Drago server and providing it with access credentials. Would you kindly confirm this?
Yeah I think a single page that has a server url and token text input and a enabled/disabled switch should be enough
b) to support more than one configuration/token/server at a
time - e.g. connect to my cluster's VPN, as well as some another Drago VPN - may need some logic in the daemon to detect routing conflicts and warn the userThis could be accomplished by maintaining a local configuration for additional interfaces which are not managed by the Drago server, and letting users alter it from the client (web?) UI. Unless you need to be able to synchronize these interfaces and want to eventually be able to manage them from the server as well.
Was more thinking along the lines of running two instances of Drago client. I guess it can be done by running two Drago clients with config server on different ports and configuring each independently. May need a config option to support generating unique wg interface names though.
Does this make sense to you? Do you see any issue?
Makes sense - thanks - no issues there.
I'd take it that when token rotation is in use the client daemon will update the config with the new token ?
Was more thinking along the lines of running two instances of Drago client. I guess it can be done by running two Drago clients with config server on different ports and configuring each independently. May need a config option to support generating unique wg interface names though.
That would work too. Regarding the unique names, after discussing #21, we are now considering using random names for the interfaces (e.g. dg-ztbpacyvps) and assigning aliases corresponding to their name on Drago to each of them. This would help us avoid collisions, still be able to filter interfaces based on their names on the Drago server, and circumvent the maximum interface name length imposed by the system.
I'd take it that when token rotation is in use the client daemon will update the config with the new token?
Yes, that will be necessary.