Export/Import Security Credentials

Core Development Feature Requests
1

Problem Statement:
Current export functionality removes all security/setup values for certain nodes (ie Azure Blob Storage) making it difficult to maintain and share across multiple deployed applications.

Feature Request:
Provide an option that would allow export/import functionality of nodes that contain credentials.

2

We have no plans to provide an api that allows secure credentials to be exported from the editor. If we did that, then anyone with access to the editor would be able to see all of the credentials. That would be a massive security issue.

The only way we'd consider this would be if we can find a way of approaching it that minimises the risk.

3

Anyone with editor access already can see the credentials by double clicking on the node? I must be missing your point. I am not asking for an API that would unencrypt the _cred file, I just want a way that I can share a common set of flows to multiple applications. For example, I am building an application that I want to deploy to 100's or distinct PI's. How am I supposed to do this without having to edit everyone of them and type back in all of the settings and credentials?

4

No they can't - the ******* that you see in the browser is not a disguised version of the password (or whatever) it's just a visual representation that you have filled something in... so cutting and pasting it won't help. The credentials only go from front to backend once on entry (or they do on nodes that are coded correctly).

5

Hmm...not based upon the nodes that I am using. See attached.

Security%20Nodes
Security Nodes.jpg1920Ă—1080 252 KB

6

Looking at the blob storage node you are using, they have defined the inputs as text inputs rather than password inputs - so they are showing the value rather than hiding it. That's a bug with the node.

If you save the changes, deploy then reload the editor and re-open the edit dialog, you should see the values have all been replaced with __PWRD__ - which is the placeholder Dave mentioned in his reply.

7

I purposely took a screen shot after deploy and reload. Every field in here gets removed when I try and export. Is this determined by the Node developer? Regardless, do you understand my request. If I want to deploy this to 100 different areas, I need to touch everyone to manually to add the information back in?

8

I'm not sure, but doesn't it work if you copy the credentials file as well ?

9

As Nick said - if they chose not to set at least the key as a password type field then I would call that a bug - but it's their choice.

10

Hello.

jewendt:
Did you manage to solve this issue?

I'm facing the same problem. I will have to deploy and manage same flows on the multiple devices.
They will all share the same flow file loaded from the network location, but entering / updating credentials to connect to the sql server manually will be a pain.
I will appreciate suggestions how to overcome this.

11

Which node are you using for SQL server? If you use mssql-plus it saves credentials in the cred.json file.

12

Hello.

I found some tips here:
How to copy credentials in node-red flow?
and here:
Node-RED User Directory

My approach to solving this:

  1. Create a copy of the ~/.node-red folder on a network location
  2. Modify settings.js file specifying userDir: to match location from step 1.
  3. Modify settings.js file specifying contextStorage location:
contextStorage: {
        default: {
            module:"localfilesystem",
			config: {
			dir: "<path to your dir>",  // eg. "/home/pi/store/"
			base: "<name of the directory for context>", // eg. "context" 
			}			
        },
    },

This allows to share flows and credentials between devices.

13

Um, not really the same.

That's for setting up file based context storage.

From my understanding, when a node correctly implements credentials they get saved next to your flows file in xxx_cred.json file.

That's why I asked what SQL server node you were using as the one I mentioned does this!

1 Like
14

Hi Team,
Sorry to bring up an old topic but it's still relevant.

Has the question evolved? I know it's a wish but there are still questions about how to do it.

The link to the discussion.

What are the problematic points and can we think about them?

As NR v4 will have to use authentication, the API is secure. Concerning permissions, we should make a difference between a basic user and a user with privileges, so that the read permission has no access to credentials but a read+ permission yes.

Concerning encryption, exporting flows may require a password from the user (only for download because it is especially storage that represents a breach) and also to re-enter their password during import. Are credentials showed raw in the window allowing them to be copied directly?
The API part only, difficult to say, should we automatically create an encryption password as parameter in order to fetch the flow?