Granting different permissions to different clients targeting the same API using OSM

Different clients, including other APIs, often consume an API. You typically handle the authorization aspects with JWT tokens containing the required audience, scopes, and/or roles, or even any other custom claim.

When using a service mesh, you can add an extra layer of security to your APIs by defining explicit permissions enforced by the mesh, independently of the code. This can be used to enforce some standards outside of the code. With OSM, the way to do this is by:

• Setting enablePermissiveTrafficPolicyMode to false because every meshed service can talk to any other one when enablePermissiveTrafficPolicyMode is set to true.

• Defining explicit TrafficTarget and HTTPRouteGroup CRDs

So far, so good, and this works well as long as you stick to generic routes. However, as of May 2023, it is impossible to accommodate the following simple scenario using OSM:

{height="" width=""}
Figure 1 – Granting different permissions targeting the same API

In the above diagram, the so-called backend API is consumed by two different clients: client 1 and client 2. I want client 1 only to be able to call a given controller with the GET verb, while client 2 can use any verb. Providing REST conventions is respected by the backend API. This means that client 1 cannot “write” any data.

This straightforward scenario is not possible at this stage with OSM. The following setup should have done the job:

{height="" width=""}
Figure 2 – OSM setup to grant different permissions to different clients against the same API

TrafficTarget links a source (client) and a destination (API). It also references the HTTPRouteGroup through a matching rule. Unfortunately, OSM seems buggy as it only considers the broadest route…

I have filled a GitHub issue https://github.com/openservicemesh/osm/issues/5297 to report this problem, as well as with the repro steps. Stay tuned should you have the same fine-grained requirements.