Injecting a shell into steps?

[imjasonh]

I've talked about this a bit with @bobcatfish in the past, and maybe others, but I wanted to float it here before writing up a full TEP (and I wanted to try out GitHub Discussions 😎 )

Tekton could inject a basic shell into steps, similar to how we inject the entrypoint binary, by adding an initContainer that copies a binary into a shared volume under /tekton/something. This would let steps that don't include a shell to take advantage of script: and perform basic actions in the step environment.

We've had some TEPs (#302, #182, #342, others) that boil down to "I want to do something shell-ey, and my image doesn't have a shell". This would give us an avenue to solve those cases without reimplementing shell-like features in Tekton itself.

Examples

steps:
- image: gcr.io/go-containerregistry/crane  # image doesn't provide a shell
  script: |
    #! /tekton/tools/sh
    crane cp foo bar || exit 0  # ignore failure

steps:
- image: gcr.io/go-containerregistry/crane
  script: |
    #! /tekton/tools/sh
    crane push foo > /tekton/results/image-digest  # redirect output to results

How

busybox provides a shell and basic tools in a single binary inside a multi-arch image (supports amd64, arm, arm64, ppc64le, s390x, plenty of others). Busybox is GPL, so if that's a problem we could find another alternative.

Considerations

• Security: Maybe operators don't want to provide a shell, perhaps for security reasons; how would they disable it? They might want to disable it for the entire installation, or for only certain pipelines or tasks or steps.
• Configuration: Operators should be able to configure what image provides the shell, like they do with image flags on the controller today. Tekton's vanilla installation should come with
• Architecture portability: Any image Tekton chooses by default should support as many CPU architectures as possible
• OS portability?: Someday Tekton would like to support Windows. script: already makes that support difficult, and shell injection can make this even worse. Let's be aware of the tradeoffs at least.

If this seems worth exploring, I can propose a TEP.

[bobcatfish]

A couple requirements I'd like to see (I'm kinda just repeating your considerations XD)

• Tasks must explicitly declare when they need a shell injected
• Operators must be able to configure what "shell" is injected from what image
• I think we'd explicitly NOT want to encourage ppl to use this to inject "anything" into steps (i.e. treat that as an entirely different problem set / use cases) (tho we'd probably never be able to stop someone from doing this if they really wanted to XD)

[skaegi]

We looked at transforming our Tasks and injecting Dash (https://git.kernel.org/pub/scm/utils/dash/dash.git) vs. busybox with the same init container technique as a workaround for managing step failure. Injecting shells, debuggers, etc. via this approach is a pretty powerful technique, I'm just not sure it's a platform vs. document thing.