Docker on Windows - Integration Container


This write-up covers the following two use case:

  1. Using the I-C to perform SaaS upload/scans of an application build (“artifact”).
  2. Using the I-C, and the necessary “runners”, to perform onprem scans of the same. We assume that the user performing the action has already done “docker login” or similar to pull the runners in advance.


  • Docker desktop version (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.

SaaS (upload/scan) example

Here, everything works in a manner similar to how it works in Unix/Linux. Note that you can specify the local paths in either DOS or Unix/Linux format:

docker run -v c:\Users\jeecybricio\zn\training\TinyGoat-Build-master:/code -v c:\Temp:/results -e POLICY_ID=..... -e CYBRIC_API_KEY=..... zeronorth/integration:latest python
docker run -v /c/Users/jeecybricio/zn/training/TinyGoat-Build-master:/code -v /c/Temp:/results -e POLICY_ID=..... -e CYBRIC_API_KEY=..... zeronorth/integration:latest python

Onprem Scan example

Onprem (local) scans require a modified set of parameters:

docker run -v /var/run/docker.sock:/var/run/docker.sock -v /c/Temp:/results -e WORKSPACE=/c/Users/jeecybricio/zn/training/TinyGoat-Build-master -e POLICY_ID=..... -e CYBRIC_API_KEY=..... zeronorth/integration:latest python


  • Before performing any onprem scans in this manner, be sure to read through ZeroNorth™ Integration-Container - Onprem Scanning to ensure that basic prerequisites are met, including requesting access to additional Docker Images from ZeroNorth, and doing docker login prior to pulling those images.
  • Local paths can be specified like /c/... assuming that the C: drive is set as a share in the Docker settings.
  • Additionally, the Docker service on Windows provides some basic mount points when it starts up:
    • /host_mnt/c points to C:\ (you can still use /c/... ).
    • /var/run/docker.sock is provided.
  • /var/run/docker.sock - the mount for the TCP socket actually works fine like this:
    -v /var/run/docker.sock:/var/run/docker.sock
    This appears to be a new feature with recent implementations of Docker for Windows.
  • /code - this bind mount is not needed for the onprem scan. But the value for WORKSPACE is important (see below).
  • WORKSPACE - the value of this variable is passed to the runner which will create its own bind mount to /code based on it. It should in a form like one of the following:
    • /c/Users/.../...
    • /c/...
    • Examples:
      • /c/Users/jee/apps/myapp
      • /c/mycompany/apps/myapp

NOTE: no need to specify a trailing / .

  • /results - as in the SaaS/local/non-onprem examples above, either of the following will work:
    • -v c:\Temp:/results
    • -v /c/Temp:/results