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).
Following TEP 70, tekton.dev/platforms annotation can be used to
specify on which platforms the resource can be run.
- add best practices for platform information in the recommendations.md
- add example of usage for tekton.dev/platforms annotation
Signed-off-by: Yulia Gaponenko <yulia.gaponenko1@de.ibm.com>
Writing my first contribution to the catalog, I failed to find the
authoring recommendations, resulting in unnecessary Slack noise.
This adds references to parts of the documentation that I did
read in the hope that others will see them in time.
I removed the recommendations list that was inlined in CONTRIBUTING.md
as it is covered by the linked recommendations.md.
… also talk a little bit about `privileged` and how to be explicit in
the task if it needs to be run as root and/or privileged.
Signed-off-by: Vincent Demeester <vdemeest@redhat.com>
