Support custom authorization filter to allow delegating authorization logic to a third party component

[andrelealmbcp]

Describe the proposal Support custom authorization filter to allow delegating authorization logic to a third party component

Scope

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

Possible use cases Configure the SMI to use an envoy authorization filter to delegate authorization to an OPA (Open Policy Agent) server.

You can find more information regarding the envoy authorization filter + OPA on the following links:

• https://www.openpolicyagent.org/docs/latest/envoy-authorization
• https://www.envoyproxy.io/docs/envoy/latest/api-v2/config/filter/http/ext_authz/v2/ext_authz.proto

[fkautz]

This would be fantastic! I have several use cases where authorization offload to OPA would be of high value.

[leecalcote]

@andrelealmbcp thank you for filing this request. To help clarify, can you expand on how the type of identity used (service account, bearer token, spiffe, and so on) bears weight on this potential enhancement?

[fkautz]

To refine @leecalcote's question, I have a need for SPIFFE identities issues by SPIRE to work here when available. I'm happy to help contribute towards a generic solution.

[andrelealmbcp]

@andrelealmbcp thank you for filing this request. To help clarify, can you expand on how the type of identity used (service account, bearer token, spiffe, and so on) bears weight on this potential enhancement?

In our case, we're using the envoy to forward all http requests to an OPA server that executes a policy that validates the JWT token sent on Authorization header (signature, expiration, issuer, audience and so on) and checks if token has roles or claims associated that must provide access to the request path (http://my-service/api/operation). The relation between roles/claims with request path needs to be pre configured on the OPA Bundle. For a granted access the request will be forward by envoy to the expected service, otherwise HTTP 401 Unauthorized status code will be returned to the client.

[michelleN]

I'd be really interested in seeing what the UX looks like. Could you raise a PR with a proposal @aanandr ? If there is a way to do this without being implementation specific that would be great. Not all implementations are going to support OPA so we'll need to figure out a way to do this in a plugin or extensible fashion. I think it'd be good to get a PR though so we can work from there.

[michelleN]

@fkautz I'm supportive of adding supportive of SPIFFE identities. Would you like to raise a PR? Feel free to ping me if you like. I'm happy to help with that PR as well if you don't have time.

[anderseknert]

If there is a way to do this without being implementation specific that would be great.

The way clients normally query OPA for an authorization decision is by sending a request to OPA's REST (or GRPC) API, carrying most, if not all, of the information from the original request in a JSON body of the request. OPA will then respond with its decision in a JSON formed response. So, essentially just a webhook with no parts of the implementation specific to OPA. Any service that can communicate JSON over a REST API could be on the receiving end. I'll readily admit that I know very little about the design of this project though, so perhaps there are other things to take into account :) Either way, if there's anything I can do to help out with this, do let me know.