User Account Token-Specific Access Privileges

[mihkuno]

Suggestion to add token-specific access privileges on the user account.

So that when enabling the environment limits functionality and enhance integrity.

For example

Default Token: Full admin access
Token 1: Can modify apiEndpoint, allow view status
Token 2: Share private tunnels only, allow view status
Token 3: Access only, cannot view status

This is useful when you’re using device1 and your friend uses your own device2, which is already set up.

It helps prevent them from tampering with your already enabled environments setup. Even when the the .zrok configs are local, something like changing the apiEndpoint is a huge man-in-middle security flaw on device2 without you knowing.

[michaelquigley]

Will give this some thought. zrok isn't necessarily designed to provide security features to control permissions inside the same account. It's kind of assumed that if you have access to the account, then you're the owner of the account and can access everything in that account.

If you're trying to provision a device/environment for someone else to use, you would want to create an account for that user, and use that account token to enable their environment... and from there you would use inter-account permissions to control these things. If all the provisioned environment needs to do is access a share, then an account for that user with a zrok access already does this today.

[michaelquigley]

There's also a planned feature to implement "organizations" #537 ... which might also cover the use case you're describing.

[mihkuno]

Accessing through a separate account is actually a good alternative. Btw can zrok invite be simplified to zrok create to email->passw->receiving the token in email instead of receiving a link for create the account on the api site.

On second thought the custom tokens is possibly difficult to implement. The point was some sort of elevated access.

Here's other suggestions:

• zrok should ask for a password/token of the account like sudo in linux. The api will have a "some command: require sudo" checkbox. Make a request every command, server then validates if requires sudo the it alongside token.

• .zrok config folder generated system level like in C:\Program Files (x86) or otherwise provide a custom zrok enable --config-path or --owner to just change the folder properties to require admin as shown below. This way, it cant be tampered since files in it always requires admin privileges to be edited.

[michaelquigley]

These things are potentially tricky and problematic to implement. The idea is that if you have permissions on the filesystem to read/write the ~/.zrok folder (or Windows equivalent), then you own the environment. Trying to provide different levels of on-host, in-environment security is outside of the scope of zrok. Most Windows hosts are accessed and used by a single user.

We have finite development resources and need to budget carefully where we invest time and effort into features for zrok. Right now, the new "zrok daemon", remote management, and the new user interface components are all at the top of the list. We're not necessarily going to be making big changes to the zrok model, just working to massively improve the quality of life with the things we currently provide.

[michaelquigley]

...and we can eventually look other ways we can bend and stretch the model once we get past the overall 1.0 milestone.

[michaelquigley]

Also, if you'd like to discuss feature ideas... you might want to check out the zrok category on the OpenZiti Discourse. Much more of the team is over there..

https://openziti.discourse.group/c/zrok/24