Use a scratch based image to limit vulnerabilities

[morepork]

The alpine base image isn't needed as the statically linked go binary runs fine without it. Using a scratch based image reduces the number of vulnerabilities brought up by scanning tools in the alpine image, and makes the image a bit smaller.

[collin-lee]

Are we just using Alpine image for the certs? I see the change considers that. I think this is okay @arkodg

[arkodg]

hey there seem to be multiple GH issues around this

• provide distroless image #437
• Discussion: Ideal base image to build the container image #396

my recommendation would be to add a new distroless variant, if this approach is taken, the decision to be made is

• publish two images - one with a distroless- prefix in the tag and one without ( alpine)
• or publish one distroless image and rm alpine but that may break downstream users who have been relying on using the shell for debugging etc

[morepork]

My preference would be to just switch to a distroless image. It would still be possible to debug via an ephemeral debug container.

Having 2 images would also be fine, we could go with <tag> and distroless-<tag> as Arko suggests, which would be consistent with Envoy, but in my experience that leads to a lot of people using the non-distroless variant when they should really be using the distroless one, I always prefer to see a secure by default approach. Another naming scheme I've seen is to have <tag> be distroless, and also having a <tag>-debug or <tag>-alpine.

For us any option is ok, I'm happy to go with whatever you prefer.

[arkodg]

thanks and agree @morepork, just switching to distroless should be okay

[collin-lee]

like the distroless approach

[collin-lee]

Maybe something like this?

#993

[morepork]

Closing in favour of #993