Enable execution sandboxing - Data360_Analyze - Latest

Configure execution sandboxing on Linux

Follow the steps in the Data360 Analyze Server Installation Guide to perform a normal installation or upgrade, then follow the steps in this section to enable execution sandboxing on Linux.

Prerequisites

• Docker version 20.10 or later is installed on the same instance as the Data360 Analyze server.
• Both the OS user that runs Data360 Analyze and the OS user that installed Data360 Analyze is a member of the Docker group. Note: These users could be different, when Data360 Analyze is configured to run under multiple users.
• Data360 Analyze is running.

1. Login to the machine where Data360 Analyze is running as the installer user.
2. Run the following commands to enable the execution sandboxing feature:

   cd <installDir>/

   source .profile.lavastorm

   bin/laeConfig executionContainers enable --user <admin> --password <pass> --processingUser <d3saProcUser> --createNetwork <net>

   The --processingUser <d3saProcUser> argument should not be provided if you have configured a multi-user installation.

   For more advanced options when running the above execution containers enable command, see Advanced configuration of execution sandboxing.

3. Restart Data360 Analyze, see Starting / stopping the server on Linux.

Configure execution sandboxing on Windows

Follow the steps in the Data360 Analyze Server Installation Guide to perform a normal installation or upgrade, then follow the steps in this section to enable execution sandboxing on Windows.

Prerequisites

• Mirantis Container Runtime version 20.10 or later is installed on the same instance as the Data360 Analyze server.
• The user that runs Data360 Analyze has permissions to create, start, stop and destroy containers in Docker.
• Data360 Analyze is running.

1. Login to the machine where Data360 Analyze is running.
2. Open a cmd window and run the following:

   cd <installDir>/bin

   laeConfig.bat executionContainers enable --user <admin> --password <pass> --createNetwork <net>

3. Restart the Data360 Analyze services, see Starting / stopping the server on Windows Server.

   This configures to use Docker execution containers for data and execution sandboxing and these containers will run within the <net> network. The <net> network will be created in Docker.

   This will download and build the necessary Docker image and create a containers.prop file in the <site>/conf folder which defines how the containers are managed including container expiry time and the maximum number of containers that can be run at any given time.

User defined mount mappings for execution sandboxing - Windows only

When using the isolated docker execution containers, nodes can only access data that is available from within data collections that the running user has access to, and their temporary execution data location. For access to additional file system locations (including mapped drives) system administrators should configure data connections, mount points and data collections accordingly, see Data repository setup.

If data connections are setup to locations that are not on the C:\ drive, then the repositoryTargetMappings.json mappings file must be configured accordingly to allow access to the underlying data connection location from the execution containers.

A pre-configured repositoryTargetMappings.json file is included in the <installDir>/conf folder. This default repositoryTargetMappings.json file ensures that when execution sandbox containers are enabled, the default data collections are accessible. The repositoryTargetMappings.json file contains a "mappings" section where the specified values are used to determine how data collections are mapped into the target execution sandbox container. This only applies if a user running an execution has the required access to the data collection, and if the host file system location is specified as a key in one of the "mappings" entries.

To add new mappings, a system administrator must generate a new repositoryTargetMappings.json file, define custom mappings, and save it to <siteDir>/conf/repositoryTargetMappings.json. Any entries in the default <installDir>/conf/repositoryTargetMappings.json file can be overridden by indicating the same host file system key with a new targetMapping.container value in the new custom <siteDir>/conf/repositoryTargetMappings.json configuration file.

For example, a mappings file with this configuration:

{
    "mappings" :
    {
        "F:/" : {
            "targetMapping" : {
                "container" : "C:/myFDrive/"
            }
        },
        "F:/public" : {
            "targetMapping" : {
                "container" : "C:/myPublic"
            }
        }
    }
}

In this example:

• Scenario 1: In Data360 Analyze, there is a data connection with a target of F:/ and a mount point is configured to use this data connection, without any relative path, pointing to a data collection at //Public Documents/Test#data-collection. In this case, if an executing user had access to that data collection, it would be mapped into the container at C:/myFDrive
• Scenario 2: In Data360 Analyze, there is a data connection with a target of F:/ on the host file system of the application, and a mount point configured to use this data connection, with a relative path of public, pointing to a directory: //Public Documents/Data. Within that directory there is a sub-directory path of folder1/folder2/folder3 and within the folder3 directory, there is a data collection DC1. In this case, if an executing user had access to the data collection DC1, it would be mapped into the container at C:/myPublic/folder1/folder2/folder3/DC1