Should objectReferences be used in TrafficTargets to prevent exceeding RBAC

[dtomcej]

Describe the proposal

When defining TrafficTarget sources and destinations, the elements name and namespace are not validated to ensure that the user has access to those resources.

This can lead to situations where a user may be able to allow traffic to or from sources that they shouldn't.

Using objectReferences could prevent this by leveraging the RBAC and built-in kubernetes validation to ensure that the referenced objects are visible to the user, and that the objects exist.

Scope

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

Possible use cases

A user in namespace default with RBAC restrictions restricting users to that namespace should not be able to create a TrafficTarget allowing traffic out of that namespace and into another.

[grampelberg]

@dtomcej when you're talking about objectReferences, is it something specific to the go client or RBAC specifically in k8s? Any pointers to docs I could read would be greatly appreciated =)

[dtomcej]

Hey @grampelberg, objectReferences are a core type in kubernetes:

https://godoc.org/k8s.io/api/core/v1#ObjectReference

An example of its usage, is in the EndpointAddress type, which has an objectReference to the Pod that has the endpoint address:

https://github.com/kubernetes/api/blob/master/core/v1/types.go#L4219

[grampelberg]

@dtomcej yeah, I've used objectReferences before, but I've never needed read access on the referenced object to apply it.

[shashankram]

A user in namespace default with RBAC restrictions restricting users to that namespace should not be able to create a TrafficTarget allowing traffic out of that namespace and into another.

If a user has rights to multiple namespaces, they should be allowed to have sources and destinations in different namespaces. There is definitely a use case for the source and destination to be in different namespaces.