Set up an external authorization service

[AntonioND]

Hello,

I've been looking into how to add policies that control traffic in a way that is flexible enough that I don't need to use kubectl to add or remove policies. Open Service Mesh and Istio support what I want through the use of envoy's External Authorization filter.

The way it works is that you create a container that listens to envoy's requests (like [1] and [2]) and you tell the service mesh to configure all envoy proxy containers to use that authorization server (with [3] or [4]). Whenever a container tries to connect to a service using envoy envoy sends a request to the external authorization server. The server then responds and allows or not that connection.

Just to clarify, even though the OSM website mentions OPA, I don't want to use OPA as a policy engine. At the moment I have a program based on Istio's demo [1] that checks if source and destination are a valid combination.

I see that linkerd supports proxying connections (https://linkerd.io/2.12/features/http-grpc/) so I was wondering if it could be used to manually setup a filter to have an external authorization service, or if there is already an automatic way to do it with linkerd that I haven't found.

This is the only part of the documentation that mentions configuration options for the proxy, and there is nothing like what I'm looking for, so I guess this isn't supported? https://linkerd.io/2.12/reference/proxy-configuration/

Thanks!

EDIT: It looks like linkerd2-proxy doesn't support configuration by design, if I understand this article correctly https://linkerd.io/2020/12/03/why-linkerd-doesnt-use-envoy/

But Linkerd2-proxy is different. It’s designed to be an implementation detail that doesn’t require specialized knowledge or dedicated operational investment (though Linkerd as a whole, of course, does require it). There’s no user-facing YAML; instead, Linkerd2-proxy is configured automatically through a handful of environment variables set at injection time and by the Linkerd control plane at runtime. We’ve kept Linkerd2-proxy’s tuning surface area to a bare minimum so that end users rarely have to touch it directly. In short: Linkerd2-proxy is designed to stay behind the scenes, to be an implementation detail, and to just work.

[wmorgan]

For reasons of simplicity and ease of debugging, Linkerd does not support using external services to authorize requests in-line with traffic handling. Authorization is only configurable via on-cluster K8s resources. Do you have a use case that this approach doesn't address, or are you just exploring the options right now?

[AntonioND]

We need to write access policies in a way that doesn't force us to deploy new resources with kubectl. The policies will be stored in some container in the cluster, and they may change at any moment because of input of services located outside of the cluster. That's why we need a server rather than static resources.

[wmorgan]

Well, the CRDs are read dynamically by Linkerd and can be updated dynamically as well (e.g. via the K8s api, not just via kubectl CLI commands). So IMO this is not really a question about static vs dynamic, or kubectl vs not kubectl, it's a question of (a) do I want the K8s cluster to be the API for expressing authz rules, or (b) do I want the mesh to call my authz server inline. Our philosophy is that (a) is better since you eliminate a class of operational issues when the authz server goes down, or has latency, but there may be situations where (b) is preferable.

[AntonioND]

Over the last few days I have been exploring the option of having a container that uses the K8s API to change the policies in the cluster, and I don't think it's going to work for us. We need to implement rules such as "if (a > 1000 and b < 200) allow()". We can do this for services that use a REST API if we use (b), but not with (a) because it only enforces access to specific paths.

[wmorgan]

Linkerd's authz rules are based on the Gateway API's HTTPRoute resource, which is fairly flexible, at least when it comes to headers. Can you express your rules using its logic?

(There are certainly situations where this wouldn't be sufficient, or where it would be onerous... you maybe in one of those situations.)

[AntonioND]

For now, it is true that all of the things I'm prototyping in my simple demo can be done with that logic, but there are plans for more complex rules (I don't have a lot of clarity about how they will look like, though).