I have a windows panel PC which is available for a client as administrator, and run Node red on that to show some variables on a dashboard, the dashboard is available throughout the clients network so that it can be seen from all devices, I do not want the client to be able to modify or see the flow though, so I am trying to secure this but don't know how.
I can put authentication inside the settings file, but since the file is accessible by the administrator, he can simply delete this again from the settings file and authentication would be disabled again.
Is there any simple other way to lock a flow?
Ultimately, anyone who has admin/root access to the device running Node-RED will be able to look at everything, at least as raw files.
The only way to avoid that would be to have a different device - to which they do not have access (e.g. on a different network) and to which the client PC connects via browser display of the dashboard.
If that is not possible. About the best you can do is to firstly tell them that the folder and files are out-of-bounds and ask them to respect that. Then to add some process that monitors the files for changes and notifies you regularly that they have not been changed (this is more robust than trying to monitor for changes since an admin could disable that. No-change notifications could be spoofed of course but it is likely to be less obvious).
You could also set up a process that pushes a known version of the flow file from a remote on a regular basis (requires Node-RED to be restarted though). You can also turn off the Editor.
There are things that you can do to help protect the contents of the userDir but they won't stop an admin.
Ultimately, the best approach is to build trust with your customer. 
You could prevent changes to settings.js by putting it on read-only media.
Unfortunately, your secured settings.js is easily bypassed by a system administrator.
Perhaps put Node-red on a Linux PC, secure it as you like and don't give the client a login id.
In my own solutions @home, I do not use any dashboard nodes, instead I have "self written web page(s)" hosted & served by NGINX
What I then decide to publish is sent from several NR instances via websockets. Commands from push buttons on the web pages are also sent back to NR via websockets. NR and NGINX runs on separate devices so access to NR itself and it's local files is therefore not needed and not possible
Sounds just like UIBUILDER! 
Yes, that would be my recommendation to others! Myself I just did some early adoptions to some old stuff I had laying around, inherited from other projects I worked with and it provides the bare necessity. But for sure, if I decide to deeply re-work...one day
One thing tempting my mind is if I could use a MQTT cloud service, some do support websockets over MQTT, and use such a channel for direct communication between NR instances and the web client(s) (Maybe I have not searched good enough...)
Sure, just make sure it is properly secured. Also, remember that MQTT brokers can transfer between themselves very easily. So avoiding costly Node-RED to remote MQTT transfers, just use a local broker and get the brokers to communicate.
Client to broker also possible as you've seen. But again, it is likely to be more effective and reliable for clients to talk to local brokers if that is feasible and then get the brokers to network.
Oh, and some mqtt clients aren't so good at reconnect processing - websockets is not always the most robust. So you may need to handle that.
UIBUILDER uses socket.io natively which is more robust than pure websocket but, of course, needs a socket.io server, which uibuilder hosts inside Node-RED for you.
