Build image with ko

[johngmyers]

Description

Builds image with ko instead of Docker. Reduces build times, allowing developer builds to use cached module sources.

Replaces the base image with ko's default of cgr.dev/chainguard/static:latest (based on distroless). This reduces the size and attack surface of the resulting image.

Adds arm/v7 image back in.

Checklist

• Unit tests updated
• End user documentation updated

[Raffo]

@johngmyers can you add some info on why this change?

[johngmyers]

/retest

[Raffo]

@johngmyers why did you remove the trivy scanner? That can spot vulnerabilities also in the binary being built.

[johngmyers]

@Raffo it looked like trivy expected the image to be present in a local docker server.

I don't think we can add much value by scanning the distroless-derived base image. We have coverage for Go module dependencies through the GitHub security notification stuff.

[Raffo]

Ok for trivy.

What kind of advantage is the chainguard image bringing compared to google's distroless? And is ko widely used in the Kubernetes ecosystem? I would love for us to stick with somewhat standard approaches and not be too much far away from what the community uses, if there's a standard. I would personally not adopt ko unless explicitly recommended by the kubernetes community, but I'm also not opposed to it. @szuecs @mloiseleur any takes on this topic?

[johngmyers]

I believe Chainguard is adding the SBOM (Software Bill Of Materials). I have the SBOM disabled in this because it might require changes in the release tooling.

I don't know what counts as "widely", but two other Kubernetes projects I'm involved in, kops and aws-load-balancer-controller, both use it.

[mloiseleur]

According to ko.build documentation, they provide SBOM by default.

• ko.build is a simple Go lang software solving a real issue on multi-arch build. It is open source, is integrated to sigtore and is maintained by 3 people. It does not seem to be a commercial product. I am aware that at least one of the maintainer is working on many others kubernetes related projects.
• cgr.devand chainguard, on the other hand, is clearly a commercial product. The recent announcement is clear. The public repo also, containing their packaged version of public software.

Since ko.build can be easily replaced if needed,
Since SBOM is quite interesting and may become a standard,
Since that with ko.build we will have less code to maintain and faster multiarch build,
=> My humble advice would be to use ko.build with Google distroless.

It's not a strong opinion, I'm not opposed to keep the current system (with a distro less image) or using chainguard.

[Raffo]

I don't know what counts as "widely"

That is a very good point, it's not easy to define as the community is big and projects managed significantly differently.

I would agree with @mloiseleur and be for using ko with distroless as base image, if possible. If we truly believe that the chainguard image is making a difference, then we can do that as well.

For the sbom, those can easily be downloaded from the GitHub dependency graph or CLI these days, but also open to improvements in this area as needed.

[johngmyers]

I chose chainguard because that is the ko default.

[Raffo]

Reading the original kep (https://github.com/kubernetes/enhancements/blob/master/keps/sig-release/1729-rebase-images-to-distroless/README.md) it seems to be that distroless should be used across the board by community projects. Given that there are no specific reason to use chainguard's, even if there are no drawbacks, I would choose Google's distroless as base image.

[mloiseleur]

/lgtm

[mloiseleur]

/assign Raffo

[Raffo]

/approve

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: johngmyers, Raffo

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

• OWNERS [Raffo]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[edbighead]

does anyone else get the CreateContainerConfigError with v0.13.6 image

    state:
      waiting:
        message: 'container has runAsNonRoot and image will run as root (pod: "external-dns-5bf5f97c4-bw7mg_kube-system(d7ec6cb8-d04d-4c40-b333-1b51c5b69219)",
          container: external-dns'
        reason: CreateContainerConfigError