Use alpine as base image
What does this MR do?
- We use
alpineimage as a base image. Then we installtrivyon top of that image. - We extract the Trivy version to install in a file. This will enable us to easily update the trivy version.
- Created a script used to download and install trivy. We download the correct zip file depending on the architecture
- Updated
build-docker-image.shin order to pass the architecture as an argument during the build process.
Why are we doing this?
We want to update the base image daily. The trivy image currently used extends the alpine image. We rely on trivy itself to fix vulnerabilities of the base image. In order to support quick vulnerability fixes in the base image we use alpine as a base instead of the trivy image. This way we can rebuild the image daily and get the latest version of the base.
What are the relevant issue numbers?
Implement nightly build policy for Trivy K8s Wr... (gitlab-org/gitlab#444470 - closed)
Merge request reports
Activity
assigned to @nilieskou
12 Warnings 
03f9d90f: The commit subject must contain at least 3 words. For more information, take a look at our Commit message guidelines. bd709bf8: The commit subject must start with a capital letter. For more information, take a look at our Commit message guidelines. bc41907a: The commit subject must contain at least 3 words. For more information, take a look at our Commit message guidelines. bc41907a: Commits that change 30 or more lines across at least 3 files should describe these changes in the commit body. For more information, take a look at our Commit message guidelines. 64a7588c: The commit subject must contain at least 3 words. For more information, take a look at our Commit message guidelines. b4d48668: The commit subject must contain at least 3 words. For more information, take a look at our Commit message guidelines. 79312b22: The commit subject must start with a capital letter. For more information, take a look at our Commit message guidelines. 26bc915c: The commit subject must start with a capital letter. For more information, take a look at our Commit message guidelines. d6361e89: The commit subject must contain at least 3 words. For more information, take a look at our Commit message guidelines. d6361e89: The commit subject must start with a capital letter. For more information, take a look at our Commit message guidelines. 43e76dd2: The commit subject must contain at least 3 words. For more information, take a look at our Commit message guidelines. 1f5b880b: Commits that change 30 or more lines across at least 3 files should describe these changes in the commit body. For more information, take a look at our Commit message guidelines. Reviewer roulette
Changes that require review have been detected! A merge request is normally reviewed by both a reviewer and a maintainer in its primary category and by a maintainer in all other categories.
To spread load more evenly across eligible reviewers, Danger has picked a candidate for each review slot. Feel free to override these selections if you think someone else would be better-suited or use the GitLab Review Workload Dashboard to find other available reviewers.
To read more on how to use the reviewer roulette, please take a look at the Engineering workflow and code review guidelines. Please consider assigning a reviewer or maintainer who is a domain expert in the area of the merge request.
Once you've decided who will review this merge request, mention them as you normally would! Danger does not automatically notify them for you.
Reviewer Maintainer No reviewer available No maintainer available If needed, you can retry the
danger-reviewjob that generated this comment.Generated by
Edited by Ghost Userchanged milestone to %17.1
added typemaintenance label and removed typefeature label
removed featureaddition label
requested review from @philipcunningham
Resolved by Nick Ilieskou@philipcunningham Could you please take a look on this MR?
- Last reply by Philip Cunningham
- Resolved by Nick Ilieskou
@nilieskou as asked on slack I had a quick look on this MR and I've just left a non-blocking suggestion.
Also, this is out of scope of this MR but I'm wondering why we don't bundle the Trivy-DB in this k8s wrapper like we do for CS? Looking at the code, I'm assuming this is pulled at runtime for each scan, right?
- Last reply by Nick Ilieskou
reset approvals from @philipcunningham by pushing to the branch
- Resolved by Nick Ilieskou
@hacks4oats I would really appreciate if you could take a look on this MR. For some reason the arm64 build job is failing. It seems like its timing out whenever it tries to perform an action that reaches the internet like
apk updateorwget. I think I might have a mistake in my Dockerfile or setup.sh script. I could use a second pair of eyes here and you are very good with Dockerfiles. Thanks in advance. - Last reply by Oscar Tovar
Resolved by Nick IlieskouIn order to support quick vulnerability fixes in the base image we use
alpineas a base instead of the trivy image. This way we can rebuild the image daily and get the latest version of the base@nilieskou, if
trivyis based onalpine, wouldn't addingapk update/upgradeto the existing build achieve the same result?I understand that the image would grow a bit, because this would add another layer with the updates but it might be a quicker iteration than replacing the whole image.
Sounds like you've done most of the work anyway, but I wanted to ask to see if I'm off.
Edited by Thiago Figueiró- Last reply by Nick Ilieskou
- Resolved by Nick Ilieskou
@hacks4oats I am trying to see why the arm64 job was failing in the first place.
When I committed the changes you suggested the pipeline was green: bc41907a but after my new commit ( 60d1e057) introducing the
ENVcommand the pipeline is timing out. This is weird right?On another front I have forked this project and tried to use
buildxwhich seems to work. Of course migrating to a version of the project where we use only buildx would require quite some work since its not straight forward. Mainly about how we push our images. We should keep this out of the scope of this issue.Edited by Nick Ilieskou - Last reply by Nick Ilieskou
-
@philipcunningham Could you please take another look on this MR? 2 things have changed since you last looked:
- We solve the problem with the failing build job on arm64 by adding
command: ["--mtu=1400"]in the Dind Service - I applied all the refactor points of @hacks4oats from !30 (comment 1911214296) (except adding an ENV command instead of exporting the PATH)
Thanks in advance
Edited by Nick Ilieskou - We solve the problem with the failing build job on arm64 by adding
mentioned in merge request !32 (merged)
-
Thanks, @nilieskou. I've added one nitpick but, otherwise, this LGTM. Approved!
mentioned in issue gl-retrospectives/secure-sub-dept/composition-analysis#46 (closed)
-
Why do we need MTU 1400 for DinD
From slack conversation and particularly this comment:
Hosted Runners are hosted in Google Cloud, and in GCP the VPCs by default have smaller MTU. The runner team had to reconfigure host level Docker Engine to match this MTU. This is why
--network=hostworks.But if you start a DinD process, it starts the nested Docker Engine configured with the default. And the default doesn't detect MTU on the host - it's simply hardcoded to 1500. Which is more than 1460 set by the Runners team on the host level. For many external networking requests that not a problem at all. Packets are smaller anyway and they don't hit MTU limit. But if you will try to generate bigger packets, especially ifDo not fragmentis set (some tools may do that), if the MTU doesn't match here strange problems can happen.Apparently, for some reason, it is even more visible on the arm64 nodes. And that's why aligning Docker-in-Docker MTU - with what the rest of our networking stack uses - helps. Because tools likeapkgenerate packets that fit in the MTU definition of the host.
