eventing
eventing copied to clipboard
knative
Allow for blocking of NS->NS eventings via Sink specification
There are going to be some environments where tenants are isolated by namespaces, and in those cases the idea of someone creating an eventing CR to send events to a different NS's sink becomes problematic. While there will be cases where this will be ok, we should consider if there are some config options we can have that would allow people to configure this on a case-by-case basis.
Some options:
- global - either on or off for the entire cluster. Admin's choice
- on a per NS basis. This one is harder since it would probably need flags in both namespaces, and one to control outbound and one for inbound event control. And, even worse, do we need to control which specific NSs can be linked? Can get complex fast.
For now, and for our current need, the global option would be enough.
I think we talked about this a long time ago, and my recollection is that there are so many ways around this by bouncing things from my namespace, or by bouncing it off the cluster, etc. I thought we deemed it infeasible to do? I guess my worry would be that unless we can properly enforce it it might be bad experience (false sense of security). I wonder if this might be something that we could get security wg to chime in? WDYT?
I may need to be clearer on this. We're not looking for eventing to do some kind of network security. Yes there are broader issues w.r.t. NS->NS communications. This issue is JUST about a config flag that will allow an admin to disable the ability for someone to specify a Namespace in the CR's Destination Object Reference. Meaning, it would force people to only specify a Sink in the same NS as the CR itself. A flag would prevent each install of Knative eventing from having to create their own webhook (or something) to disable/catch this action.
Yes people can get around it by specifying a URL instead of object Ref, but blocking that is a separate issue: https://github.com/knative/eventing/issues/2721
Does this need to be built in to Knative, or would something like [OPA gatekeeper] (https://github.com/open-policy-agent/gatekeeper) be sufficient to enforce that the namespace field is empty?
As an added bonus, this could also enforce things about the URL if needed...
If we decide policy controls is the way to go here, I'd say that a min bar would be documenting this in the admin guide on the website.
It's also possible that we'd want to document an equivalent pattern using identity, where the multi-tenant eventing components would need to be able to present a namespace-specific identity...
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.