@knolleary,
Our current need is an industrial iot application. The system needs to talk to PLC's, and SQL databases, output files, pretty much the gambit of an industrial monitor and data collection application. The app is currently in a C++ environment and it has a scripting language that is custom. Modifications are typical and I was searching for an alternative which the "scripting" could be simplified and replaced by some sort of graphical programming. With Node-RED, it seems to offer almost a perfect fit and enhance it with multi-station user interface and remote debugging and programming. The interest in the tab level security is that the base of the program needs to have a CORE administrator level, which defines the app and user interface. The second layer needs to have "Engineering" level access and then possibly a layer for "Technicians", then Operator is the default open level. If at all this kind of layers specific to tabs, for instance would allow us to deploy this in plants which do not have or need direct CORE level or "Engineering" support, but do allow the 3rd and 4th layers to access and configure all of the channels to support adding barcode readers/printers/weigh cells... and the logic for each. I have designed a beta using Node-RED for proof of concept so far. We are in load testing device connections and reliability now. Our next hurdle would be the security requirements. There may be options which would include a base program written in some other language and utilize Node-Red API for the device connection and logic layer. However, using a completely Node-RED environment is attractive.
I expect you've thought about this but what about having more than 1 instance of Node-RED? Perhaps one for each level?
Then you can easily enforce separation between the layers - even at a networking level if required. You would of course need to think about communications between them but that is rarely a problem for Node-RED given its ability to talk over many different protocols.
Yes, Multiple Node-RED instances. Thank you for that suggestion. We are now in the process of using the current C++ environment which can be installed on Windows 10 and integrating it with Node-RED in the background and using TCP/IP to update the user interface. This perhaps is a variant where you can have a user interface and base level app then connect to it's pre-configured interface much like our paradigm has been defined.
Thank you for your insight and suggestion. However, I do believe that the system would benefit from having layered security if you could user define the tabs to be hidden and accessed with a hashed user access defined in the system configuration.
My simple question would be how to separate independent instances of Node-RED. Can this be done without using Docker or another VM. Can you run independent instances of Node-RED on a single computer?
I'm certainly not disagreeing with your desire or that perhaps NR might benefit from that enhancement. Only suggesting a possible alternative. Indeed, I would - with my IT Security hat on - say that separated instances are very likely to be significantly more secure. However, that has to be balanced by resource use and maintenance/administration complexity. As so often with IT, there is no single "Right" answer only ones that fit best with your resources, knowledge and needs.
Most certainly you can run many instances of Node-RED on a single device. You could spread them over multiple devices as well of course.
You can even run multiple instances on different version levels if you needed/wanted to.
If you are happy to always use a single version, you can continue with a single, global install of Node-RED itself and set up multiple services that call Node-RED passing in different --userDir parameters. This is actually somewhat easier to do on Linux but certainly possible on Windows as well.
If you want to have the option of different versions of Node-RED, check out my alternate installer repo on GitHub. You don't have to use that but it certainly shows you how to have local installs of Node-RED. On my Windows 10 dev machine for example, I often keep multiple instances including one that is completely "clean". This enables me to run different tests on different setups and even different versions of Node-RED.
Docker, of course, is another way to achieve the same thing but rather more complex. You get better local separation with Docker but at the cost of higher resource usage and more complex administration.
One last thought. The main thing against running multiple instances is resource utilisation. You will need to check how much spare resource a machine has in order to ensure that you don't get slow-downs or even crashes.
@TotallyInformation,
Your insight is, as always, beneficial. To clarify, I cannot tell if this feature is difficult or not. I have the utmost respect the development team and their time. I am simply a "user" and my needs are unapologetically selfish. I will take your advice in the meantime and discover how to install at least 2 instances of Node-RED in order to try this approach. Thank you for your kind advice and time to help me find a solution and explore Node-RED.
While I'm at it. We are probably going to use VUE and the uibuilder contribution. There is a need for a fixed size on the UI screen. As far as I can tell, Node-RED Dashboard does not offer an easy way to put all items on a page in a fixed size frame that does not change the page items when someone may re-size the page. I need to have it fixed. I would like to stop Items moving on the page on re-size. Or is my best option to use uibuilder? Or am I again, in a box?
Thank you for your kind words, always welcome.
Dashboard, of course, fills a much needed position in Node-RED of being accessible with minimal to no web building experience. But like many complex frameworks, you get to a point where you "fall off a cliff" and the complexity of fighting with the framework outweighs the benefits. That is why I wrote uibuilder in the first place.
I'm no expert in Dashboard as I no longer use it for anything other than a quick output or quick prototype. However, as I understand it, the Dashboard framework is built around a "card" style interface that adjusts itself to the screen size. So I don't think you can particularly fix it in place without moving to a purely Dashboard Template based output - and that might then be easier anyway using uibuilder. I expect that Dave will chip in if I've got that wrong.
What I typically find is that, even with only basic knowledge of HTML, CSS and JavaScript, a simpler and cleaner framework with uibuilder is very easy to work with.
uibuilder comes with VueJS and bootstrap-vue (and hence bootstrap) by default - though you can, of course, replace that with anything you like. Bootstrap has a fairly opinionated way of visualising things but it generally produces pleasant looking UI's with no adjustment on a variety of devices. You can chose between fixed and adaptive widths and heights with very simple selection of CSS Classes. Reasonably well documented on the bootstrap-vue and bootstrap web sites.
Hi Node-Red Team,
I would like to contribute here on the design concept, ultimately it would be beneficial to have the permissions to be able to control the access down to the node level as well as flow level (tab), so that each individual node could be configured for read or write or no view access (to secure the function code). To the point where, if I wanted the user to only see one node in the editor to be able to change the configuration they could, all other nodes would be hidden.
It would be sort of what I would like to control as per this request, to allow the end user to edit the configuration node only, i.e. FTP server user/password when the password of a FTP server changes for periodically for best practice cyber-security.
I'm not really in a position to comment on your proposal but I can comment on this.
Best practice for identity authentication and authorisation management is to have it completely independent of your business logic. And really best practice is not to be using passwords. It is certainly not to be having passwords embedded in your business logic.
Hi TotallyInformation,
Yes that's all very well, however the ftp node has the server configuration node in it, and to use that node the configuration node needs to be configured with the server credentials?
I'm not familiar with that particular node - but many nodes can also use environment variables to help configuration https://nodered.org/docs/user-guide/environment-variables
As I indicated, I wasn't commenting on whether a change to the node might be helpful but rather commenting on best practice in regards to security for FTP (and other) servers.
There are nearly always other solutions to problems and in this case there may well be ways to transfer that data that doesn't rely on the specific node.
@knolleary,
Greetings and Salutations!
I was wondering if this topic of "Flow Security" had crossed any design thresholds for you and development team?
Kind Regards,
@hp_apcc
@knolleary, I'm curious if this feature has any traction at all? Our current plan is to have multiple instances of Node-RED running and communicating with MQTT data shared from one security level to another. This means is by your definition, the only way to have levels of security to block certain flows from being able to be seen and edited. Separating out parts of the main functionality and the core dashboard would then allow technicians whom have permission to address input/output devices and change things like IP Addresses and configuration settings common to the devices and not allow them access to core development areas. For security and simplicity. This would help uncomplicate the Node-RED editor and streamline the areas they only need to see.
If we can have Flow security, then this would allow the system to be more manageable to areas without having to share data to and from the devices via MQTT at all.
I'm just looking to get some feedback on your opinion of this request and if it is within scope of any current development.
Kind Regards,
@hp_apcc
This is very often mentioned. But you really have to dig deep into the requirement here.
—-
“I want 3 people to work on a node red instance and make sure they can by no circumstance break each others working flows”
You can not achieve this by authorization. You can only achieve this by version control, automated testing and ci/cd
—
“My developers know all flows and their bits and pieces. I still just want to give them visual clues of where they should be working”
This can be achieved by simply naming your flows accordingly
—
“I want to hide some flows from some developers”
You shouldnt so this, people can implement things that break each other without knowing what others created
—-
Finally i suggest you to look at software development teams. 10 devs work on the same application thats gonna run on the same server. They are usually not limited from editing parts of the code. Other measures are taken mentioned on the first example
It depends what you mean by traction.
I've lost track of how many times this type of feature has been discussed. I've said a number of times in those discussions that I can see there being place to have finer grained permissions that work at the flow level.
What I don't have is a design, specific set of requirements or anyone showing interest in helping move the feature forward.
I can certainly see the value it would bring. But I also see the value of all the other items in our roadmap.
So I don't know what else I can say at this point. It is a pretty major piece of work - not a minor feature that can be slipped in between everything else.
If someone did want to discuss specific details of how this could work, I'm happy to have that conversation. For example, how would it be configured? What does the adminAuth model look like when you have to deal with access control to individual flow resources? What's the user experience in the editor to setup the permissions? How are the permissions stored? What new runtime APIs are needed? What features of the editor need changing to support this sort of locking - for example, does this prevent a user from viewing the tab entirely? Or does it just stop them from modifying it? If its the latter - can they export and reimport a copy?
There is a huge number of questions that need answering, and the best way forward is for someone to start to put together a proposal that considers them.
@aderici,
Thank you for your input. Our requirement would be to isolate flows such they cannot be edited on Technical support level. Administrator level would have access to all flows for debug and revision control. This is not a multi-developer problem. It is a Technical support vs. development problem. In the world of manufacturing, There are necessary device configuration to the outside world which needs only technical support. This is NOT strictly development, so your model for analysis may not apply completely. We would not want to expose the whole program to Technical support for reasons not only because it is out of context, but to keep it safe and the areas of real concern obvious.
@knolleary,
Thank you for your response and consideration.
I would love the opportunity to be part of this discussion. I am going to answer these questions you pose and see if I can qualify for your time on this topic. I will also try to solicit others who can help to define criteria. If the concept is attractive to others, then it should also fit their purpose.
For now, we certainly can use the system as it is with multiple instances and separate security. I am also looking forward to the offline installer which you described in new features to come. Our production systems are air-gapped from internet access. Keeping the nodes up to date is a concern which has yet to be addressed.
Thank you and kindest regards,
@hp_apcc
I think the idea has merit.
I work with a bunch of app services that have different ways of solving the fine grained security issue.
Challenges are to make something usable 'out of the box' but configurable enough if necessary.
@knolleary, what can a nodenoob like me do to help?
Is there a specific format for a requirements / design doc? Some sample code to demonstrate POC?
@RobC ,
I'm very glad you are in this conversation. I would very much like to hear what your needs are with "flow security" to better define what would be a benefit to the community and garner support for inclusion in Node-RED.
My needs are to define by tab/flow access to the tabs. For instance these tabs are greyed out if they are disabled. I would very much like to have the tab not displayed at all if the user did not have the credentials to display it. If you cannot see it, tab to it, you cannot change it.
Security levels:
Admin - global
Access - Limits tabs exposed to changes. Deploy on these tabs only.
Read-only - Look at everything, no changes
Read-access - Look at just what is available, no changes
Then its a matter of a checkbox in the flow menu to what you as an administrator will allow for the users.
"Access Limited"
To restrict "Access Limited" users so they cannot get to this tab even to look at it, much less modify it in any way. If you are "Read-only", it will have no effect, If you are "Read-Access", you cannot see it at all but can only look at the non-limited tab/flows.
