Granular RBAC for Instances and Devices

[MarianRaphael]

User Story

As a FlowFuse Team Owner,

I want to assign user privileges on a more granular basis, specifically for selected Instances / Devices,

So that a user can access and modify Node-RED instances and Devices, but only for the selected application scope.

Scope

• In the User Management overview, the Team Owner can select whether the privileges are valid for the whole team or only for specific Instances. If no application exists in the team, the more granular selection is not possible.
• No additional RBAC roles, just the application-based limitation
• A DevOps pipeline should be executable only if the user has write permissions for the given target.

Have you provided an initial effort estimate for this issue?

I have provided an initial effort estimate

### Tasks
- [ ] https://github.com/FlowFuse/flowfuse/issues/3120

Requested By:

• https://app-eu1.hubspot.com/contacts/26586079/record/0-2/8175387106

[joepavitt]

Is this a customer request? This level of granularity starts getting very messy, very quickly... Does a user that doesn't have the permissions still see the list of devices/instances at the top team-level view?

[MarianRaphael]

@joepavitt Yes it is a customer request.

This level of granularity starts getting very messy, very quickly...

Absolutely agree, this is why the UX concept needs to be good :D

Use Case

You have a Production and a Staging Node-RED instance/device. A selected group of admins should have access to both, while another group of developers should only have access to the Staging instance. Consequently, only admins can execute the pipeline.

[MarianRaphael]

Follow-up: https://github.com/FlowFuse/flowfuse/issues/3139

[MarianRaphael]

[hyamanieu]

I believe the origin of the issue is three-fold:

• that an application is bound to a single "team", under which you have 4 roles with fixed rights, and none of these rights are about the deployment process.
• the "project" node triplet is a very nice feature, but is only available for instances within the same application.
• conflicts arising when parallel work is done on a single instance (common Node-RED trouble unrelated to FlowFuse :) )

IMHO, managing code within Node-RED instances should be seen as managing code in a software application, following basic git-flow.

For example, if we want to have three level of instances for a specific pipeline:

1. a single "main" (or "production") instance
2. a single "develop" (or "staging") instance
3. as many other instances as there are people working on new features for this pipeline, like branches

At the discretion of the administrators of the team, there must be a review process to go from 3 to 2 ; then from 2 to 1. According to me, the most important is to be able to go into 1, there should be at least one additional person, a reviewer, signing off the changes, which is what #3139 is about, albeit it mustn't be necessary reviewed by an owner. Eventually, specific instances (e.g. at degree 1) may be modifiable only for "owners" (this issue).

As you made it possible to have several pipelines under a single application, this means that there can be several "main" instances with different goals. Typically, we can think of an application with 3 pipelines:

• One for common ETL
• One for PLC to PLC communication (in other words: control, which is critical)
• One for dashboards

One instance may be using data from another one: think how extracting data from a PLC is usefull to be recorded , but also to communicate to another PLC or to be shown on a dashboard. We can let the automatic technicians do the extracting with the PLC and communicate it to the other ones. In this configuration, we can see how very different teams would be involved in one or the other. Which explains the level of granularity where both roles and groups under the same team are needed.

The work around is to have different applications with different teams with the same people, but different roles. Here we'll be losing the "project" node triplet but I think it's fine. Anybody can make Rest-API.

---

To sum it up:

1. I believe the review process is the most critical as mentioned in #3139 , where each change going into production must be signed by at least 2 people.
2. I believe having a simple user right configuration where only "owners" may modify specific instances comes second, but is still mandatory: very specific people should have access to code controlling PLCs! (This issue).
3. A higher level of granularity with roles & groups can be achieved by creating additional teams and exchanging data with MQTT or a Rest-API, so it's optional.
4. Having "as many other instances as there are branches" is a serious change in your business model and is not mandatory, so it should have , in my honest opinion, the lowest priority.

3 & 4 would require their own issues, but according to me it all belongs to the same story: how to have nice development environment and safe deployment pipeline with Node-RED?

[SynoUser-NL]

Hi,

Was just referred to this thread in reply to my question: https://discourse.nodered.org/t/devops-pipeline-instance-access/88235

In general, in a DevOps pipeline (i.e. an OTAP street) the people building a solution are not the people that are testing the solution, and those are not the same people that are using the solution. So there is a need to control access to each stage.

Hope there is a solution in the works for this.

Thanks!