I propose a feature that allows Node Access Control by Project Folder.
This feature would enable users to selectively enable or disable specific nodes (like the Execute Command node, or any other node) on a per-project-folder basis. This would involve a new configuration setting, likely in the administration or project settings, to define which nodes are permitted within workflows in a given folder.
My use case:
Example
We have a “System” project folder dedicated to infrastructure maintenance and deployment workflows. In this folder, the Execute Command node is essential and must be allowed. This will allow us to execute n8n cli commands.
All other project folders (Development, Marketing Automations, HR, etc.) should have the Execute Command node disabled to prevent developers or users from accidentally or maliciously running arbitrary commands on the host system.
I think it would be beneficial to add this because:
Enhanced Security: It directly addresses the risk of unauthorized commands being executed from less-controlled workspaces, mitigating potential security vulnerabilities.
Better Governance: It allows administrators to enforce policies on where certain powerful nodes can be used, ensuring that critical operations are only built and run in designated, audited folders.
Any resources to support this?
This is a governance feature similar to Role-Based Access Control (RBAC) but applied at the Node/Folder level.
Are you willing to work on this?
I am willing to clarify the requirements, provide feedback, and help test the feature as well as help with development. I am a software developer and have experience working with nodejs.
I have a similiar, but slightly different use case. We have users that we need to be able to execute workflows and edit data tables, but should not have the ability to edit any of the workflows. They need view access to see execution status.
This provides greater flexiblity without having potential issues due to incorrect edits.
Hey @maven Jonathan here from the product team. Thanks for the feedback. The good news is that this is something my team is starting to work on this quarter to extend the out the way include/exclude nodes currently works and bring that to the UI for admins to more easily see an control and at different levels of granularity.
We’re intending to bring these controls at the instance level, i.e global allow or restrict and then at the project level for both nodes and credential types. One thing I’m interested in from your feedback above is that yuo mention folders and projects. Are you referring to them as the same thing here or do you specifically mean controlling access to nodes at the folder level inside a specific project?
And one other thought, have you ever had a scenario where you would have even needed to go more granular and allow a specific using inside a project/folder to use a certain node but not others? If so, would love to hear of any examples of that.
@dagarritysps on this related point. Depending on which version and license you’re running on this is something that is possible through custom roles. You could create a role inside a project that can execute and edit data tables specifically but not ever edit the workflows themself. This is an Enterprise plan feature but just thought I’d share in case its not something you’d seen.
Yeah, we are not on the enterprise plan unfortunately, which is why we defaulted to chats for this purpose. I am thinking the most likely, although not ideal, path will be to move these to Google Chats since we are a Google enterprise
When you say we defaulted to chats, what do you mean by that? Are you referring to how users trigger the workflows from chat rather than the workflow itself?
Correct, since we do not have the granular role based security we decided to use n8n chat as a workaround for those non-technical users needing run ability.
You are right. I actually meant the project level.
We don’t have any use cases where we would need to apply this rule even more granular inside a folder of a project.
Project level is enough for use because for us we have a project called System where only system level workflow lives and only few users will have access to read and write.
There we could use Execute Command node and disable this node every where else. Honestly if it is more granular than project level, it might be more confusing
When you say ‘if it was more granular than the project level, it might be more confusing’, why is that?