build a distroless base image to be used for bom based on apko and melange

[developer-guy]

What would you like to be added:

Based on the comment that @puerco did, it'd be better to have a base image for bom tool that includes all the necessary packages such as go, git, etc. The proper way of doing it is that use a tech stack including apko¹ and melange².

cc: @justaugustus @kaniini @imjasonh @cpanato

Why is this needed:

To provide a proper base image for bom tool that fits its needs.

#137 (comment)

Footnotes

1. https://github.com/chainguard-dev/apko ↩

2. https://github.com/chainguard-dev/melange ↩

[developer-guy]

This might help us 👇

https://github.com/chainguard-dev/hello-melange-apko

cc: @jdolitsky @puerco

[imjasonh]

If we could enumerate the packages that bom needs that would be helpful. Common things like go and git are already available as apk packages and should be very easy to bundle into an image using apko. melange should only be necessary if there's other code we'd depend on that isn't already available as an apk.

Does bom require Git to fetch Go modules? e.g., does it run go get? It might not need more than go to work.

[jdolitsky]

melange would be required to get bom into APK format if wanting to use apko to build the image

[imjasonh]

I thought the plan was to make a base image that contained all the things bom needed, then use ko to build bom on top of that base.

You could also use melange to build bom as an apk and use apko to stitch it into an image, but I'm not immediately sure what the benefit of that is over using ko and apko.

[jdolitsky]

I thought the plan was to make a base image that contained all the things bom needed, then use ko to build bom on top of that base

Didn't see any mention of ko, but that would work too 😄 In fact, that would add the benefit of surfacing an SBOM from this package (no way to do this in melange currently).

[developer-guy]

Similar issues: google/go-containerregistry#1356

Once we complete it on the ko project side, maybe, later on, we can do the same one here.

[developer-guy]

I've created PR to create a base image to be used for debugging purposes in ko, and we can achieve the same one in bom tool as well:

google/go-containerregistry#1454

[developer-guy]

if it looks legitimate, I can do the same one for the bom tool.

[developer-guy]

kindly ping @cpanato @saschagrunert

[saschagrunert]

I don't think we require git and go as runtime dependency for bom (this is worth a second look).

[cpanato]

no it does not need afaik

[developer-guy]

Unfortunately, the problem still exists, to reproduce the same issue here¹:

1. replace the base image definition defined in .ko.yaml with: cgr.dev/chainguard/static:latest
2. build the container image by simply running: KO_DOCKER_REPO=ko.local BOM_LDFLAGS= ko build -B ./cmd/bom
3. run the image on the same directory of the bom project: docker container run --rm -v $(pwd):/work -w /work ko.local/bom:latest generate .
4. You will get an error something like the following:

Footnotes

1. https://github.com/kubernetes-sigs/bom/issues/135 ↩

[imjasonh]

Does bom expect the go executable to be present? The "go executbale not found" error sounds suspicious. If so, basing its image on static will be a problem. Can you try basing it on golang and see if that helps?

[developer-guy]

Does bom expect the go executable to be present?

yep, this is why we set the current base image of the bom project as ghcr.io/chainguard-images/go:latest here.

[developer-guy]

kindly ping folx 👋

[developer-guy]

kindly ping folx ☝️ I did a similar issue on the ko project side.

google/go-containerregistry#1454

[saschagrunert]

Do we have any volunteer from @kubernetes-sigs/release-engineering who can provide us an overview how the go binary is required by the bom golang code?

Edit: go, not git.

[developer-guy]

not git, bom requires go executable ☝️ @saschagrunert

[saschagrunert]

Ah, alright thank you for the clarification!

[k8s-triage-robot]

The Kubernetes project currently lacks enough contributors to adequately respond to all issues.

This bot triages un-triaged issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue as fresh with /remove-lifecycle stale
• Close this issue with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale

[developer-guy]

I'm still interested in doing this, folx.

[k8s-triage-robot]

The Kubernetes project currently lacks enough active contributors to adequately respond to all issues.

This bot triages un-triaged issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue as fresh with /remove-lifecycle rotten
• Close this issue with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle rotten

[k8s-triage-robot]

The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs.

This bot triages issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Reopen this issue with /reopen
• Mark this issue as fresh with /remove-lifecycle rotten
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/close not-planned

[k8s-ci-robot]

@k8s-triage-robot: Closing this issue, marking it as "Not Planned".

In response to this:

The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs.

This bot triages issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Reopen this issue with /reopen
• Mark this issue as fresh with /remove-lifecycle rotten
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/close not-planned

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.