exactly that indeed

great idea with the setting

I think this needs more protection not less - dashboard could have 2FA on login - and perhaps each network should have a shown once resettable 'master key' - and you need to enter that key to modify a network - once you enter that key - yes show the tokens and be able to do whatever on that network. As things stand it doesn't really matter if you show the token or not as anyone with access to the dashboard can go ahead and make new keys and mess around anyway. Whatever the decision some consideration should be made towards a longer-term RBAC system whereby people with particular roles have particular rights to view / modify a network and its nodes. Potentially in the future end-users are able to login to dashboard and see tokens only on specific networks they are allowed to access - or view the access tokens they are assigned to see - so that they can self-service adding new nodes / new external clients. Additionally tokens could auto-expire after a period of time for joining of nodes - in which case show the token - but it is useless after a while. Or tokens are only valid if when you join you enter a valid 2FA or network password in which case it doesnt matter if the token leaks. e.g. are you clearing out shell history on nodes after joining ? The API idea is also gold - this would allow a mechanism to script the addition of nodes on cloud-init etc.

While yes a RBAC system would be good in the long run, I highly doubt a resettable master key is going to be the answer here, at least it would be a stopper for me 😉 As I'm def not going to be writing down 10 keys for 10 different networks. And that depends entirely on if you have access to all networks or not, otherwise you will only see assigned networks, not all of them as that option is already there. not sure where you get the less protection from as option 1 is how it is already is right now, and option 2 is safer or not less safe as option 1. the 2FA yes, I can agree on that, hence once I rebuild one the admin password for now is just going to be an enormous password (lol), and integrated with Azure where I ofcource have 2FA.

Currently we have “admins” which are superadmins, and “network admins”, which are like superadmins for specific networks but cannot view any other networks. We plan to implement “network users” as a final level of rbac, which will have a limited number of nodes/access keys allowed, and will only be able to edit their own nodes. @cold-camera-7160 I think this addresses what you are talking about

Agreed as well that 2fa in general will be good to have at some point

True, 2FA would be really great to enhance the security.

very simple solution to the keys issue that took about 5 minutes to implement. There's now a DISPLAY_KEYS env var. If it's on, the API will return the real key values / tokens . If it's off, it will return the key name and uses, but sensitive info will be placeholder text: KEY_VALUE and ACCESS_TOKEN

thanks @User for suggestion

🙂

@here we now have a functioning FreeBSD client, which will be in the next release. It would be great to test this on OPNsense or pfSense, if any of you happen to run a router with that.

I have a open WRT router I think

OpenWRT we have been able to test and are good on, but thank you

oh ok great no problem 🙂

so if I want to rebuild it for the new version to use caddy and such, should I first uninstall all clients?

that should not be necessary, the server changes are pretty minor. That said, previous upgrades have caused conflicts so we'll have to see.

I actually meant really rebuild it lol, throw away this old docker file and such

any reason why the new version says ui:0.8.0?

the new version isnt out yet, we're still working on it

and the UI doesn't track with server upgrades, so sometimes the UI is older than the server

I get that in 0.8.5 🙂 (i know I'm a bit behind)

seems to work fine again! now I have a clean docker setup using caddy

🙂

nice! just in time for the next upgrade lol

jeez hahaha

checking dependencies... OS unsupported for automatic dependency install lol

does look like the macos one doesn't work anymore

2021/11/15 22:30:15 [netclient] joining internal at grpc.nm.linservers.tech:443 2021/11/15 22:30:20 [netclient] error installing: rpc error: code = Unknown desc = Key: 'Node.Name' Error:Field validation for 'Name' failed on the 'in_charset' tag

Yeah that’s an annoying part of the new “host name” based names

In the next release we’re gonna clean up the name automatically