mirror/catalog
1
0
Fork 0
mirror of https://github.com/tektoncd/catalog.git synced 2024-11-21 05:55:35 +00:00
Code Issues Releases Activity

Recommend versioning script instead of using configmap 📝

Browse Source 
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).
This commit is contained in:
Christie Wilson 2021-07-22 13:50:50 -07:00 committed by tekton-robot
parent b21ad0b3fc
commit 68e44c629c
1 changed files with 14 additions and 41 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

55
recommendations.md
View File

@ -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 in the script, there is no real need for the script to be in-lined
into the Task. into the Task.
Use a ConfigMap for your script, and mount the configmap in the task. As with all configuration and code that you write as part of software
Use a single _command:_ that executes your script (optionally with development, it is important to treat the Tasks and embedded scripts
environment variables and with parameters): 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
volumes: an image which contains your tested, versioned script, and use that image
- name: scripts from within your Task. This may seem like a big ask, but another way of
configMap: looking at it is that your script has graduated from just being a script
name: my-task-scripts to being a tool.
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".
## Test and verify your task code ## Test and verify your task code