feat(charts): allow auto workflows to set own posixuid

[JamesDoingStuff]

AP-1110

I had to remove the pipe expressions from the JMESPath in the policy - they don't seem to work with the || operator. Possibly a kyverno bug, as they seem to behave as one would expect in the JMESPath tutorial/playground.

If identity-mapper changes related to AP-1140 are merged in before this, then that policy will need updating instead in a similar way to how workflow-label-clusterpolicy is here e.g.

context:
     - name: posixUidString
       variable:
         value: "{{`{{ request.userInfo.extra.\"workflows.diamond.ac.uk/posixuid\"[0] || request.object.metadata.labels.\"workflows.diamond.ac.uk/machine-uid\" }}`}}"

[davehadley]

checking I understand the safety reasoning here: it's impossible for a malicious user to set "workflows.diamond.ac.uk/machine-uid" themselves because "workflows.diamond.ac.uk/posixuid" is always set and is out of their control?

[JamesDoingStuff]

Yes that was my thinking - I just tried running a workflow with the label set manually and the pod was still my UID rather than the machine one

[TBThomas56]

Could be worth adding a validating rule that rejects workflows that carry a machine-uid label unless submitted by a trusted Service account? maybe the events metacontroller?

[JamesDoingStuff]

@TBThomas56 I like that idea. The fact that we create the EventSources (which are where the machine-uids are defined) combined with the logic @davehadley pointed out should mean that it's already impossible to create a job with any old account, but it can't hurt to have a fail-safe like that. Would you be happy if I merge this as-is and then add that in once #1366 is done?