FME itself can also remove shared data folder contents, remove files etc.

Maybe you could restrict the rights of the user running FME to not be able to remove critical files/folders?

I guess you could PIP uninstall some modules but I think this will do more damage then you expect. For example installing the AutodeskDocs transformer will use Python to install some capabilities, and without for example the OS module it could fail to install.

You could talk to users using FME and explain using Python requires knowing Python and check .fmw files for existence of PythonCallers.

I think FME itself is capable of destroying a lot even without Python so the danger is between seat and screen.

Right, that’s the point. It’s not about FME as such, but as I said it’s about “unexperienced user or malicious insider”. I just see a grey zone here - it’s OK to grant user access to Flow as Publisher, it’s not OK to allow OS level actions. I hope you see my point of view here.

As far as best practices go, my opinion is that it would be best to work with and train an inexperienced user before granting them publisher access. For malicious activity, procedures could be set in place to review the workspaces being created and published to Flow along with their log files.

Fully agree, have it in place already. What’s more, ‘my’ users can publish to PreProd only and then automation pushes it to Prod after validation. But this is just a workaround. QC part also requires resources, especially when there are quite a few active users and/or multiple “top priority’ projects.

What about FME Flow itself? Is anyone aware of option to limit use of Python modules or perhaps whitelist some of them? 

You should restrict the user that runs FME Flow write access to folder that you are dangerous to change. For example the FileCopy writer can remove every folder if you move all folders and subfolders from C:\ to the VOID.

Again, it is not Python.OS module that is dangerous. And a lot of Transformers within FME use Python. So restricting Python.OS will result in for example writing to FileGeodatabase.

But if you want you could set FME Flow to a custom Python folder and remove the default Python folder that have the ArcPy module installed. And within the custom Python folder you could uninstall all modules you think are unsafe.

Not to mention the SystemCaller which can just run anything that the user running the Engine Service can run. 

I often use the os module in my work. Quite often it’s to just get environment variables, but if a customer blocked the os module then they wouldn’t be able to run quite a few of our workspaces. 

Another security concern (which I don’t think is an issue yet) is that with packages they will likely need to expose the web connections and database connections via python. As it is right now I don’t think it’s possible to use web connections or a database connection via python. This might change down the line, at that point extra care will need to be taken to protect credentials