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.
- Docker desktop version 126.96.36.199 (service v19.03.5), or later. See the related article Docker on Windows - Installation for details.
C:drive is declared in Docker settings as a shared drive. This is kinda important.
- OPTIONALLY, add your Windows user account to the
docker-usersgroup 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
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
- 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 loginprior 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:
C:\(you can still use
/var/run/docker.sock - the mount for the TCP socket actually works fine like this:
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
WORKSPACEis important (see below).
WORKSPACE - the value of this variable is passed to the runner which will create its own bind mount to
/codebased on it. It should in a form like one of the following:
NOTE: no need to specify a trailing
/results - as in the SaaS/local/non-onprem examples above, either of the following will work: