|
1 | | -# Deploy Thunderstorm in a Container Environment |
| 1 | +# Deploy Thunderstorm as a Container |
2 | 2 |
|
3 | | -Many companies rely on the containerization of services to increase economic and technical efficiency. Customers which use containerization need to create images that make the services available as containers. In this guide, we provide you with the necessary requirements and templates to run Thunderstorm as a container. |
| 3 | +[THOR Thunderstorm](https://www.nextron-systems.com/thor-thunderstorm/) is a web service that lets you scan files with our compromise assessment tool THOR through a Web-API. This guide provides a base [container image](https://github.com/NextronSystems/thunderstorm-deployment/pkgs/container/thunderstorm-deployment) and a [Docker Compose template](https://raw.githubusercontent.com/NextronSystems/thunderstorm-deployment/master/docker-compose.yml) so you can run Thunderstorm as a container with just providing your contract token. |
4 | 4 |
|
5 | | -## Quick Start |
6 | 5 |
|
7 | | -Thunderstorm is a web service which allows you to scan files with our compromise assessment tool THOR through a Web-API. Ready-to-use base images are published to the GitHub Container Registry and only require your contract token to run. |
| 6 | +## Quick-Start |
8 | 7 |
|
9 | | -### Contract Token |
10 | | - |
11 | | -The contract token is used to download the THOR binaries on first container start. You can find it in the [Nextron Portal](https://portal.nextron-systems.com/ui/contracts/contracts) under *Contracts & Licenses → Contracts → Actions → cloud icon → THOR Download Token*. |
12 | | - |
13 | | -<img src="images/contract_token.png" alt="Contract Token location in Nextron Portal" width="500"> |
14 | | - |
15 | | ---- |
16 | | - |
17 | | - |
18 | | -Two versions are available: |
19 | | - |
20 | | -| Version | Image tag | Compose file | Default port | |
21 | | -|---|---|---|---| |
22 | | -| THOR 10.7 (stable) | `:thor10` | `docker-compose.thor10.yml` | 8080 | |
23 | | -| THOR 11 (techpreview) | `:thor11` | `docker-compose.thor11.yml` | 8000 | |
24 | | - |
25 | | -### THOR 10.7 |
26 | | - |
27 | | -1. Download the compose file |
| 8 | +1. Download the [Docker Compose](https://raw.githubusercontent.com/NextronSystems/thunderstorm-deployment/master/docker-compose.yml) file |
28 | 9 |
|
29 | 10 | ``` |
30 | | -curl -O https://raw.githubusercontent.com/NextronSystems/thunderstorm-deployment/master/docker-compose.thor10.yml |
| 11 | +curl -O https://raw.githubusercontent.com/NextronSystems/thunderstorm-deployment/master/docker-compose.yml |
31 | 12 | ``` |
32 | 13 |
|
33 | | -2. Start the service with your contract token |
34 | | - |
35 | | -``` |
36 | | -CONTRACT_TOKEN=<CONTRACT_TOKEN> docker compose -f docker-compose.thor10.yml up -d |
37 | | -``` |
| 14 | +2. Get a contract token from the [Nextron Portal](https://portal.nextron-systems.com/ui/contracts/contracts) (see [Contract-Token](#contract-token)) |
38 | 15 |
|
39 | | -### THOR 11 |
40 | | - |
41 | | -1. Download the compose file |
| 16 | +3. Start the service with your contract token |
42 | 17 |
|
43 | 18 | ``` |
44 | | -curl -O https://raw.githubusercontent.com/NextronSystems/thunderstorm-deployment/master/docker-compose.thor11.yml |
| 19 | +CONTRACT_TOKEN=<CONTRACT_TOKEN> docker compose up -d |
45 | 20 | ``` |
46 | 21 |
|
47 | | -2. Start the service with your contract token |
| 22 | +Thunderstorm is exposed on port **8080** by default. |
48 | 23 |
|
49 | | -``` |
50 | | -CONTRACT_TOKEN=<CONTRACT_TOKEN> docker compose -f docker-compose.thor11.yml up -d |
51 | | -``` |
| 24 | +## Contract-Token |
52 | 25 |
|
53 | | -On first start, Thunderstorm downloads the THOR binaries using your `CONTRACT_TOKEN` (your non-host-based Thunderstorm license) and persists them in a Docker volume so subsequent restarts are instant. THOR signatures are updated automatically on every start. |
| 26 | +Deploying Thunderstorm as a container requires a **non-host-based** Thunderstorm license. |
54 | 27 |
|
55 | | -Each compose file contains commented environment variables for all available configuration options. |
| 28 | +On first start, the container uses your contract token to download the THOR binaries and persists them in a Docker volume so subsequent restarts are instant. You can omit the contract token afterwards as long as the volume exists. |
56 | 29 |
|
57 | | -## Signature Updates |
| 30 | +A contract token can be retrieved from the [Nextron Portal](https://portal.nextron-systems.com/ui/contracts/contracts) under *Contracts & Licenses → Contracts → Actions → cloud icon → THOR Download Token*. |
58 | 31 |
|
59 | | -On every container start, THOR signatures are updated automatically. For THOR 11, signatures are additionally refreshed periodically while running (every 24 hours by default, configurable via `SIGNATURE_UPDATE_INTERVAL`). |
| 32 | +<img src="images/contract_token.png" alt="Contract Token location in Nextron Portal" width="500"> |
60 | 33 |
|
61 | | -### Rolling Deployment |
| 34 | +## Tech-Preview |
62 | 35 |
|
63 | | -If you are running a single Thunderstorm instance, you may want to use a Rolling Deployment to prevent a downtime of your Thunderstorm service. A Rolling Deployment spawns a new container and stops the old one after ensuring that the new one is healthy and ready to accept requests. The configuration differs between container management systems such as Kubernetes, Docker or Docker Swarm. |
| 36 | +If you want to use the techpreview channel (currently THOR 11) you need to set `TECHPREVIEW=1`. If it is omitted it will downgrade to the stable channel again. |
64 | 37 |
|
65 | | -For Docker we recommend `start-first` as value for `deploy.update_config.order`, as configured in both compose files. |
| 38 | +The compose file contains commented environment variables for all available configuration options. Some options only apply to specific THOR major versions, for example, `SIGNATURE_UPDATE_INTERVAL` is only available for THOR 11. |
66 | 39 |
|
67 | | -### Multiple Replicas |
| 40 | +## Signature Updates |
68 | 41 |
|
69 | | -If you want to deploy multiple Thunderstorm instances, we recommend to distribute the requests equally using a load-balancer such as [Traefik](https://traefik.io/traefik) or [Nginx](https://nginx.org). |
| 42 | +On every container start, THOR signatures are updated automatically. You can enforce a signature update by restarting the service with a brief downtime: |
| 43 | +``` |
| 44 | +docker compose up -d --force-recreate |
| 45 | +``` |
70 | 46 |
|
71 | | -## Passing Additional Arguments |
| 47 | +If a brief downtime is not acceptable, you may want to consider a Docker Swarm setup with start-first update config or use the [techpreview channel](#tech-preview) (currently THOR 11) which allows you to update signatures periodically while running. By default, THOR 11 updates signatures every 24 hours but it can be customized via `SIGNATURE_UPDATE_INTERVAL` environment variable. |
72 | 48 |
|
73 | | -Any argument supported by Thunderstorm or THOR can be passed via the `THUNDERSTORM_ARGS` and `THOR_ARGS` environment variables in the compose file. This means new parameters released in future versions are available immediately without any changes to the image or entrypoint. |
| 49 | +## Additional Arguments |
74 | 50 |
|
75 | | -For example, to forward scan results to a remote SIEM (THOR 11): |
| 51 | +If you need to customize the THOR scan behavior, you can pass additional arguments via `THOR_ARGS` environment variable. For example, to forward scan results to a remote SIEM: |
76 | 52 |
|
77 | 53 | ```yaml |
78 | 54 | environment: |
79 | 55 | THOR_ARGS: "--remote-log splunk.intern:514:DEFAULT:TCP --remote-log elastic.intern:1514:JSON:TCP" |
80 | 56 | ``` |
81 | 57 |
|
| 58 | +A full list of all supported arguments can be derived from the THOR binary using `./thor-linux-64 --fullhelp`. |
| 59 | + |
82 | 60 | ## Security |
83 | 61 |
|
84 | 62 | The communication between a client and the Thunderstorm service could involve sensitive files. Therefore, we highly recommend to encrypt the traffic using TLS by mounting the certificate and private key via the built-in secrets functionality of Docker or Kubernetes into the container. In addition, you need to specify the file path to the TLS certificate and private key in the environment variables `TLS_CERT` and `TLS_KEY`. |
85 | 63 |
|
86 | 64 | Out of the box, Thunderstorm API is unauthenticated and does not support authentication providers at the moment. If you require an authentication layer, we suggest to use a proxy middleware which delegates the authentication to an external provider such as [Microsoft Entra ID](https://www.microsoft.com/de-de/security/business/identity-access/microsoft-entra-id). |
| 65 | + |
| 66 | +## Limitations |
| 67 | + |
| 68 | +### Load-Balancing |
| 69 | +Thunderstorm allows you to send **asynchronous requests** and poll the results using an ID. Currently, Thunderstorm instances do not share their results with each other. If you run multiple Thunderstorm containers behind a load-balancer and request the results of an async request, you may not get the result from the correct Thunderstorm instance. We recommend to use async requests in combination with remote logging only in a load-balancer setup. |
0 commit comments