Looking for best practice on this: If I use environment variables (set via the environment when Node-RED is run as a service) in my configuration node properties, do I need or even want a credentialSecret (in settings.js) defined? All it would encrypt is the environment variables, not actual usernames/passwords and that seems counterproductive.
The problem it causes is it is difficult to set up a new project, because I need to enter the credentialSecret password into the Project settings, even though I have NODE_RED_CREDENTIAL_SECRET defined in the environment file and reference it in settings.js. Similar to this issue.
Bit more info:
I am building an open source project (glossyio/traffic-monitor, if you want to check it out). I am running Node-RED as a service, so I have enabled an environment file. I am using those environment variables to populate my Configuration nodes. In that way, the user specifies applicable username/passwords in those. Note, I am only doing this for the aedis mqtt broker at the moment. You can see these under the node-red-project directory on the working branch.
Node-RED is powering most of my logic, so I am re-working it to read in a config.yaml file have a standard way to set up a deployment and to initialize all the variables. But these are not available until the flow starts, so I can't use these in the Configuration node properties.
No, the credentialSecret feature is largely useless. It functions as a sort of built-in password-manager, but doesn't encrypt secrets outside a specific limited set of fields (you can easily declare secrets elsewhere that are not covered and therefore stored in clear text). I ended up enabling it, hardcoding the password into the settings.js. And I use the same settings.js to each new installation. Only reason I used it was to silence a warning in startup logs/stdout.
Worth noting is if using projects, this setting is ignored in settings.js and instead used in .config.projects.json.
For any nodes that use the credential system of Node-RED, then it will ensure they are not stored in plain text within the flow file and that they are encrypted in the credentials file.
You can also define env var properties within the flow as credentials and they will also be stored within the encrypted credentials file.
If you are passing in everything you consider a secret via an environment file, and not storing anything in the flow itself, then there's not much benefit to enabling credentialSecret in Node-RED itself - although there is equally no harm having it set.
That's interesting... I can't find that anywhere in my directory tree. Is there documentation for that?? That does explain why settings.js doesn't initialize on the new project.
Good context. Though, the harm is that when Cloning an existing project, the user needs to manually enter the password into the Project Settings in the Node-RED UI, by hitting the tiny little "edit" button on the upper-right of that side-panel screen. Which is REALLY HARD to teach someone who doesn't regularly use Node-RED. I can't tell you how many screen share sessions I've had with colleagues that forgotten that one step. And if you don't do that when you clone a project, there is a nebulous error thrown and no flow comes up.
Ah, wait. I do see the .config.projects.json under the .node-red directory under the current user (for NR as a service) with the credentials (not the project).
If I wanted to provide that file with password by default (to avoid warnings)... I would need to incorporate it into my system setup script prior to cloning a project, wouldn't I? That's kind of a weird step since it's only useful to folks who want to develop/access the flow (normally, users would have no reason to look at the NR flow at all, it should just work) but shouldn't be any harm.
If you use a secrets vault, everyone who wants to access it must have the password to that key vault. What are you trying to facilitate for others that doesn't involve develop/access the flows? Dashboards?
In my setup script it applies a bunch of files I need to be exact in order to have everything in place (including a bunch of settings and user settings so we don't have to start with defaults every time):
.env (for docker)
.env.json (for node red, using json here since I didn't bother to install env dependency)
.config.nodes.json
.config.projects.json
.config.runtime.json
.config.users.json
With all of these taken care of, I can pretty much get the exact instance each time.
By default I set up the Node-RED environment so it runs in the background whenever the RPi turns on, headless, with the settings.js, package.json (and initially installed all additional nodes), flows.json, and environment (for the node-RED systemctl service): ref the repo tree. Users can access the dashboard/ui for monitoring output. In this case, it doesn't matter if there's a password (credentialSecret for the flow) or not, a user will never encounter it. Worth noting, I also enable AUTH user/password for users accessing the flow.
But, if a developer comes in to change something in the flow and subsequently submit a PR, hopefully, the path I recommend is to use Clone Project. That downloads all the repo files again (now into the .node-red/projects folder) and that's when the dev needs the credentialSecret... because it doesn't use the existing settings.js pre-populated values.
I think we're on the same page. Though, I'm not using those .config.*.json files at all. I do see them in my .node-red/ folder, now that you mention them. Should I be using those over the ones I have listed above?
Are you not using that workflow? We've not had much feedback around the project's workflow, so if you have feedback, it would be great to hear, otherwise nothing will change.
Thanks, @knolleary - 2 feedback points off the top of my head for this:
It would be nice to specify a remote branch when this initializes. I typically use it for testing incoming changes, so being able to jump right a branch would be nice instead of Cloning > Side Panel > Project History > Commit History > Manage remote branch. If you recommend just using git in terminal, I totally understand.
If someone [inevitably] fails to enter the credentials at that Clone Project point because it doesn't show as required, that's where it gets hairy. It won't load the flow, throws a setup error, and the error notification button goes to Project Settings, but it's not clear the error is with Encryption. Then the [really tiny] Edit button is also not clearly required to enter credentials. And maybe that's just a dev behavior thing we need to correct more than a workflow issue. I usually get pulled in when someone is like "my flow won't work", and I had no clue they didn't enter credentials. I'm getting good at checking that now first. But that's why I'm asking if they are even required, just get rid of them in our case since we bring in all passwords via environment file variables from the system.
Ok, I'll leave those alone, though I am interested in how @ThingsTinkerer is doing it (would you share your repo, TT?), but my headless version is working without a hitch. It's just to make development easier.
