Service lets you point traffic at revisions it does not own

[dprotaso]

What version of Knative?

Repro'd with 0.25.1

Expected Behavior

Update the traffic rules of a Service to point to another revision should fail

Actual Behavior

The traffic rule is realized and hitting Service A will route traffic to a revision owned by a different Service

Steps to Reproduce the Problem

$ kn service create aaa --image gcr.io/knative-samples/helloworld-go --env TARGET=A
...
$ kn service create bbb --image gcr.io/knative-samples/helloworld-go --env TARGET=B
...
$ curl aaa.default
Hello A!
$ curl bbb.default
Hello B!
$  kn service update aaa --traffic bbb-00001=100
$ curl aaa.default
Hello B!

[skonto]

@dprotaso I guess we can retrieve the traffic targets and see if they are owned by the service at the webhook validation side. Otherwise to keep validation light we can fail when we try to configure traffic for the route during route reconciliation. WDYTH?

[markusthoemmes]

I don't think we can reliably do that without any false positives. A more lightweight approach might be to allow setting ConfigurationName and RevisionName at the same time (I think it's disallowed right now) and then always force ConfigurationName = ServiceName in the Service API, so cross-references would be impossible.

[skonto]

We still have an issue of how to link a revision to a configuration name in here in any case: https://github.com/knative/serving/blob/main/pkg/reconciler/route/route.go#L271. Ownerref may help here but may not be ideal (as we discussed offline).

[dprotaso]

I think doing it as part of reconciliation would be the cheapest as the objects would be in the informer cache

[github-actions[bot]]

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.

[dprotaso]

/lifecycle frozen /triage accepted

[linkvt]

/assign