Repository navigation
Build the image from a pinned base and add a pipeline that scans it - #1
Merged
Merged
Conversation
The base image was pinned to a version of ubuntu, the build of the image was broken. The base image is ubuntu 24.04 now, the current long term support release, and the user is only created when it is not there yet. The base image of ubuntu 24.04 already has a user with the id 1000. Four things kept the build from working: * The argument for the version of the package had the form "ARG name value", which does not set a default. The form with the equal sign is used now. * The address of the release of terrascan was read out of the answer of the github api with a pattern that matched the whole answer instead of the address of the file. * The install script of tflint is gone, the release of the project has the program as an asset now. * The packages of pip are installed into the system python on purpose, the image is a toolbox. Ubuntu marks the system python as managed, the packages would not be installed without the option. The entrypoint of the container failed when the environment did not have the variable for the user. The guard for it expanded the variable that was not set, and the script stops on that. The same was done for the variable of the home directory. The repository had no pipeline, the image was built and published by hand. The pipeline builds the image, tests that it starts, that it runs as an unprivileged user and that the tools are in the image, and it scans the image for vulnerabilities and for secrets. A finding fails the build. The release workflow builds the image for a tag, scans it, tests it and publishes it to the Docker Hub and to the GitHub container registry. It only publishes when the build of the branch passed and the image is clean.
…stem The image holds a lot of programs that are built with go, the findings of their dependencies can not be fixed in the image. They are reported by the pipeline, the gate looks at the packages of the operating system.
The keys of the host are made by the script of the package openssh-server when the package is installed. They were part of the image, so every container that was made from the image used the same keys. They are taken out of the layer that makes them now, so they are not part of the image at all, and the entrypoint makes them again when the container starts.
This file contains hidden or 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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
The base image was pinned to a version of ubuntu, the build of the image was broken. The base image is ubuntu 24.04 now, the current long term support release, and the user is only created when it is not there yet.
Four things kept the build from working:
ARG name value, which does not set a default. The form with the equal sign is used now.The entrypoint of the container failed when the environment did not have the variable for the user. The guard for it expanded the variable that was not set, and the script stops on that. The same was done for the variable of the home directory.
The repository had no pipeline, the image was built and published by hand. The pipeline builds the image, tests that it starts, that it runs as an unprivileged user and that the tools are in the image, and it scans the image for vulnerabilities and for secrets. A finding in the packages of the operating system fails the build, the findings of the programs that are part of the image are reported.
The release workflow builds the image for a tag, scans it, tests it and publishes it to the Docker Hub and to the GitHub container registry. It only publishes when the build of the branch passed and the image is clean.