Step-by-step deployment guide

This version of the gateway is currently compatible with Elimity Insights server versions matching >3.40.0.

1. Ensuring your files are accessible to the gateway

The Elimity Insights gateway for NTFS scans from the container's local filesystem. This means you have to explicitly mount all the files you want to target. Refer to the sections below for additional details.

Local directories

Let's assume you deploy the gateway on a plain Windows Server VM and want to scan some directories on the local filesystem: C:\dir1\subdir and D:\dir2. The following Docker Compose specification would be a good starting point:

services:
  ntfs-gateway:
    image: europe-west1-docker.pkg.dev/elimity-general/docker/ntfs-gateway:<tag>
    restart: always
    ports:
      - 8080:80
    volumes:
      - .\config:C:\app\config
      - C:\dir1\subdir:C:\target1
      - D:\dir2:C:\target2

In this case you would typically configure the built-in connector to target C:\target1 and C:\target2. Note that you can freely choose the destination paths for these mounts.

SMB shares via host mount

Scanning permissions for SMB shares is very similar to scanning permissions for local directories, we just need one extra preliminary step to mount the shares into the local filesystem. Microsoft provides explicit support for making SMB share mounts available to containers, the official documentation contains detailed instructions about setting this up. In short: to mount a directory dir in share \\host\share to local drive D:, run the following PowerShell command:

You can now mount the D: drive into the NTFS gateway container using a Docker Compose specification based on the following snippet:

SMB shares via container mount

The NTFS gateway also supports mounting SMB shares directly from within the container. In this case you don't need to mount them from the host. Instead use the connection configuration option to provide SMB share addresses and credentials to the gateway. After mounting the shares you can use their UNC paths in the built-in connector's target configuration. Refer to the dedicated section on this page for additional information. Note that this approach is especially suitable for serverless deployments on e.g. Azure App Service.

2. Generating a secret token

To make sure your gateway only serves requests from authenticated sources, we need to generate a secret token. You could do this for example with OpenSSL:

You should use this token to configure the built-in connector. The gateway itself only has to verify this token, so we just need to provide it with a hash (hex-encoded SHA256). You can again use OpenSSL for this step:

Note down the resulting hash for later use.

3. Configuring the gateway

To configure your gateway, mount a JSON configuration file at /app/config/config.json with the properties listed below. Refer to the following attachment for a starting point:

61B
Open

Edit the following properties in this file to configure the gateway to your needs:

Property
Type
Description

connection

optional[object]

Configuration object describing which network resources the gateway should connect with before scanning

connection.networkResources

list[string]

UNC paths of the network resources to connect with, e.g. "\\\\host\\share\\dir"

connection.password

string

Password to authenticate network resource connections

connection.userName

string

Username to authenticate network resource connections

secretTokenHash

string

Secret token hash you noted down in step 2

4. Deploying the gateway

Having configured the gateway we can now deploy it so the built-in connector can start importing. Since we distribute the gateway as a Docker image, our recommendation for deployment is to use a CaaS solution like Azure App Service. If that's not an option, you can also manually deploy the image on e.g. Windows Server. Refer to our documentation about gateways and import agents for additional details.

Last updated