provide Service-to-Service authorization

[cypherfox]

Feature Request

What problem are you trying to solve?

Eliminating the need for any authentication and authorization in application micro services. As linkerd2 already has fairly strong identity management infrastructure for automatic TLS, it seems a good starting point.

How should the problem be solved?

By having the proxy request authorization (authz) from a service (e.g. an OPA wrapper), caching the for a TTL returned with the authz result.

What do you want to happen? Add any considered drawbacks.

Deny access to the target service if the identity does not comply with a pre-set policy.
For an initial prototype a whitelist of identities per service would be sufficient.

The request to the authz service may cause latency spikes, especially if the service is unavailable.

Any alternatives you've considered?

Building good Authz and Authn code in every micro service. This has never the level of quality that I would aim for.

How would users interact with this feature?

By configuring the authz service. The method and complexity of it would depend on the type of the authz service.

[cypherfox]

I have had a look at the traffic access control part of the SMI spec, as recomended by @grampelberg. The definition is covering my intended use case fine.
(see: https://github.com/deislabs/smi-spec/blob/master/traffic-access-control.md)
While this issue is more focussed on getting authz data to the proxy, being able to define the policy as CRD would be very welcome.

Since we are looking at using other policy engines like OPA, it would be usefull if the SMI CRDs where not only way to set authz policy.

[kubaj]

It would be nice to support external authorization that works similar to envoy's external authorization filter. This is useful when you run OPA as an authorization engine in a sidecar.

Communication flow:

Client          Proxy             Authz container       Service
    |---------> |                                          |
    |  1. Req   |---------------------> |                  |
    |           |    2. Authz request   |                  |
    |           | <---------------------|                  |
    |           |  3. Authz decision    |                  |
    | <---------|                       |                  |
    |  4a. 403  |                       |                  |
    |           |----------------------------------------->|
    |           |         4b. Service request              |
    |           |<-----------------------------------------|
    |           |         5. Service response              |
    | <---------|                       |                  |
    |  6. Resp  |                       |                  |

More details can be found also here

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed in 14 days if no further activity occurs. Thank you for your contributions.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed in 14 days if no further activity occurs. Thank you for your contributions.

[cypherfox]

Update to the spec doc: https://github.com/servicemeshinterface/smi-spec/tree/master/apis/traffic-access/

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed in 14 days if no further activity occurs. Thank you for your contributions.