Docker on Windows - Integration Orchestrator

ZeroNorth Experts
, , ,
1

Overview

This write-up covers the following two use case:

  1. Using the I-O to perform onprem “DAST” scans such as Nmap, etc…
  2. Using the I-O, and the necessary “runners”, to perform onprem repo (e.g. Bitbucket Enterprise, GitHub Enterprise, etc.) scans. We assume that the user performing the action has already done “docker login” or similar to pull the runners in advance.

Prerequisites

  • Docker desktop version 2.1.0.5 (service v19.03.5), or later. See the related article Docker on Windows - Installation for details.
  • The C: drive is declared in Docker settings as a shared drive. This is kinda important.
  • OPTIONALLY, add your Windows user account to the docker-users group at the OS level.
  • No need to create a /shared folder on the local host. See details below.

Refer to the article Docker on Windows - Integration Container for related information.

Launching the Integration Orchestrator

Start the I-O like below, but there is NO need to create /shared on the local drive anywhere prior to running the command:

docker run -v /shared:/shared -v /var/run/docker.sock:/var/run/docker.sock --env-file env.local.jee.student zeronorth/integration-orchestrator:latest "/app/run.sh"

Without /shared - sufficient for onprem “DAST” scans:

docker run -v /var/run/docker.sock:/var/run/docker.sock --env-file env.local.jee.student zeronorth/integration-orchestrator:latest "/app/run.sh"

NOTE the use of double-quotes around /app/run.sh . Use either double-quotes or no quotes. Windows does not like single quotes, because that means something else.

What works

  • Onprem DAST - scans like Nmap, etc. work fine as is expected.
  • Onprem GitHub (cloud) scan - This one is strange. The cloning of the repo appears to be done by the runner instead of the I-O. This is probably because the Integration, though it is set as onprem, is for GitHub cloud, so the cloning is done by the runner.
  • Onprem BBE repo scan - It works as expected despite the fact that the C: drive did not actually contain a folder named c:\shared .

Looking more into why the above repo scan technique works:

Inspecting the Docker containers, we find:

The I-O:

The Runner:

So, then exec 'ing into the I-O container, we find:

Looking at the timestamps of the two subfolders in /shared , it’s evident that the /shared mount point is not ephemeral (per container). So, maybe the Docker service must be providing it ondemand? Restarting the Docker service appears to clean out the /shared mount.