Dockerfile & Trickest YAML Configuration
In this section, we will guide you through the main principles of creating and building Dockerfiles that can be integrated into the Trickest platform.
Each tool will typically consist of files organized in a specific structure to ensure compatibility with Trickest's system.
Tool File Structure Overview
└── run.sh (optional, only if needed)
This is the file that will be used to generate the Docker image of the tool. If you are unfamiliar with the Docker and its concepts, you can learn more on this link.
To create efficient and light Docker images, follow best practices. But do keep in mind that although having small (in size) images (which means faster startup time) is essential, it is even more critical to have stable images. It's all about finding a compromise here, but pick stability if you have to choose.
Downloading the tool
Use one of the methods listed in versioning conventions to download a specific version of the tool into the docker image.
FROM golang:1.17.3-alpine AS build-env
RUN apk add --no-cache git
RUN go install -v github.com/author/tool-name@latest
RUN apk -U upgrade --no-cache \
&& apk add --no-cache bind-tools ca-certificates
COPY --from=build-env /go/bin/tool-name /usr/local/bin/
If the tool you use only supports
stdin as an input, check out Parameterizing stdin/stdout where you will learn how to create
run.sh and configure the tool to be compatible with Trickest platform.
It is important to remember to copy
run.sh it to your Docker image and configure it as the image
ADD run.sh /app/
RUN chmod +x /app/run.sh
RUN apk add bash
You need to create two folders:
/hive/out in the final image. These will be used by the platform to store and manage the tool's input/output.
RUN mkdir -p /hive/in /hive/out
Tips for better docker images
Compiled languages (e.g. golang)
- Use multi-stage builds to reduce the final image size
-alpineimages when possible
- You should almost always use
python:<version>-slim. This is a variant that has less packages installed, resulting in a smaller image.
- If you run into any problems with
-slim, the official image should be your second choice.
- Try to stay away from
alpine, because it might cause some unexpected issues.
Remeber to always tag your images properly according to the versioning guide.
trickest.yaml Configuration File
trickest.yaml file is essential for integrating tools into the Trickest platform, specifically designed for the Workflow Editor. This YAML file contains all the necessary data for the tool to be displayed appropriately and configured within the platform.
The YAML file is structured to provide comprehensive details about the tool, including its functionality, usage, and output handling. Below is a detailed explanation of each field in the trickest.yaml file:
This is an example of YAML Structure
description: This is an example of a private tool
description: This is description of input parameter
Tool Identification and Description
|Name of the tool
|Short description of the tool. The "About" section of GitHub is an excellent starting point if available
|The OWASP Amass Project performs network mapping of attack surfaces and external asset discovery using open source information gathering and active reconnaissance techniques.
|High-level category of the tool
|Original repository's URL
Docker Image and Command Execution
|Docker image URL. We use quay.io for hosting images
|Command that should be executed on the container when the node runs
|Command line parameter that designates the tool's output path
|Output type (file or folder)
|Name of the tool's license
|URL of the tool's license
Versioning NoteThe docker_image value should always use a Versioning Conventions. Never use :latest.
The parameters structure is as follows:
|Command line parameter used by the tool
|Name to identify the parameter in the node
|Type of the parameter (string, file, folder, or boolean)
|Short description of the parameter
|Domain names separated by commas
|The index of the parameter. The order is followed when building the final command
Next up: Versioning Conventions