Roadmap reflections

[dahook]

Hi,

Jus saw that 2.5.1 is out - nice job

I found myself skimming through the Unimus roadmap, where I hoped to find some info on the since long mentioned enhanced RBAC model. Found nothing, but I did notice an upcoming feature "Device CLI" directly in Unimus.

I fear that Unimus is becoming something more than we, as an MSP, need. Even with read-only access, users can still run things like pre-defined config push templates, which could be an issue depending on what the template does. With a feature like "Device CLI" I fear that users that only need the product of what Unimus retrieves, i.e the device backup, might be able to gain access to more than they should. For some devices the actual Unimus user has way more permissions than I would like, due to limitations in the device permission model itself. If a simple user can gain RW CLI access to the running devices we will have to instantly replace Unimus with something else. The legal demands that are placed on us just don't give room for these kind of backdoors. As a minimum, such a feature should force the user to use personal credentials to access the device, and not the credential Unimus use to backup the device.

We have many low-level Unimus users that only need to get the latest backup, for example when replacing a faulty unit. Sure, I could create something that allows them to extract that, and only that, via the API but that is more work, and also something we need to maintain ourself. The Unimus GUI is already there and it is fairly easy to use without training. With a good RBAC system in place we can limit users to only what
they actually need. Both in terms of which devices they can extract configurations from, and which Unimus features they can use.

So please, give us a better way to control what the users can do!

Sorry for the lenghty post, and I hope my fear is unfounded.

Kind Regards,

//Dan

[Tomas]

Hi,

Jus saw that 2.5.1 is out - nice job
...
Sorry for the lenghty post, and I hope my fear is unfounded.

Hi, thanks for the feedback - those are all good points actually. Let me address them individually:

... Even with read-only access, users can still run things like pre-defined config push templates, which could be an issue depending on what the template does.

This should definitely not be possible. A user can execute a Config Push Preset only if:
1) they have write-access to Unimus itself (so Operator or Administrator roles)
2) AND they have access to all Targets of the Push (from Object Access Policies)

If you found a way to run a Push Preset as a read-only user, please le us know, that's a bug that needs to get fixed.

... I did notice an upcoming feature "Device CLI" directly in Unimus.

I fear that Unimus is becoming something more than we, as an MSP, need. ... With a feature like "Device CLI" I fear that users that only need the product of what Unimus retrieves, i.e the device backup, might be able to gain access to more than they should.

The Device CLI will be disable-able, same as you can disable Config Push all together. In fact, if you aren't using Config Push at all, you can disable that as well. Here is how: https://wiki.unimus.net/display/UNPUB/D ... s+features

As a minimum, such a feature should force the user to use personal credentials to access the device, and not the credential Unimus use to backup the device.

It's a very good question if Read-Only users in Unimus should have access to the Device CLI at all, and if so, how should they auth to the CLI. I will discuss with the team, but I agree RO users should not be auth to device by default. I think the best option would be that Operator/Admin accounts are auth'ed to the device by Unimus automatically using the device credentials, but RO users needs to explicitly enter credentials to login to the device. Denying the CLI to RO users is also a way - we will need to pick one of these.

I found myself skimming through the Unimus roadmap, where I hoped to find some info on the since long mentioned enhanced RBAC model. Found nothing, but I did notice an upcoming feature "Device CLI" directly in Unimus.

Just a note on how we pick features to the Roadmap - it's about 50% from community demand, and 50% by what we think should happen in Unimus next. We do yearly community surveys (last survey went out just a month ago actually). Quite a large set of community were requesting a way to access the Device CLI in Unimus, so we made it into an official feature.

I found myself skimming through the Unimus roadmap, where I hoped to find some info on the since long mentioned enhanced RBAC model. ...
Sure, I could create something that allows them to extract that, and only that, via the API but that is more work, and also something we need to maintain ourself. The Unimus GUI is already there and it is fairly easy to use without training. With a good RBAC system in place we can limit users to only what they actually need. Both in terms of which devices they can extract configurations from, and which Unimus features they can use.

I agree we need to improve the existing RBAC with the ability to create custom roles and control what those roles can do. There is no reason you should HAVE TO create a 3rd party UI and use the API if all you need is to have users that can only get to Backups.

This year we did A LOT of work on the Object Access Policies, which massively improved the object access controls in Unimus (a bunch of info on that can be found here). Quite a few users were asking for this.

As for RBAC and custom Roles - I will discuss with the team if we can get this into the Roadmap for next year.

[dahook]

Thanks! That was a very detailed answer, I will try to find time in the near future to read it again since I am a bit pressed for time this week. I think you covered it very well.

One more thing that came up in my head, not related to the roadmap but to our way of working with Unimus, is credential discovery. I would like to disable that completely. With hundreds of zones (customers) and where we don't always know the security level of the devices there is a risk that credentials can be leaked. Also, we experience that (mis)configured devices that uses credential discovery leads to locked accounts in TACACS which can be an issue.

[dahook]

As a minimum, such a feature should force the user to use personal credentials to access the device, and not the credential Unimus use to backup the device.

It's a very good question if Read-Only users in Unimus should have access to the Device CLI at all, and if so, how should they auth to the CLI. I will discuss with the team, but I agree RO users should not be auth to device by default. I think the best option would be that Operator/Admin accounts are auth'ed to the device by Unimus automatically using the device credentials, but RO users needs to explicitly enter credentials to login to the device. Denying the CLI to RO users is also a way - we will need to pick one of these.

Comment on "I think the best option would be that Operator/Admin accounts are auth'ed to the device by Unimus automatically using the device credentials, but RO users needs to explicitly enter credentials to login to the device.".

In our world all non-M2M logins need to be tied to a personal account. Piggybacking on the Unimus backup account makes it harder to find out who logged in. Sure, we could trace back and see who was logged into Unimus at the time but that is more work. I think an option to force all users to use explicit credentials is required. Same for config push, where the is an option to selectively use explicit credentials. It would be nice with a way to always require explicit credentials.

I find myself holding back the urge to create a config push "write erase", "reload" on all devices almost every week

[dahook]

... Even with read-only access, users can still run things like pre-defined config push templates, which could be an issue depending on what the template does.

This should definitely not be possible. A user can execute a Config Push Preset only if:
1) they have write-access to Unimus itself (so Operator or Administrator roles)
2) AND they have access to all Targets of the Push (from Object Access Policies)

If you found a way to run a Push Preset as a read-only user, please le us know, that's a bug that needs to get fixed.

My bad, you are indeed correct. I must have messed up when I tested that.