I'm afraid that I've lost track now of the origin of this thread so I'm struggling to follow. It would probably further the conversation to outline the different persona's - what different use-cases are you thinking about and what different access would they have? Start from the desired outcomes and work backwards.
System Admins
Node-RED Flow Developers
Users of Node-RED apps (e.g. consuming the output of flows)
Anything else?
A user probably shouldn't have access to the Editor anyway and if so, they wouldn't be able to download a flow.
A flow developer has access to the Editor which can be protected with a login - ideally the flows and related files should be further protected with something like GIT and an automated commit on deploy process so that changes can be undone. But unless you block access to the filing system, developers have access. I think that you could in fact protect the FS as well since you could apply ACL's to the files that would only let the system user running the Node-RED service have access to the files.
Julian,
I would really love to be as efficient as necessary. I guess I'm missing the format which to disclose this information. Apparently I'm describing it to the n'th degree, but for some odd reason the mission is escaping. I need a "super user". NOT an admin, NOT a user, but something in between.
So, thank you for assisting with it. If I can get this from my head to yours as complete as possible, that would be a good start point.
System Admins. Have complete control of programming and assigning levels within flows of being available for the levels under admin.
Node-RED Flow developers fall into 2 categories apparently. I tried to designate them by "Admins" and "Technical Support". There is a need to "develop" per se, which is to modify a flow that is attached to a device that may need modification or the device itself may change it's particular configuration. Typically this is not done, but in cases where a device needs to have it's configuration checked/ changed/ troubleshooting, then access to this is desired. For these purposes it is a "desire" to let this category only have access to these devices and/or I/O configuration flows.... or any other flow which is necessary etc. This keeps them out of the main program which integrity needs to be maintained.
Users of Node-RED apps. these do not even need access to the editor page at all obviously.
On the surface, if we can block the access to the editor that is adequate for myself. That is the very reason which I have need to ask the community for better definition. The offering of security brings with it more complex issues if you do go beyond just the editor. My assumption is that anything can be hacked. The level of hacking is only those who will use the current editor. I have no need to go beyond that for this reason.
If it is best designed with concurrent instances for the purpose of adding security to the files themselves, then maybe a concurrent instance is really the best option. And pursuit of "flow security" is best handled by dividing up the application into different instances which this is now an option.
As I think about it. It would be good to categorize the flows for better organization. You can expose flows, under whatever condition you desire to help you work in your area. Almost all the projects I have done have more flows than I can see at any given time. I need to scroll across the screen to get to them.
If by chance this "Flow Security" discussion can morph into something useful just for development and debugging, then it can also be useful for my needs. As this last post, The need for a super-user may not be exactly the way to approach it. It could be good if I can just expose a category which the "Super-User" would be interested in and they would just leave the other categories alone anyway.
Can we filter flow tabs? The same way you filter the node pallet? and then perhaps use the browser URL to force this filter on open?
Sounds like a Node-RED admin to me. I would probably think of a system admin being the person responsible for the underlying OS.
OK, this seems to be where things are getting confused? It isn't clear what the separation of access is here. There appears to be a mix of roles.
Yes, that is exactly what I'm thinking. I believe that any other approach will add significant complexity to Node-RED to cover an edge-case.
If there are aspects of device configuration or logic that some people should not be able to see or possibly not be able to change, these should be in separate instances with different security settings so that separation is enforced at the security layer (OS/FS).
This is security best practice anyway. It is also easy to achieve in an OS like Linux. And of course, Node-RED excels at communications over multiple channels so linking the instances together is trivial.
Where this may fall down is in the case of running Node-RED on small, low-power devices where multiple instances might not be achievable. But in that case I personally don't think that Node-RED is the right answer. In that case, I would advocate using Node-RED to do the prototyping of the logic that needs to be secured and then translate it into something that could be separately protected and run more efficiently. Maybe a full-blown rewrite into C++ or Rust, maybe GOlang or even a dedicated Node.js service. Then you can layer on Node-RED for less sensitive use. I suspect that this is the kind of approach that someone like Siemens might take for example.
OK - my 5 cents on this: I think it got mentioned already a few times in this thread - multiple instances of Node-RED with individual security settings could be a solution / temporary workaround until a more fine grained security concept gets implemented.
And this just became a bit easier with the release of Shuttle-RED:
It allows to start, stop or restart instances of node-red from within node-red itself. So one could have a controller instance and then child-instances offering functionality to several user-groups with different rights. Communication between the controller- and child-instances is easily implemented with Shuttle-RED's message in and out nodes and therefore (indirectly through the controller instance) also between child-instances.
Please keep in mind that this is the very first release of Shuttle-RED. Anyway it is exactly one of the use cases why we developed it.
In the "Shuttle-red" brief, it states as a disclaimer that it is "not recommended for production". This is a production role for these instances. When do you think it can be available for "Production" environments?
All of my instances are started by services I installed by using NSSM. If I need to start/stop/restart instances I would normally use a system service call.
SC QUERY [service]
NET START [service]
NET STOP [service]
NET PAUSE [service]
NET CONTINUE [service]
Does this interact with the services? or just manage them on command line? Would I need to abandon the windows service except for the main controlling Node-RED instance for the master?
Good point. And to be honest: I don't know. But I guess it is more production ready then an enhanced security feature being just considered.
We consider Shuttle-RED feature complete for version one and do not plan on introducing any breaking changes at the moment. But of course we cannot guarantee this. So you might want to consider forking the project before integrating it into a real life project so you have a stable snapshot in place.
The two things missing are documentation and testing - that's why we added the disclaimer.
It should be kind of stable though (if there is such a thing as "kind of stable" ) as it does no big magic in the background. But as said: We have not yet tested it extensively.
You might want to consider testing it and giving us feedback. The more it gets tested the sooner we have a "real" stable version ready for production.
The thought behind Shuttle-RED is that only the controller instance gets installed as a service and this controller instance then starts (and controls) all other instances.
What it does in the background is that it runs NR as a child-process pointing to the project it should run (using a symbolic link). So it should be quite straight forward to replace the service with Shuttle-RED and vice versa.
Shuttle-RED has some advantages over the services though: You can easily configure environment variables from within NR and the control over the instance gets more fine grained. You can even start different projects with different NR versions. And you can communicate between the instances (this would break the way back to a service based approach though).
Well, that is a very good point... except that I have abandon my request for the developers of Node-RED to actually implement any more levels of security for the purpose of a single instance with policies that will disable access to a flow. Thus, option 2, instances...
Also, when we go to multiple instances, that is a viable solution that I can manage very well with the tools outlined by the Node-RED team.
Flow Filtering is something which I believe is a concept Nick and the crew should embrace, but I do not think it is a high priority. My suggestion in a similar discussion on hiding flows, does that but works very much like the filtering already there for the node palette. Maybe just doing the same to filter flow tabs. That really is my goal anyway. I can use both instances to refuse editing and filtering to enable a simpler look to the program, if it is implemented.
BTW: One thing we didn't test so far but which should work is that you can run the same project several times and / or within different NR versions. This would allow to test a project on a new version before upgrading the production version to the new NR version. Or you could run the project with different parameters (through the environment variables).
Sounds slightly unfair on "the developers" - as an open source project, there is, to my knowledge, only a single full-time developer working on Node-RED. So if you are able to work on robust additions to the project, I am sure that Nick and others who are the guardians of it will be very welcoming once the design details have been hammered out. But there are a lot of ideas and improvements to Node-RED that are already on the backlog so unless more people step forward to assist, it is simply going to take a very long time for more complex changes to be able to be worked on.
I believe Nick is going through a role-change and may be getting some more funding which may help but too early to tell perhaps yet. Certainly there seems to be some new focus on industry integrations which may well help certain features to move forward more quickly.
Julian,
OK unfair for the developers? isn't then Read-Only access equally unfair? I think we need to define developers? First there is a group which in this case is not qualified to be true developers because they are not "administrators". But have strict privilege (I guess you can call it) to perform maintenance. They are a secondary group which have the function of maintaining. The core flows/nodes are signed off as "accepted functionality". If I submit this area to everyone who happens to have access, then I cannot guarantee "accepted functionality". I realize that this is limited anyway, but at least I have a group who is directly responsible for their actions because they are a limited group which have been given "administrator" privilege. The secondary group being responsible for maintenance.
This is very much unlike open source for the development of Node-RED itself. It is a signed off function which we need to control changes to it. You do have administrator or Read-only in the system.... right? It is only a tier between these 2.
Node-RED is what it is until someone develops it further. If you need something to change in order to meet a commercial need and it isn't happening fast enough, you need to help make that change happen by providing resources one way or another. That is how open source development works.
Maybe I'm confused on an important topic, but why is it that I need to concern myself with the community of developers with my program? And who I allow access to it? Clearly there is a means to have Read-Only access. If that violates the community, then they can copy the program in other ways. Why should I not have the right to hide sections of it from anyone? for at least expediencies sake?
My customer wants to maintain the core functions' purpose, they want to ensure that we can limit access to it so it can continue without question that the function does not change.
You were talking about the possibilities of changes to Node-RED to facilitate a feature set that you wanted to use. But then were saying that you had "given up" and that Nick and others should "embrace" your suggested approach.
So what I was reminding everyone was that Node-RED doesn't have an army of developers and if something needs to change, someone needs to facilitate that. Or, as you are doing, you need to work around it.
It felt to me that Node-RED developers were getting some form of "blame" for not doing things (fast enough).
You have (hopefully paying) customers to service and you have to decide what is best for your business and your customers.
Earlier I responded to someone who said that hiding flows violates the "open source" agreements.... That's where some confusion came up about if there were "programmers" vs. "developers" who could not get to a flow for some reason. I was trying to address his/her comments and should not have used their term "developer". I see the error of my way.
I would be a developer of "Node-RED-contrib-tanklevel" which i submit to the community if I went that far. I just use Node-RED.
Developers will need to add a feature to Node-RED. Not me. The feature is to allow to not show a flow...
I can use the feature as a "programmer" to not allow a "user" to see the flow. Not having seen my flows perhaps would be a good thing and the community would be the better.
Julian,
No, I'm pretty sure that I have a deep respect for anyone who knows more than I do. Developers, Owners (Nick) have my deepest respect.
I'm not a developer. I'm a programmer. I use and have used Node-RED and it has really benefited me and my team in the past 2 years we have used it. The system is easy to use and easy to get working programming done faster than we could have on any other platform. Hands-Down!
I work with is on a daily basis and I am learning and getting valuable resource information from this site. You have helped me resolve problems more than anyone who i can name. Thank you and keep up the good work. I'll continue to use these resources and try to define my needs better.
I concur a wholistic view of the authorisation/security/view models would be a great idea. There is lots of room for it to be enhanced
Having said that I know this is big and quite possibly hard to do on such a rapidly evolving product .
My experience is using docker to run multiple instance for different purposes is ideal, docker is lite and it just works. I give only users who need access to instances either UI or dashboard. It takes some work to maintain and is not perfect but it does work pretty well.
For my VPN (90% of access for users is via the VPN) is using the great product tailscale. Its s pretty easy to define ACLs which work for me.
I am building tooling around it (I currently run 4 -6 instances in production ) and managing them is a bit of a challenge. The admin API does support a lot of what is needed so I will be focusing my efforts there.
Certainly. I think there are things in the security discussion that make addressing hiding flows by security make it very big. Maybe it's time to take a step back and be sure that it meets the demand for a single instance to have barriers to keep those in the editor away from some flows. Maybe this is best addressed with multiple instances even if they are a bear to manage. I would like to see it go forward only if it really meets a need, otherwise it may never be used.
As it is now, I hope "Flow Filtering" could gain some ground, I can use "multiple Instances" easy enough for my purposes now, but I would like to be able to limit the view in the editor to the subject matter I can control with filtering flows.
This is exactly our requirement, too. We need to have some sort of level of access for users, like for example admin will have full access while some users will only be able to view some flows but not the other flows and properties of each node. We are looking to interface node-red with some of our sensors and definitely making critical configurations visible is not allowed. We have:
admin users - full access
on site engineers - change some parts of the flow/node, import/export flow but not allowed to view critical flows of the system
client user - view the flows just for basic troubleshooting
There are multiple ways to hide property values but what if we need to hide some logic. I understand there is shuttle-red for multiple instances but the difficulty will be on how we can manage with our less technical users (on site)? And, it is also still not for production. Keeping track, managing and deploying this will be a huge task specially as we expand the system. Having a switch for the admin to hide some tabs/flows/nodes and assign viewers to users will be the most suitable use case and safest (in terms of operability) for our requirement.
I know, to achieve really high level of security we might as well develop our own system but we have one already, it is working and secured, but we are trying to a achieve cross platform compatibility, a fully independent system and node-red seems to be just the perfect tool to achieve this with minimal cost on time and developers.
I know, implementing this will need some time and thorough analysis but still I hope it will be considered. We are loving node-red more and more and it would be a shame not to push through with this project. Meanwhile, I am looking into existing features and shuttle-red if it can be a workaround but I still hope this I idea will not be dropped.
) as it does no big magic in the background. But as said: We have not yet tested it extensively.
