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!

[ZJvandeWeg]

I think this should be an enterprise tier feature as team-tier teams generally don't have the number of members to deeply care about this feature set yet.

[gstout52]

Note from 20 May 2025 Summit - the only alternative to application-level RBAC is creating different teams and allocating roles at that level. But this requires making users Owners of multiple teams.

[gstout52]

Related: https://github.com/FlowFuse/flowfuse/issues/5191

[joepavitt]

Just beginning to break this task up into Design/Dev tasks and assigning accordingly.

[robmarcer]

This has been requested by https://app-eu1.hubspot.com/contacts/26586079/record/0-1/7835190239

[gstout52]

Proactively moving this and the outstanding sub issue to 2.22 with Nick and Joe both out.

[joepavitt]

@gstout52 I'd assigned this to Nick as his primary task. I am hopeful we can deliver something in 2.22

[knolleary]

I have raised two sub issues for the frontend - one to implement the UX for managing RBAC, the other to update all of the other views in the app to honor the RBAC settings.

[knolleary]

Following discussion with @cstns, we have identified #5974 as a pre-req to the UI updates. Have added as child tasks and scheduled them.

[cstns]

Here are the bugs I found so far during the e2e suite implementation:

Issues

• [ ] Dashboard role view doesn't filter out instances based on permission
  • should be filtered on the backend to not expose data

---

• [x] Dashboard counters for remote & hosted instances need to filter out instances belonging to applications without permissions
  • api counter methods should be updated
  • https://github.com/FlowFuse/flowfuse/pull/6055

---

• [x] (JP) Target snapshot button should be hidden for application viewer roles on the instance//devices page

---

• [ ] (JP) Device row in data tables should not show the finish setup button to users without permissions
  • the finish setup button is currently visible
  • https://github.com/FlowFuse/flowfuse/pull/6056

---

• [ ] (SC) User with an application role of viewer should not be able to update an instances target snapshot, register a device or select devices
  • currently the buttons are visible
  • https://github.com/FlowFuse/flowfuse/pull/6057

---

• [x] Instance version history timeline does not contain the creation of the instance as first event, (could be an e2e seeding issue)
  • the timeline should also expand to full height no matter it's content

---

• [x] (JP) Instances page 'create instance' button visibility should be dependent not only on the team role but also if the user has any application he's entitled to create an instance in

---

• [ ] Hosted instances list should also include instances belonging to applications to which he only has a dashboard role
  • these entries in the data table should only expose the dashboard button
  • the open editor button should not be present
  • the kebab menu containing instance actions should be hidden
  • the row should not be actionable on click

---

• [x] Create instance multi step form does not expose the instance next step when a user has a different application role than his team role

---

• [ ] Instances where the user has only the dashboard role should also appear in the hosted instances list, but they currently do not

Some are quick fixes, basic filtering involved some not so much.

[cstns]

quick update:

Remote Instances

• [x] (nol) Devices belonging instances that are a part of restricted applications are accessible when retrieving an individual device
  • fixind the backend to return a 403 for these devices will solve the problem
  • nol: fixed in https://github.com/FlowFuse/flowfuse/pull/5987

---

• [ ] (SC) Devices belonging instances that are a part of restricted applications are accessible when listing devices
  • the backend should not retrieve these devices

---

• [ ] 'Add remote instance' button from the remote instances page should only be rendered if the user belongs to applications that allow him to register devices in, not based solely on his team permission
  • this type of case begs the question if we should be pre-loading applications with a minimal data set but including the user's role in the application to evaluate

---

• [ ] There is no backend rbac application validation for devices for crud operations
  • for devices that belong to instances that are a part of applications with lesser roles
  • for devices that belong to applications with lesser roles

---

Generic

• [ ] updating an application role does not request an updated team role after changint an applications permissions
  • eg: updating own permissions to an application from the team overview rbac admin and then accessing the application in question, the previous permissions are still applied
  • this begs the question on how to refresh the ui (the backend will react accordingly) when a team owner changes the permission of somwone who is logged in (not critical, a hard reload will refresh the user's permissions)

---

• [ ] more of a question than a bug: shouldn't admins be able to bypass hasPermissions checks? especially when managing other teams? we're locking ourselves out the application rbac user access management page

---

• [ ] there's a discrepancy using the api/team/<team-id>projects endpoint when combined with query limits, in that when using query limits and filtering instances based on contextual application permissions the results could be less than initially requested in the queryLimit
  • forge/routes/api/team.js:372

Team Groups

• [x] the create team group button should not be visible if the user is not part of any applications in which he can create a team group
  • this type of case begs the question if we should be pre-loading applications with a minimal data set but including the user's role in the application to evaluate

Fixed application permissions on the fly

[joepavitt]

@cstns

Target snapshot button should be hidden for application viewer roles on the instance//devices page

As fas I can see - this works correctly already. I'm got a "Viewer" the logic works sound, and the buttons are not shown.

[joepavitt]

Device row in data tables should not show the finish setup button to users without permissions

This one too - already seems to be working?

[cstns]

I don't remember fiddling with them recently will have another look once i'm done with the dashboard counters

[joepavitt]

@cstns ignore i was working with a user already only at "Member" and then gave them "Viewer", so they never had the team-level rights in the first place.

[joepavitt]

Target snapshot button should be hidden for application viewer roles on the instance//devices page

This one definitely is working as expected already.

[joepavitt]

Instances page 'create instance' button visibility should be dependent not only on the team role but also if the user has any application he's entitled to create an instance in

Not convinced we need to handle this. Step 1 after clicking that "Create Instance" button is to view/select the Application. Unless somehow we have a Team Owner, who then has reduced permissions on every application, I can't see this being a problem.

[cstns]

I was under the impression that team members could also create projects/devices/applications when i wrote it down, just checked that's not the case, only team owners can create them. We can scratch it off

[joepavitt]

Instance version history timeline does not contain the creation of the instance as first event, (could be an e2e seeding issue)

Not seeing this issue when using the actual application.

[joepavitt]

more of a question than a bug: shouldn't admins be able to bypass hasPermissions checks? especially when managing other teams? we're locking ourselves out the application RBAC user access management page

That's a very good point

[joepavitt]

the create team group button should not be visible if the user is not part of any applications in which he can create a team group

Similar to above, I'm okay with this being shown. They'll quickly realise they have no applications in which they can dd Remote Instances when they have to select them from the "Application" list.

[joepavitt]

updating an application role does not request an updated team role after changint an applications permissions

I also saw this, but a refresh didn't fix the issue, I had to log out and login again in order to get the updated permissions taking effect on which elements showed and which did not

[knolleary]

Devices belonging instances that are a part of restricted applications are accessible when retrieving an individual device

Fixed

There is no backend rbac application validation for devices for crud operations

Need to clarify this. There was a gap for devices assigned to Instances in a restricted application that I've now fixed in https://github.com/FlowFuse/flowfuse/pull/5987 - but the checks were in place for devices assigned directly to restricted applications.

Have also pushed a fix to block assigning an unassigned device to a restriction application (or instance).

[knolleary]

Have pushed unit tests for the main device crud operations that cover rbac.