Summary

(Follow-up to #5061 after thinking about it some more.)

I think param interpolation in command, args, and source is an anti-pattern. In 99.9% of use cases, inputs are input, they're not code. Allowing interpolation in these fields creates a major code injection attack surface. Developers will copy/paste hello-world examples and then build on them, forgetting to add safeguards against malicious param values.

When Argo was a young project, I think this feature made a lot of sense. It's super easy to write up a workflow and use input param interpolation to change code behavior. But as Argo gains adoption, I think it will become a major problem. SQL injections became ubiquitous because adoption of the language grew faster than the safeguards. The param interpolation feature introduces a similar attack surface to the Kubernetes ecosystem.

Of course, removing such a widely-used feature would be very disruptive. So I recommend adding a workflow controller option to disable param interpolation in the command, args, and source fields, which are the fields most often interpreted directly as code.

If the dev team doesn't love this idea, here are a few alternatives:

• replace command, args, and source param interpolation examples w/ the equivalent env vars implementation
• add warnings in docs around input params, encouraging proper validation/sanitization

Use Cases

Large organizations could enable this feature to enforce best practices (e.g. using env vars for params instead of interpolation) across a large group of developers and workflows which would be difficult to manually review/govern.

Message from the maintainers:

Impacted by this bug? Give it a 👍. We prioritise the issues with the most 👍.