Date: 2024-11-15
Proposed
Tekton Tasks often depend on specific CLI tools.
The tools come from a restricted set of container images
(see allowed_step_image_registry_prefixes in the policy data).
If no image containing a required CLI tool already exists, the current approach is to build a new image specifically for that one tool. Or to add the tool to one or more of the existing images, if Task authors find that more convenient. Examples:
yq and a copy of one script from build-trusted-artifacts)git-init tool, also includes find)dockerfile-json, rsync, kubectl, jq, subscription-manager and others)Then, we have some use-case-oriented containers which are somewhat intertwined with the tool-oriented containers (or at least share software, sometimes installed using different approaches).
oras and jq)skopeo and jq)And last, some Tasks use the appstudio-utils image, which contains a variety of tools installed straight from GitHub releases. Many of which are also available in the tool-oriented containers (and installed via more legitimate means).
The current situation increases confusion, maintenance burden (both for the container
maintainers and for build-definitions maintainers) and, in case of appstudio-utils,
breaks good secure supply chain practices.
The set of CLI tools you need may already be containerized, but in two or more separate
containers. In that case, rather than adding the tools you need to one of the containers,
the better solution could be to take advantage of Tekton Tasks’ steps feature (each
step can use a different container image).
Could be, but isn’t. In practice, what this achieves is:
The Enterprise Contract team has developed the Trusted Artifacts concept to enable Konflux users to add custom Tasks to the pipelines without compromising the trustworthiness of the build.
But Konflux users face the same difficulties described above (made worse by the fact that they don’t tend to have much Tekton experience). The initial hurdle of finding/building the right container image for what they want to do may be too high.
Build and maintain a common “Task Runner” image.
The image must:
Gradually deprecate all the current tool-oriented container images and replace their usage with the common Task Runner image.
The Task Runner image does not replace the more specialized use-case-oriented images, but they can use it as a base image if desirable.
To include a tool in the Task Runner image, it should meet these requirements:
The maintenance of container images needed for Tasks becomes more consolidated. The total number of rebuilds needed due to CVEs stays the same but is not scattered across tool-container repos anymore.
Tasks get easier to write because all the tools you need are available in the same image. For both Konflux devs and Konflux users.
Tasks have lower resource requirements because there’s less of a need to split them into steps.
The Task Runner image is larger than any of the individual images used by the Tasks at present. But it’s much smaller than all the individual images combined. And because Tasks don’t pull the image if it’s already cached on the compute node, this is a win (there’s a smaller set of images to cache, less pulling to do).
By reducing the reliance on a Tekton-specific feature (steps), most Tasks become nothing more than a bash script wrapped in some YAML. It enables a saner approach to authoring Tasks. Write a bash script that works on your machine, wrap it in a bunch of YAML, verify that it works, ship it. Exceptions can still exist where necessary/justified. For example, the Trusted Artifacts variants of Tasks would still use separate steps to create/use the artifacts.