bom
bom copied to clipboard
kubernetes-sigs
build a distroless base image to be used for bom based on apko and melange
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^1 and melange^2.
cc: @justaugustus @kaniini @imjasonh @cpanato
Why is this needed:
To provide a proper base image for bom tool that fits its needs.
This might help us 👇
https://github.com/chainguard-dev/hello-melange-apko
cc: @jdolitsky @puerco
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.
melange would be required to get bom into APK format if wanting to use apko to build the image
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.
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).
Similar issues: https://github.com/google/go-containerregistry/issues/1356
Once we complete it on the ko project side, maybe, later on, we can do the same one here.
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:
https://github.com/google/go-containerregistry/pull/1454
I don't think we require git and go as runtime dependency for bom (this is worth a second look).
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 - build the container image by simply running:
KO_DOCKER_REPO=ko.local BOM_LDFLAGS= ko build -B ./cmd/bom - 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 . - You will get an error something like the following:
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?
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.
kindly ping folx ☝️ I did a similar issue on the ko project side.
https://github.com/google/go-containerregistry/pull/1454
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.
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/staleis applied - After 30d of inactivity since
lifecycle/stalewas applied,lifecycle/rottenis applied - After 30d of inactivity since
lifecycle/rottenwas 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
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/staleis applied - After 30d of inactivity since
lifecycle/stalewas applied,lifecycle/rottenis applied - After 30d of inactivity since
lifecycle/rottenwas 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
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/staleis applied - After 30d of inactivity since
lifecycle/stalewas applied,lifecycle/rottenis applied - After 30d of inactivity since
lifecycle/rottenwas 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-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/staleis applied- After 30d of inactivity since
lifecycle/stalewas applied,lifecycle/rottenis applied- After 30d of inactivity since
lifecycle/rottenwas applied, the issue is closedYou 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.
