TrafficTarget should be created in same namespace as destination

[michelleN]

trafficstars

Describe the proposal Currently, there is no limitation for which namespace a TrafficTarget can be created in. This means that if a cluster is being used by multiple teams/groups/orgs in a multi-tentant scenario, any party can create a TrafficTarget defining access control rules for any destination across the cluster.

Should we require that a Traffic Target be created in the same namespace as a the workload identity being referenced in the destination field of the spec? This will ensure that the author of the destination service can control who and what can access it and if a user does not have the ability to create a TrafficTarget in the destination namespace, then they won't be able to control who accesses the destination service.

Scope

• [ ] New specification
• [X ] Traffic Access Control
• [ ] Traffic Specs
• [ ] Traffic Metrics
• [ ] Traffic Split

Possible use cases team A deploys a client application in the namespace client. team B deploys a server application in the namespace server. team A does not have create permission in the server namespace and team B does not have create permission in the client namespace team B wants to control who accesses the server application and can do so by creating a TrafficTarget in the server namespace. If team A creates a traffic target for the server application (as destination) in the client namespace, it is invalid and has no bearing on the access control rules for the server application