Context variables encrypted at rest?

General
1

Thanks to all the contributors for great new features. I cannot express how satisfying it is to me finally to see my mermaid diagrams render properly in the Node-RED editor. :slight_smile:

One nit: it would have been nice if the configuration nodes used to store global environment variables were encrypted at rest by default and the whole design of the "credential" type of config data always has been more than a little cumbersome to use in practice. As it is, I will be sticking to my setting.js based approach because keeping sensitive info out of cleartext within my flows is my primary use for globals, to start with.

2 Likes
2

Can you explain what you mean by that please. Perhaps an example of what you mean.

3

I did describe my comment as a "nit," and solving it is probably more trouble than it is worth. But since you asked... :slight_smile:

I have always found the way that the Node-RED editor handles encrypted data via the "credentials" data type in configuration nodes burdensome to use and error prone. For example, you can only see the cleartext value in the editor while entering it initially. Once saved, editing it requires you to re-enter a value from scratch rather than having the ability to see and edit the existing value. Also, the UX for entering the credentials password when creating or cloning a flow makes it fairly easy to accidentally leave your new flow in a broken state that is annoying to repair from within the editor, itself.

For these reasons, I tend to avoid putting data into credentials fields in configuration nodes but, rather, put sensitive information in global environment variables. So for my use case, relying on the same old credentials data type mechanism for encrypting global variables maintained within the flow misses the mark. Ultimately, this is certainly reflective of personal preference and working style. For those who find the existing "credentials" UX less cumbersome than accessing settings.js in a text editor I am sure that this is a welcome feature.

I would, of course, love to see enhancements to the overall handling of "credentials" in the editor, in which case I would probably migrate to using them more extensively. But then I would have little or no need for global environment variables in the first place. So this new feature does not give me, personally, any increase in value and I will happily stick with my tried-and-true approach of putting environment variable definitions in a module file and importing them into settings.js using require. Again and as usual, your mileage may vary!

Of course, I do recognise the challenges of enhancing how the credentials UX might work. It would likely require a top-to-bottom, end-to-end revamping of how authentication and authorisation work in the editor as well as how encrypted data is accessed in the flows at runtime, entailing substantial breaking changes.

One way to have addressed this dilemma in this particular case might have been to store global environment variables in a new type of file, distinct from either flows.json or flows_cred.json, and handle its encryption / decryption as a new, special case. Exactly how that special-case encryption might work, I leave as an exercise for the reader... :wink:

1 Like
4

It might be a good idea to take this part of the thread to a new topic - I can do the split if you are willing for me to do that.

I think this is an idea that requires a little more examination as there are several potential issues that would need to be thought about.

Just reply if you are happy for me to split this thread.

6

Thanks @parasaurolophus , moved to new thread because I certainly think it is worth a discussion.

I think that the potential issue with your suggestion might be that while encrypiton at rest for context vars would mean possible more security when Node-RED wasn't running, the nature of NR is that it is often running all the time. Coupled with the fact that it is a general-purpose compute tool, you would need to be very careful indeed in order to retain any security.

7

The same applies to the existing encryption mechanism for configuration nodes on which the current implementation relies. So maybe you are suggesting that any encryption by Node-RED is not worth the effort? :slight_smile:

In all seriousness, I actually would not dispute that, speaking only for how I personally use Node-RED. It is, in fact, how I do use it, as my previous lengthy post describes. I would not expect and do not need enterprise-style, in-memory and in-flight encryption from a platform like Node-RED. For my purposes, I only am concerned about hiding sensitive data (e.g. API keys) from being stored as cleartext in flows.json when shared with others while finding the flows_cred.json based encryption mechanisms too cumbersome to use due to the editor UX in which they are wrapped. By keeping my sensitive configuration in ~/.node-red/settings.js it isn't encrypted at all, which is fine for my uses, while being completely invisible to any flows I might share with others. That is my entire purpose for using global environment variables in the first place.

8

There is a node that allows more general use of credentials. Maybe that would be enough for you? It should at least deal with the flow sharing issue.

Alternatively, and very simply, you could use a secure file system for some data, even the folder that holds file based context. Though that wouldn't fix the flow sharing problem.

Using settings.js allows you to either attach something to global context or you could use a custom property with a custom node.

You could also use environment variables if you can live with them being set before Node-RED starts.

Better would probably be a custom node that uses a proper keystore. But that sounds like it would probably be too much trouble for your use-case.

So at least a couple of existing options. Do any of them work for you? Been a long week for me so I might not be at my clearest thinking now.

9

Thanks for your interest, but I do not have a problem that needs solving. My post which kicked this off was an observation that one of the big features of 3.1 has a deficiency in its implementation such that it is not very well suited to its intended purpose, at least from the point of view of the traditional use of environment variables to store sensitive configuration data and for those, like me, who find the way that encryption is handled in the Node-RED editor far too bothersome due its clunky UX. For me, in other words, using settings.js to configure environment variables isn't broken, and the new 3.1 feature related environment variable would only be useful if it came with substantial improvements to the UX around "credentials" in the editor.

10

Those are some pretty strong statements. But I'm afraid I don't see anyone agreeing.

1 Like
11

Maybe not. But that does not alter the facts. :slight_smile:

12

Fact... Opinion...
Potato... potatoe...

:wink:

No worries. You are of course entitled to your opinion, and your use case preferences.

13

This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.