After the future removal of the classic playbook editor, your existing classic playbooks will continue to run, However, you will no longer be able to visualize or modify existing classic playbooks.
For details, see:
About automation isolation in Splunk SOAR
This feature is only available in Splunk SOAR (Cloud) FedRAMP Moderate environments.
has implemented a feature called Automation Isolation to further secure actions.
How playbooks and playbook blocks are run
When you run a playbook, the blocks are run sequentially by a Python runner. A playbook block or custom function must be completed before the runner executes the next playbook or custom function in sequence.
Automation isolation
In deployments of FedRAMP Moderate your playbook's blocks can be run by multiple Python runners, each python runner in its own isolated container.
When a Playbook run is started, the DECIDED daemon assigns playbook actions or python code either to the internal Automation Broker or to a Python runner.
- Playbook actions are assigned to an internal automation broker named soar_internal_ab to be run.
- The playbook's Python code or custom function blocks are assigned to an available Python runner in a round-robin fashion.
- The number of Python runners is automatically scaled up or down as needed. When additional Python runners are required, new containers are launched. When a Python runner is no longer required, its container is destroyed.
- Blocks from the same playbook run are run sequentially. A single playbook run will only run one block at a time.
- Previous releases of guaranteed that all the blocks of a playbook run would be run by the same Python runner. Now, playbook blocks can be run by any available Python runner.
Additional information about playbook code when using automation isolation
The following changes in playbook behavior occur:
- The playbook API save_data may return incorrect results when playbook blocks are run different runners if the key:value pairs are not unique across playbook runs. Use the save_object() API instead of the save_data() API.
- The playbook API save_object may return incorrect results if the same playbook is run against the same container multiple times. Use the optional playbook_name and container_id parameters with save_object to make sure that saved objects are unique across multiple runs of the same playbook.
- The directories /tmp and /opt/phantom/tmp cannot be used to share information between playbook runs. These directories can still be used to share information in the context of a single playbook run.
- Playbooks cannot share information between playbook runs by using the host's file system.
- If you need to save information specifically about a playbook run, use the save_run_data() and get_run_data() APIs.
- Playbooks cannot read or modify the directory /opt/phantom/vault by using the file system. Playbooks that interact with the vault must use the Vault automation API.
- Playbooks should not create subprocesses, either by using the built-in
os.system
python function or the built-insubprocess
python module.
See also
Splunk SOAR (Cloud) in restricted environments | Pair Splunk SOAR with Splunk Enterprise Security |
This documentation applies to the following versions of Splunk® SOAR (Cloud): current
Feedback submitted, thanks!