Adding container-storage as a provider for daemonless Podman and Buildah Support

[Bru456]

Adding Podman daemonless and Buildah support to Stereoscope for issue #197 and Syft issue 2107: Add support for containers-storage backend for container images

This feature adds:

• New provider containers-storage:
  • Takes the current user scope (root or user) to determine the container store and copies to a temporary docker archive via go.podman.io/image/v5 and delegates to the existing Docker archive provider.
  • Ensures the tags, os, architecture, and variant is populated.
  • Graceful continuation on miss/unavailable store to allow auto detection to move to the next provider.
• New source containers-storage to allow for either auto detection or explicit usage via --from containers-storage
• Provider registration: inserted before OCI registry provider so flow is daemon -> containers-storage -> remote registry. Allowing locally built images to resolve before a remote pull.
  • This only applies to Stereoscope I believe Syft and other consumers may have their own ordering.

Build

The new provider is opt-in at build time. Use the build tag containers_image_openpgp.

Without this tag, Stereoscope compiles a stub provider that reports that containers-storage support was not included.

Static Linux builds may also require the exclude_graphdriver_btrfs and exclude_graphdriver_devicemapper tags. These tags exclude optional graph drivers that require native system dependencies.

Dependency management

Pulled in go.podman.io/image/v5 v5.40.0 + go.podman.io/storage v1.63.0.

Tests

New unit tests are in and passing.
Tested compiling for both Linux and non Linux builds and bundling this with a local copy of the latest Syft. Docker, Podman (daemon and daemonless) and buildah all working and creating consistent SBOMs. Compared with Syft v1.46.0
previous-syft-json-sboms.zip
and new version with stereoscope
new-syft-json-sboms.zip

Issues encountered and fixes

• Dependency compatibility: The original implementation used the retired github.com/containers/image/v5 and github.com/containers/storage modules and required go.mod replacements for filepath-securejoin and selinux.

• Empty source.metadata (tags / os / architecture): the docker-archive copy is tagless, and the archive provider never sets os/arch.

  • Fix: gather tags from the store image's names and os/arch/variant from image inspect, and pass them through as additional metadata.

  This has been edited since orginal PR

[wagoodman]

This is pulling in github.com/containers/storage , however, this has recently migrated to podman-container-tools/container-libs.

Additionally, the use of replace directives will most likely block this from being merged as it will complicate / add friction to consumers of stereoscope (e.g. syft and grype and all lib consumers of those projects too).

[Bru456]

Thanks, @wagoodman I will look into this. The replace was only needed for Linux builds and was needed to get the containers storage to compile. I will see if the new lib sorts the need for replaces. :)

[Bru456]

@wagoodman, I’ve migrated the provider to go.podman.io/image/v5 v5.40.0 and go.podman.io/storage v1.63.0, removed both replace directives, and updated the imports and documentation accordingly. I have also rebased the branch from the latest commit (at time of writing) from main.

I also validated the changes using a personal Azure DevOps E2E pipeline. The pipeline:

• Cloned and built my stereoscope branch.
• Ran the unit tests with both the default and containers-storage build configurations.
• Cloned the current Syft source and built it against my stereoscope branch without any downstream dependency replacements.
• Built local images using Buildah.
• Successfully scanned those images using both implicit daemonless resolution and explicit --from containers-storage resolution.

Both E2E resolution paths completed successfully. Thanks for pointing me toward the migrated modules. 😄

Please note that containers-storage support is currently opt-in for downstream consumers such as Syft. Binaries must be built with the containers_image_openpgp tag; Linux static builds may also require exclude_graphdriver_btrfs and exclude_graphdriver_devicemapper.

If keeping this opt-in behavior is preferred, I can follow this with a Syft PR that enables the required tags in its release builds. If you would prefer containers-storage support to be compiled in by default, please let me know and I can revise the approach here.