-
Notifications
You must be signed in to change notification settings - Fork 22
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
feat: Publish fortifydocker/fcli image
- Loading branch information
Showing
9 changed files
with
150 additions
and
0 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1 @@ | ||
fcli |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,78 @@ | ||
# This Dockerfile defines the following targets for building an fcli fcli Docker image: | ||
# - fcli-alpine | ||
# - fcli-ubi9 | ||
# - fcli-scratch | ||
# You can select between these variants by passing the --target option to the 'docker build' | ||
# command, for example 'docker build . --target fcli-alpine'. If no target is specified, all | ||
# targets may be built but the final image will correspond to the fcli-scratch target. | ||
# | ||
# In general, the fcli-scratch image is preferred to avoid having to deal with any CVEs reported | ||
# on the base images, and potentially having to provide refreshed images for older fcli versions | ||
# to fix such CVEs. Potentially, we could add commands to upgrade all base OS packages to reduce | ||
# the number of CVEs on those packages, in case the base image doesn't include those upgraded | ||
# packages yet. | ||
# | ||
# For now, we're only automatically publishing the fcli-scratch image for the reasons above; if | ||
# there's any demand, we can also publish ubi9, alpine and/or other (like busybox) images that | ||
# include a shell. Primary advantage is that this would allow for running a sequence of fcli | ||
# commands in a single container invocation (potentially removing the need to mount the data | ||
# directory to a persistent volume/host directory, as fcli state will be stored inside the container | ||
# for as long the container is alive). Primary disadvantage is that users might expect to be able to | ||
# run something like the following: | ||
# fcli tool sc-client install | ||
# scancentral package ... | ||
# submit scan request, ... | ||
# However, these images don't include Java (required to run ScanCentral Client) nor any other | ||
# build tools (which may be required by ScanCentral Client to properly package application source | ||
# code). Users would need to build a custom image that includes fcli and any other tools required | ||
# for building/packaging an application, or alternatively any of the fcli Docker images can be | ||
# used to install ScanCentral Client on the host system (using proper volume mappings), from | ||
# where it can be run with (presumably) all relevant build tools and Java being available. | ||
# | ||
# Before running the 'docker build' command, the fcli executable to be included in the image | ||
# must be copied into the same directory as this Dockerfile. The fcli build process will | ||
# automatically take care of this when releasing a new fcli version. For manual testing of | ||
# this Dockerfile, you can safely copy fcli 2.5.4 or above into your workspace; the .gitignore | ||
# file will have git operations ignore the fcli executable. | ||
# | ||
# All of the targets defined below have more or less the same structure: | ||
# - Add fcli user to /etc/passwd | ||
# - Add fcli executable to the image | ||
# - Add /data (and /tmp for fcli-scratch) directories with 777 permissions to the image | ||
# - Set WORKDIR to /data | ||
# - Set FCLI_USER_HOME to /data | ||
# - Set container user to fcli user | ||
# - Define an appropriate entrypoint (fcli for fcli-scratch, shell for others) | ||
# | ||
# Regarding FCLI_USER_HOME, fcli uses user.home by default, but if the Docker container is being | ||
# run as a different user through 'docker run -u <UID>:<GID>', user.home returns a directory | ||
# containing a '?' to represent unknown user name for the given UID, which causes issues. Fcli | ||
# versions 2.5.4 and up allow for overriding user.home through FCLI_USER_HOME. | ||
|
||
FROM alpine:3 AS fcli-alpine | ||
RUN echo "fcli:x:10001:10001:fcli:/data:/sbin/nologin" >> /etc/passwd | ||
ADD fcli /bin/fcli | ||
ADD data.tgz / | ||
WORKDIR /data | ||
ENV FCLI_USER_HOME=/data | ||
USER fcli | ||
ENTRYPOINT ["/bin/sh"] | ||
|
||
FROM redhat/ubi9-minimal:9.4 AS fcli-ubi9 | ||
RUN echo "fcli:x:10001:10001:fcli:/data:/sbin/nologin" >> /etc/passwd | ||
ADD fcli /bin/fcli | ||
ADD data.tgz / | ||
WORKDIR /data | ||
ENV FCLI_USER_HOME=/data | ||
USER fcli | ||
ENTRYPOINT ["/bin/bash"] | ||
|
||
FROM scratch AS fcli-scratch | ||
ADD minimal-passwd /etc/passwd | ||
ADD fcli /bin/fcli | ||
ADD tmp.tgz / | ||
ADD data.tgz / | ||
WORKDIR /data | ||
ENV FCLI_USER_HOME=/data | ||
USER fcli | ||
ENTRYPOINT ["/bin/fcli"] |
Binary file not shown.
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1 @@ | ||
fcli:x:10001:10001:fcli:/data:/sbin/nologin |
Binary file not shown.
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1 @@ | ||
fcli.exe |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,46 @@ | ||
# This Dockerfile allows for building a Windows-based fcli image. Although functional, for now | ||
# this is considered just a prototype and not automatically published; we can fine-tune and | ||
# publish if there's any demand for a Windows-based image. Note that may suffer from some of | ||
# the same issues regarding base OS CVEs and ability run run ScanCentral Client as detailed in | ||
# the Linux Dockerfile. | ||
# | ||
# Some questions to be answered (also see more detailed comments on the actual Dockerfile instructions): | ||
# - What base image to use for the final image; nanoserver, servercore, ...? | ||
# - Any improvements necessary for VC++ redistributables installation? | ||
# - Should container run as ContainerUser, or should we create fcli user like for the Linux images? | ||
# - Should we have fcli.exe or CMD.exe as entry point (or both)? | ||
# | ||
# Before running the 'docker build' command, the fcli Windows executable to be included in the | ||
# image must be copied into the same directory as this Dockerfile. If we decide to automatically | ||
# release Windows-based images, the fcli build process will automatically take care of this when | ||
# releasing a new fcli version. For manual testing of this Dockerfile, you can safely copy fcli.exe | ||
# 2.5.4 or above into your workspace; the .gitignore file will have git operations ignore the fcli | ||
# executable. | ||
|
||
# Install Visual C++ redistributables; this requires at least servercore and will fail on nanoserver, | ||
# hence we do this in a separate build phase. | ||
FROM mcr.microsoft.com/windows/servercore:ltsc2022 as installer | ||
ADD https://aka.ms/vs/17/release/vc_redist.x64.exe /vc_redist.x64.exe | ||
RUN /vc_redist.x64.exe /install /quiet /norestart | ||
|
||
# Build fcli nanoserver-based image. We manually copy any VC++ DLLs required by fcli into this image | ||
# from the installer phase above. This process is somewhat fragile and may break the image if a future | ||
# fcli version requires additional VC++ DLLs but we forget to update the Dockerfile to copy them. We | ||
# may want to add an instruction like 'RUN fcli -h' instruction after installing fcli, to ensure fcli | ||
# can run successfully with the manually copied set of DLLs. | ||
FROM mcr.microsoft.com/windows/nanoserver:ltsc2022 AS fcli-ltsc2022 | ||
COPY --from=installer C:/Windows/System32/vcruntime140.dll C:/Windows/System32/vcruntime140.dll | ||
COPY --from=installer C:/Windows/System32/vcruntime140_1.dll C:/Windows/System32/vcruntime140_1.dll | ||
ADD fcli.exe C:/bin/fcli.exe | ||
ADD data.tgz C:/ | ||
WORKDIR C:/data | ||
ENV FCLI_USER_HOME=C:/data | ||
USER ContainerUser | ||
# TODO, do we want to have the image have fcli as the entrypoint to mimic behavior of the fcli-scratch | ||
# Linux image, or CMD.exe as the entrypoint to mimic behavior of the shell-based Linux images? Maybe | ||
# we want to have both, in which case we'd remove the ENTRYPOINT instruction here, and move it two | ||
# two new build stages that use this build phase as the base image, just adding the applicable ENTRYPOINT | ||
# (and PATH for CMD.exe-based image) to those new build stages. | ||
# ENV PATH=$PATH:C:\bin # Only for interactive shell image? Might also be useful for fcli entrypoint, as | ||
# # users may override the entrypoint to CMD.exe. | ||
ENTRYPOINT ["C:\\bin\\fcli.exe"] |
Binary file not shown.