search

parodos-dev / orchestrator-helm-chart

Helm chart to deploy the Orchestrator solution suite.
https://parodos.dev/orchestrator-helm-chart/
Apache License 2.0
2 stars 22 forks source link

Allow traffic from knative-eventing and knative-serving #267

Closed rgolangh closed 2 months ago

rgolangh commented 2 months ago

Workflows like move2kube deploy and use knative functions to achieve the workflow tasks and working with functions means we need to allow the traffic from knative-eventing and knative-serving namespace.

Traffic from knative-serving is needed when the function is deployed in the same workflow namespace, because the way the function is triggered is by the knative-serving components that send the event to the function. So the traffic is knative-serving -> $workflows-ns (where the knative function is deployed)

Traffic from knative-eventing is needed when functions or in the future other events go through the knative broker and the trigger is sending them to workflows. In the case of move2kube it is the m2k-save-transformation function that sends an event, and that event direction is knative-eventing -> $workflows-ns

https://issues.redhat.com/browse/FLPATH-1580

Signed-off-by: Roy Golan rgolan@redhat.com

gabriel-farache commented 2 months ago

So it means that events sent through knative are "unprotected", i.e: if someone send a event with the right parameters it will reach the workflow This may be an issue if there is an workflow waiting for event to be triggered or if/when we go full knative ready with the triggering of workflow execution via event and not REST request

If so, we need to document that and maybe check with security too, WDYT?

rgolangh commented 2 months ago

closing this and resending to the operator repo