build: new container images for minimal alpine runtime

[cazlo]

what

• Add 2 new alpine container image builds aimed to reduce image size and vulnerability state

why

• reduced image size -> less time to scale the system up on nodes without the image in cache
• reduced image size -> less cost to warehouse the artifact
• less dependencies -> less vulnerabilities

tests

I have tested my changed by building them locally and asserting non-zero exit code to build. I added make commands to facilitate this task.

For this commit, image sizes when built using the new make commands:
debian = 812.08 MB
alpine = 647.28 MB
alpine-slim-terraform = 209.72 MB
alpine-slim-tofu = 204.51 MB

references

closes #5366

[jamengual]

mmmm maintaining more images is a lot of maintenance; we will have to think about this.

[X-Guardian]

I agree with @jamengual. I don't see any need for this. I've commented on the issue.

[chenrui333]

yeah, I also feel so, adding more images in the core feels unnecessary.

[cazlo]

As additional quantification for the value add, here is the current vulnerability state, with the only change from main being the removal of old tofu or terraform bins:

Vuln summary for atlantis:latest-alpine.json =
                   CRITICAL=7 HIGH=14 MEDIUM=32 LOW=2 
 [unique CVE only] CRITICAL=2 HIGH=6 MEDIUM=10 LOW=1 

Vuln summary for atlantis:latest-alpine-slim-terraform.json =
                   CRITICAL=3 HIGH=3 MEDIUM=9 LOW=0 
 [unique CVE only] CRITICAL=1 HIGH=1 MEDIUM=3 LOW=0 

Vuln summary for atlantis:latest-alpine-slim-tofu.json =
                   CRITICAL=2 HIGH=3 MEDIUM=10 LOW=0 
 [unique CVE only] CRITICAL=1 HIGH=2 MEDIUM=4 LOW=0 

Vuln summary for atlantis:latest-debian.json =
                   CRITICAL=8 HIGH=20 MEDIUM=69 LOW=139 
 [unique CVE only] CRITICAL=3 HIGH=9 MEDIUM=25 LOW=58 

This report was generated with trivy.

I can remove the bins in a downstream image like:

FROM ghcr.io/runatlantis/atlantis:v0.33-alpine
RUN rm -rf /usr/local/bin/terraform1.* && \
          rm -rf /usr/local/bin/tofu*

However this doesn't really solve the problem; We still have to transfer the layers with all the bins on them, and then an additional layer which removes the bins. Additionally deep scanning of this built image will still reveal layers with the CVES on them.

Also there is unnecessary bin duplication present it would seem; e.g. terraform 1.10.5 is present in 2 bins:

• /usr/local/bin/terraform
• /usr/local/bin/terraform1.10.5

instead of binary duplication, if we really do need the second bin, it should probably be a simlink

[cazlo]

I understand risk of additional maintenance (why I noted it in the original issue). However I have implemented this in a way where there is virtually no duplication of effort needed; effectively all the same Docker layers are used from current and the test case variance is minimal. I'd be happy to take on the maintenance of this so I don't have to spend time maintaining a fork for this image.

[X-Guardian]

Still not convinced me. You can easily use a multi-stage Dockerfile to completely remove the files.