eventing
eventing copied to clipboard
knative
block the use of external URLs from eventing Destinations
Problem
We're running Knative in a managed environment where the eventing infrastructure is something that will be hidden from the user and is really there to drive traffic to the hosted KnServices. In this environment, if we allow the user to specify external URLs for the destinations of the Eventing components (e.g. Sink in an adapter) then we'd get into a situation where people can setup the KnEventing infrastructure to route traffic to something outside of the cluster. So, if the infrastructure is meant to be cost free the user would then have a loop-hole to free cloud eventing infrastructure.
We'd like an operator option to generate an error if any Destination resulted in a URI that is not local to the cluster. Default would be to not enforce such restrictions.
Persona: Operators
Exit Criteria Enable the flag and specify some internet facing URI as a Destination - should result in an error while trying to create the eventing resource with that Destination.
@duglin A cluster operator could implement this (and other optional validations) as an additional ValidatingWebhookConfiguration and webhook pod. Would that be sufficient?
@grantr as a last resort yes we may have to do something like that, but I’d prefer if there was a more standard option available so that any one who needed this restriction didn’t have to reinvent the wheel.
Seems like you could just write a super simple function that just takes the incoming event and calls the external URL? seems like it's semi complex feature that's extremely straightforward to bypass, what am I missing?
Blocking that will do nothing because I can make an addressable crd that hosts an external url and trigger just sees an object ref to a thing that has an address.
Maybe a better solution would be to force your cluster to use an istio mesh?
I see, because they'd still be paying for the function invocation?
Yup. The issue isn't about blocking all outbound connections, it's blocking outbound connections from the eventing infrastructure.
... I can make an addressable CRD...
If I'm following... nope, you can't. In our managed environment people can't create random CRDs.
@duglin is this still a priority for you? Do you have anybody that has spare cycles to pick this up?
we do still want it - but other work items are taking priority right now. If someone else wants to jump in.... :-)
This issue is stale because it has been open for 90 days with no
activity. It will automatically close after 30 more days of
inactivity. Reopen the issue with /reopen. Mark the issue as
fresh by adding the comment /remove-lifecycle stale.
![github-actions[bot] avatar](https://avatars.githubusercontent.com/in/15368?v=4 "Published by a pub.dev verified publisher"){kind=small}
This issue is stale because it has been open for 90 days with no
activity. It will automatically close after 30 more days of
inactivity. Reopen the issue with /reopen. Mark the issue as
fresh by adding the comment /remove-lifecycle stale.
This issue is stale because it has been open for 90 days with no
activity. It will automatically close after 30 more days of
inactivity. Reopen the issue with /reopen. Mark the issue as
fresh by adding the comment /remove-lifecycle stale.
@lionelvillard how do you see that being enabled? Flag and then a webhook rejecting its usage if enabled? If so, seems reasonable. We'd need to check to make sure it only rejects absolute URIs, right?
This issue is stale because it has been open for 90 days with no
activity. It will automatically close after 30 more days of
inactivity. Reopen the issue with /reopen. Mark the issue as
fresh by adding the comment /remove-lifecycle stale.
