Enabling Custom Scripts on a System without an Internet Connection

Overview

If you have SecureChange actions that are performed by customized scripts that were developed for TOS Classic, or if you need to create scripts for TOS Aurora, to use these scripts in TOS Aurora, you need to place the scripts and their dependencies in a location outside the TOS cluster. For details, see Custom Scripts.

If your TOS machine is not connected to the Internet, you need to download the required files to a separate Internet-connected Linux machine (non-TufinOS) and follow these instructions to build an offline installer. Then copy the installer files to the TOS machine and install the mediator script locally.

Example files are available at https://gitlab.com/tufinps/tos2/trigger-example.

If you have any questions about the migration process from TOS to TOS, you can post a question in the Tufin Developer community, in the Aurora Migration category.

Enabling custom scripts

The following commands must be done with root privileges, for example using sudo -s

On the separate Internet-connected Linux machine, install Docker:

curl -fsSL https://get.docker.com -o get-docker.sh
sh get-docker.sh

On the Docker machine, in your desired directory, clone the sample mediator script and related files:

mkdir -p trigger-service && curl "https://gitlab.com/api/v4/projects/tufinps%2Ftos2%2Ftrigger-example/repository/archive.tar.gz" | tar -zx -C trigger-service --strip-components 1

Run the following to create the file trigger_proxy.install.
```
cd trigger-service/install
./builder
```
Copy the file trigger_proxy.install to the TOS machine (without Internet) and give it Execute permissions.
Run the following to install the trigger proxy:
```
./trigger_proxy.install 
```
Run the following to activate the virtual environment:
```
. /trigger-service/venv/bin/activate 
```

Start the web service in a Screen session.

tmux new-session -s customscript
trigger-service/venv/bin/uvicorn --app-dir trigger-service trigger_proxy:app --reload --host 0.0.0.0

If using a high availability (HA) deployment, use the IP address of the cni0 interface from the server running the trigger proxy.

To get the IP address:
```
ip -4 addr show cni0 | grep -oP "(?<=inet )[\d\.]+(?=/)"
```
Set the SCRIPT_HOST to the returned IP address:
```
set SCRIPT_HOST=<IP>
```
where <IP> is the IP address.
Modify the Mediator script (mediator.sh); in the following line replace SCRIPT_HOST=10.20.51.230:8000 with the IP address of the web service:

SCRIPT_HOST=10.20.51.230:8000

This should be the IP address of assigned to a node in the cluster, which is the IP address you would use to SSH to the server. It is not the VIP used in the TOS interface.
Copy the script to the SecureChange pod:
```
tos scripts sc push mediator.sh
```
This command places the script in the /opt/tufin/data/securechange/scripts/ directory on the internal SecureChange pod.

Use the following command to configure SecureChange with the path where the mediator is installed on the pod:

curl -k -X PUT -u <user name>:<password> "https://<IP Address>/securechangeworkflow/api/securechange/internal/configuration/set?insert=true&key=webHookMediatorScriptFullPath&value=/opt/tufin/data/securechange/scripts/mediator.sh"

where:

<user name> and <password> - SecureChange credentials for a user with Admin Privileges
<IP Address> - TOS VIP Address

Configure the script in SecureChange, for example, if the script is for a Workflow event, configure as follows:
1. In SecureChange, select Settings > SecureChange API.
2. In the Full Path field enter the full path where the script resides on the host outside the TOS cluster.
  
  The full path for the script is the full path where the script is located. The web service should be installed in the same common path.
Register the scripts:
```
curl -k -X PUT -u <user name>:<password> "https://<IP Address>/securechangeworkflow/api/securechange/internal/configuration/set?insert=true&key=webHookMediatorScriptWhitelist&value=/home/tufin-admin/trigger-service/MyScript1.sh;/home/tufin-admin/trigger-service/MyScript2.sh"
```
where:
- <user name> and <password> - SecureChange credentials for a user with Admin Privileges
- <IP Address> - TOS VIP Address
- /home/tufin-admin/trigger-service/MyScript1.sh;/home/tufin-admin/trigger-service/MyScript2.sh - Script identifiers, multiple values are separated by a semicolon (;). The value must correspond with the value in the Full Path field of the script in SecureChange.
If the parameter is missing or has no value, SecureChange will use the Path field for the triggered script, and will not use the mediator script. SecureChange can work in hybrid mode, some scripts can be run locally, while some scripts are run externally by the mediator script.
In SecureChange, click Test to confirm that SecureChange is able to run the script.

Important notes

The mediator and web service scripts are working examples are provided by Tufin as a courtesy. By downloading and using these scripts you agree to take responsibility for implementation and maintenance.
You are responsible to make sure that the web service is up and running at all times.
The host where the web service is installed must have an Internet connection when the service is installed and the first time that the process is run.
The sample web service is designed to run on a node in the cluster, and will only respond to requests from the SecureChange pod using the Kubernetes library. These examples assume that the scripts are installed on the same host where TOS cluster runs.

If you prefer that the web service and customized scripts reside on different hosts, you should implement security measures such as encryption and authentication according to your organization's regulations.
Customized scripts will not be able to access the TOS database directly.
These scripts are intended to allow TOS-specific addons only. Scripts should be designed to utilize the TOS APIs or web service to interact with the software.
Customized scripts should not impede the performance or functionality of TOS. If Tufin Support provides assistance with troubleshooting or performance issues, you may be asked to disable custom scripts as part of the troubleshooting process.
On HA deployments, the web service should be installed on a data node.
You can install this solution on a node in the cluster or a separate external server; however, the examples in this topic are for a node in the cluster.