Overview
This write-up covers the following two use case:
- Using the I-C to perform SaaS upload/scans of an application build (“artifact”).
- 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.
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.
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 cybric.py
OR
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 cybric.py
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 cybric.py
IMPORTANT POINTS:
- 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 theC:
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 toC:\
(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