In v2020.4, we introduced a new feature called Storage Buckets in Orchestrator. This feature allows Orchestrator clients (workflows mainly) to read and write file-like data. We also implemented several backing stores, also known as providers: Azure Blob Store, Amazon S3, Minio, Orchestrator (uses Orchestrator’s configured storage), and FileSystem.

The FileSystem provider allows the Orchestrator end-user to define a path where data is saved, either a network share (e.g. \\fileserver\\orchestrator_bucket) or an absolute path on the Orchestrator server (e.g. c:\data\orchestrator_bucket).

If the end-user chooses a FileSystem location that contains sensitive information or is generally considered a sensitive area of an operating system configuration and settings, it can cause un-intended consequences for the Orchestrator deployment and use cases.

For this reason, we discourage the use of the FileSystem provider, and we disabled it by default on both fresh installations and upgrades.

To further mitigate the safety concerns with using the FileSystem provider, starting with v2020.4.5 and v2020.10.7, we introduced an allowlist feature so that the Orchestrator admin can control the location of buckets that end-users can create. To use the FileSystem provider, an Orchestrator administrator must first enable the provider and use the allowlist feature from the Orchestrator web.config file to include the list of locations that users are allowed to use. See Buckets.FileSystem.Allowlist for more details on this.

In order to mitigate the safety concerns, Orchestrator administrators should adopt the following best practices when defining entries in the allowlist:

• Do not use the Orchestrator installation root directory or any directory that gets served by a web server;
• Make sure the supplied folder or network share does not have any subdirectories or files containing sensitive information that should not be accessible to Orchestrator users or automations;
• Do not use a full partition, such as C:\, as it might result in read access to unexpected data;
• When possible, restrict the access to a subdirectory created specifically for storage buckets. For example, if you use C:\my_data to store all your data, you could create a subdirectory called storage_buckets, and then add C:\my_data\storage_buckets to the allowlist instead of C:\my_data;
• Look for hidden files and folders before deciding on the allowed paths as they might contain sensitive data;
• Use a specific folder in a network share instead of the whole network share (e.g. \\server.corp\sharedfolder);
• Do not allow system-specific folders, such as C:\Windows, C:\Program Files or C:\ProgramData, as they might contain sensitive information;
• Do not allow an administrative share to be used (e.g. \\server.corp\c$\);
• Multiple users can specify the same location on disk for storage buckets. For this reason, users should not store sensitive data in a bucket, as there is no guarantee that data is isolated to that user or their tenant.