Set up a new machine with an InfluxDB access token already configured in an influxdb config node's "Token" field. This token is available to Node-RED runtime as an environment variable INFLUXDB_TOKEN, and each machine has a unique uuid credentialSecret.
Problem
The influxdb node's "Token" field is stored as a credential, even though the value we want to provide it is simply ${INFLUXDB_TOKEN} and not the actual token value. Since the credential secret differs between machines, we can't just copy the flows_cred.json file like we do with flows.json.
Is there a way to achieve this or are we stuck entering ${INFLUXDB_TOKEN} manually for each new machine?
If you want to access environment variables in a function node it is
env.get('INFLUXDB_TOKEN')
But I think this is not your point, I am having the same issue as you. I think this should be possible by being able to decrypt and encrypt the flows_cred.json file.
Not really, nothing reliable at least. Could just copy the flows_cred file if you happen to use the same credentialSecret and influx token for every install, but that's not likely or a good idea. It could also be done manually following the encryption code here, but that seems like a bad idea as well.
So there are some ways around it, but they aren't great. We just stuck with manually populating the influx token on new installs since there doesn't seem to be a reliable solution.
Good hint, the functions encryptCredentials() and decryptCredentials() could be used easily.
It would need a script which calls these while building based on a node-red docker image.
in the Dockerfile something like this:
COPY flows_cred.json.cleartext /data/flows_cred.json.cleartext
# create encrypted flows_cred.json
RUN encrypt-flows-cred ${NODE_RED_CREDENTIAL_SECRET}
# remove flows_cred.json.cleartext
RUN rm /data/flows_cred.json.cleartext
as soon as there are no secrets in flows_cred.json.cleartext it can be checked into vcs.
Yeah like I said, it's possible, but I don't really like the idea of using internal Node-RED code that could change and break at some point in the future. We have to do some other stuff manually through the UI for a new build anyway so pasting the influx token isn't too much of a hassle. But if it works for your use case then great!
@knolleary any thoughts on this? What would be a good approach now, and what maybe a better in the future if you consider our use cases as relevant for Node-Red.
I think maybe a less-invasive way to handle this could be to allow users to tell a credential input "this value isn't sensitive, please store in flows.json instead of encrypted in flows_cred.json". Since for my use case (and it sounds like yours as well) the literal "${INFLUX_TOKEN}" is all that's getting stored as a credential, then Node-RED loads the actual "secret credential" during runtime. So this "credential" doesn't really need to be treated as one in this case.
If you have secrets in your .env file, just store all secrets there and none in the flow_credentials.json file. And make sure, only relevant users of the host system can access it.
. Thanks a lot 
Not much sense keeping some credentials encrypted when there are multiple others in plain text .env files on the machine I suppose...