Enforce Execution Isolation for Secure Multi-Tenant Operations
For the complete documentation index, see llms.txt. For a full content snapshot, see llms-full.txt. Append.mdto anykestra.io/docs/*URL for plain Markdown.
Configure worker isolation to separate file systems, restrict thread creation, and enforce script task isolation in multi-tenant Kestra instances.
Worker isolation — enforce separation
When dealing with multiple teams, you can add extra security measures to your Kestra instance to isolate access so that there is no shared file system, only certain plugins can create worker threads, and script tasks are isolated.
Java security
By default, Kestra uses a shared worker to handle workloads. This is fine for most use cases. However, when using a shared Kestra instance between multiple teams, this can allow people to access temporary files created by Kestra with powerful tasks like Groovy, GraalVM Python, and more. This is because the worker shares the same file system.
You can use the following to opt in to real isolation of file systems using advanced Kestra EE Java security:
kestra: ee: javaSecurity: enabled: true forbiddenPaths: - /etc/ authorizedClassPrefix: - io.kestra.plugin.core - io.kestra.plugin.gcpTo only limit access to certain plugins on a Worker without requiring file path protection, you can also consider configuring Kestra with Allowed & Restricted plugins.
kestra.ee.java-security.forbidden-paths
This is a list of paths on the file system that the Kestra Worker will be forbidden to read or write to. This can help to protect Kestra Security and Secrets configuration files and ensure security for audits and compliance. With this property configured, you can reduce the amount of directories that a Worker can access such as protecting access to the folders where global Kestra configuration or ~/.aws/credentials are stored.
kestra.ee.java-security.authorized-class-prefix
This is a list of classes that can create threads. Here you can set a list of prefixes (namespace) classes that will be allowed. All others will be refused.
For example, GCP plugins will need to create a thread in order to reach the GCP API. Because this whole plugin is deemed safe, you can authorize it.
kestra.ee.java-security.forbidden-class-prefix
This is a list of classes that can’t create any threads. Other plugins will be authorized.
kestra: ee: javaSecurity: enabled: true forbiddenClassPrefix: - io.kestra.plugin.scriptsCurrently, all the official Kestra plugins are safe to be authorized except all scripts plugins because they allow custom code to be created that can be read and written on the file system. Do not add these to the forbidden-class-prefix.
Scripting isolation
Use a Policy to enforce Docker isolation for script tasks. For installation-wide enforcement, declare a static policy in server configuration (Enterprise Edition):
kestra: policies: - id: enforce-docker-isolation description: "Force Docker isolation for all shell script tasks." rules: - type: io.kestra.plugin.ee.rules.Add on: PLUGIN override: true where: - field: type operator: STARTS_WITH value: io.kestra.plugin.scripts.shell values: containerImage: ubuntu:latest taskRunner: type: io.kestra.plugin.scripts.runner.docker.DockerStatic policies apply across all tenants and cannot be overridden by namespace-level policies, making them suitable for cluster-wide security requirements.
Add rules for all script plugin types (Python, Node, and others) to ensure no tasks can bypass Docker isolation.
Was this page helpful?