Destination endpoints for a service that maps to multiple ServiceAccounts doesn't honor TrafficTarget policy

[shashankram]

Bug description:
Consider the following example:

• Service-X is backed by <Pod-1, SvcAccount-1> and <Pod-2, SvcAccount-2>.
• Client-A (Service-A, SvcAccount-A) wants to access Service-X
• User configures single TrafficTarget policy to allow src=SvcAccount-A, dst=SvcAccount-1

*Note: there is no traffic split configured

OSM will translate the TrafficTarget policy to src=Service-A, dst=Service-X.

When EDS resolves the endpoints for the destination Service-X, it will receive the endpoints for both Pod-1 and Pod-2. However since Pod-2, SvcAccount-2 is not allowed to be accessed by Service-A, SvcAccount-A, traffic from Service-A, SvcAccount-A to Pod-2, Svc-Account-2 should be denied. Currently, the destination endpoints for a service do not take into consideration the traffic target policies.

Affected area (please mark with X where applicable):

• Install [ ]
• SMI Traffic Access Policy [X]
• SMI Traffic Specs Policy [ ]
• SMI Traffic Split Policy [ ]
• Permissive Traffic Policy [ ]
• Ingress [ ]
• Egress [ ]
• Envoy Control Plane [ ]
• CLI Tool [ ]
• Metrics [ ]
• Certificate Management [ ]
• Sidecar Injection [ ]
• Logging [ ]
• Debugging [ ]
• Tests [ ]
• CI System [ ]

Expected behavior:
Based on the above example:

• Service-A should be able to access <Pod-1, SvcAccount-1>
• Service-A should not be able to access <Pod-2, SvcAccount-2>

Steps to reproduce the bug (as precisely as possible):
Use the above example.

How was OSM installed?: osm install

Anything else we need to know?: n/a

Environment:

• OSM version (use osm version):

Version: dev; Commit: 4370f4c8e9036b77125da795eb565be5b7ec8b21; Date: 2020-09-01-16:55

• Kubernetes version (use kubectl version):

Client Version: version.Info{Major:"1", Minor:"17", GitVersion:"v1.17.2", GitCommit:"59603c6e503c87169aea6106f57b9f242f64df89", GitTreeState:"clean", BuildDate:"2020-01-18T23:30:10Z", GoVersion:"go1.13.5", Compiler:"gc", Platform:"linux/amd64"}
Server Version: version.Info{Major:"1", Minor:"15", GitVersion:"v1.15.10", GitCommit:"ba1ce4122d67b0f7399a41afbbd8a7258d22ecb8", GitTreeState:"clean", BuildDate:"2020-04-21T00:13:25Z", GoVersion:"go1.12.12", Compiler:"gc", Platform:"linux/amd64"}

• Size of cluster (number of worker nodes in the cluster): 1 node

[nojnhuh]

@shashankram Do you think P1 or P2 fits better here? It looks like it's possible to workaround the issue, but I can see where this definitely needs to get fixed soon anyway.

[shashankram]

@shashankram Do you think P1 or P2 fits better here? It looks like it's possible to workaround the issue, but I can see where this definitely needs to get fixed soon anyway.

The only workaround is to not have such a scenario :-)
We haven't completely gotten rid of assumptions around 1-1 mapping between a Service and ServiceAccount, so I'd put a P1.5.

[snehachhabria]

@michelleN as FYI the new proposal for traffic split and client/server config that @ksubrmnn is working on will handle this case as well.

Once the changes are made we will need to validate this scenario