External Auth Provider in Ingress / Injected Sidecars

[evie404]

Feature Request

What problem are you trying to solve?

In order to standardize authentication patterns across the mesh, one can run external auth at the ingress level; however, in order to address other malicious access patterns, we are also interested in authenticating every request within the mesh between services.

This includes requests that may have already been authenticated on the edge, but potentially also including requests that originated within the mesh.

How should the problem be solved?

There already exists some support for configuring this at the ingress level; however, in order to extend this also for requests within the mesh, this should be configurable by the proxy itself when running as an injected sidecar.

Ideally, the proxy should be able to configure some target for external auth provider, and also provide some standard RPC spec (preferably gRPC) to codify the interface of the external auth provider.

Any alternatives you've considered?

Technically, this could be achieved by routing every request through the ingress, but that creates additional issue including unnecessary network and cost overhead.

Other alternatives include running other proxies where this might be supported.

How would users interact with this feature?

I'm not sure what would be the best place to inject this configuration. Perhaps as additional annotation like in the Automatic Injection example, or perhaps as a Kubernetes custom resource?

[evie404]

Some context (related discussions in slack):

https://linkerd.slack.com/archives/C89RTCWJF/p1559763924065300 https://linkerd.slack.com/archives/C89RTCWJF/p1559764012066000

[msvechla]

Are there any updates on this?

I am looking to integrate for example https://www.openpolicyagent.org/ with the linkerd2 sidecar proxy, so incoming requests get sent to OPA for authorization decisions.

Are there currently any mechanisms in place that could be utilized to add such extensions? I would appreciate any hints, thanks a lot!

[grampelberg]

@msvechla what are you trying to do with OPA?

[msvechla]

Basically the same as here: https://github.com/open-policy-agent/opa-envoy-plugin This plugin uses the envoy external authorization filter: https://www.envoyproxy.io/docs/envoy/latest/intro/arch_overview/security/ext_authz_filter.html

This filter checks if an incoming request is authorized or not by calling some external service. I am looking for an equivalent or alternative for linkerd.

Every incoming request to a target pod should be intercepted by the proxy as usual and then sent to OPA for validation. Depending on the answer from OPA, the request should be forwarded to the target pod or rejected with HTTP 403 or something similar.

[s4got10dev]

@grampelberg can you provide some update on this one? is it somewhere on roadmap?

[bklaubos]

Assumption is that OPA will cache the authorization with some TTL to avoid rate-limiting issue with external authz providers. A OPA wrapper could probably provide this

[saltbo]

Any progress for this?

[shadiramadan]

I'd like to know the same thing- I want to validate some JWTs- its so easy with Istio- was hoping I'd find an easy path with linkerd.