Tern with kaniko

[ravenpride]

Hello Tern Team,

I'd like to know whether it is possible to use Tern with kaniko instead of the usual docker daemon. Kaniko allows to build docker images completely in userspace. Our CI pipeline uses kaniko as it runs in kubernetes and providing containers access to the docker daemon is risky, if the workload (the CI job) is not known in advance.

Thank you very much, Sascha

[nishakm]

@ravenpride Thanks for your question! Tern only requires the docker daemon to run for pull, save, images and build APIs. If Kaniko has equivalent Python APIs (or commands to shell out to), then it's possible to extend Tern to use Kaniko.

Some work is needed to get it to that stage though. Can you help with identifying a Python API for Kaniko or Kaniko equivalent for the above Docker commands?

[ravenpride]

@nishakm Thank you for your quick response. I'm afraid that kaniko does not work that way. Kaniko builds an image using a specific Dockerfile and pushes the resulting image straight to the specified registry. As far as I can see, there is no API except the one call to trigger the entire workflow :-/

If someone knows it better, please let me know - that would be a really great feature!

[HontoNoRoger]

I'm having a similar use case and I tried to get around this by taking kaniko's resulting image tar archive and shoving that into Tern with --raw-image. Unfortunately though, this doesn't yet work, as tern.analyze.default.container.run.extract_image seems to always expect a format docker save is exporting. This doesn't seem to be compatible with kanikos output though.

The result when tried is, every layer in the image.tar is another .tar.gz archive. On layer hashing, temp/contents is always deleted and reused for every layer in the sequence (tern/utils/rootfs.py:147). This finally leads to the OS check in tern.analyze.default.container.single_layer.get_os_style to check for an os-release file in the contents folder, which now only has the contents of the last layer analyzed in. And not the first layer where the release file is most likely to be found.

I quickly tried it out with fixed "oci" as format but that even crashes along the line. It might be beneficial to improve this handling of raw images (i.e. if not already dirs after main tar archive extraction, create a deeper folder structure by layer number when analyzing, just like with oci) so that Kaniko can also be supported, even if only via workarounds for now. At least it would help me a bunch :)