From 68e44c629c9ee287393681030ed391d2c2e856cd Mon Sep 17 00:00:00 2001 From: Christie Wilson Date: Thu, 22 Jul 2021 13:50:50 -0700 Subject: [PATCH] =?UTF-8?q?Recommend=20versioning=20script=20instead=20of?= =?UTF-8?q?=20using=20configmap=20=F0=9F=93=9D?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit When discussing some potential ways a Task could be compromised, @afrittoli mentioned that if a Task refers to some remote source for a script, there is the potential for that source to be modified and run something malicious inside a Task. As he described this, he mentioned that our catalog recommends putting scripts into configmaps, which I was surprised to see. A script inside a configmap does have this potential attack vector (though you'd have to have write access to the configmap to pull it off) but I'm actually a bit more concerned that this isn't a great solution for maintaining scripts over time. Not to mention that I'm not how we would support this in the catalog (we'd have to start supporting applying and versioning ConfigMaps alongside the Tasks that reference them). So this commit changes the recommendation to recommend 'graduating' large scripts from script to tools and treating them like you'd treat other code. This is still not a fantastic solution as it requires you to maintain and publish your own images but I think it's a step in the right direction (and if it helps, I could also see a world where we support storing and publishing those images via the catalog as well - though I'm pretty sure @vdemeester disagrees with me here). --- recommendations.md | 59 +++++++++++++--------------------------------- 1 file changed, 16 insertions(+), 43 deletions(-) diff --git a/recommendations.md b/recommendations.md index 074ded3e9a..777d4a54d6 100644 --- a/recommendations.md +++ b/recommendations.md @@ -174,49 +174,22 @@ maintain it in-line. Because you have already avoided interpolation in the script, there is no real need for the script to be in-lined into the Task. -Use a ConfigMap for your script, and mount the configmap in the task. -Use a single _command:_ that executes your script (optionally with -environment variables and with parameters): - - -``` - volumes: - - name: scripts - configMap: - name: my-task-scripts - defaultMode: 0755 - steps: - - name: foo - image: myimage - volumeMounts: - - name: scripts - mountPath: /mnt/scripts - volume - command: - - /mnt/scripts/my-command.sh -``` - -This allows you to create and update your configmap from a real -script. An external script-file allows you to edit it stand-alone as -a proper script file, rather than in-lined into a tekton task yaml -file. This gives you better completion, syntax checking, and many -other benefits. You can even run the script locally. - - -``` -#!/bin/bash -# my-command.sh -echo "${PARAM_ONE-Hello world}" -``` - -To create the configmap: - -``` -kubectl create configmap my-task-scripts --from-file=my-command.sh -``` - -For bonus points, use a kustomize generator to create your task; this -allows you simple "kubectl apply -k". +As with all configuration and code that you write as part of software +development, it is important to treat the Tasks and embedded scripts +with the same care you use for your other code. + +Scripts should be maintained such that they can be versioned and tested; +therefore as a script grows beyond a few simple lines, you should store +the script in version control, and use tests and code review to maintain +it over time. At this point you may want to consider switching from a +language which does not naturally support tasking, such as bash, to one +that does, such as Python. + +At this point, the best option we have to offer is to build and publish +an image which contains your tested, versioned script, and use that image +from within your Task. This may seem like a big ask, but another way of +looking at it is that your script has graduated from just being a script +to being a tool. ## Test and verify your task code