Pomerium: proxy: add forward-auth endpoint (third party proxy support)

[victornoel]

Is your feature request related to a problem? Please describe.

When using pomerium in a kubernetes cluster, it does (at least) two different things:

• it authorizes request and authenticate users
• it proxies request

Often a kubernetes has already an existing proxy such a nginx-ingress or ambassador or others.

So the requests are proxied twice, and the proxy implementation is done twice, hence increasing the attack surface as well as the potentiality of bugs/problems.

Describe the solution you'd like

It would be cool if it was possible to use the authorize/authenticate part of pomerium coupled with another proxy that would be responsible of proxying.

See for example:

• Ambassador has an API for this: https://www.getambassador.io/reference/services/auth-service
• nginx-ingress too even though I'm not exactly sure it is adequate: https://kubernetes.github.io/ingress-nginx/examples/auth/oauth-external-auth/

Describe alternatives you've considered

I didn't. Notice also that I just thought of this while reading about ambassador and wanted to bring the subject to awareness to the pomerium project in case it converges with its goals.

[desimone]

@victornoel

I see where you are coming from. Since we are already reverse-proxying requests with some production load balancer like nginx, can we just do the authorization and authentication bits in pomerium?

Though I like the idea of separation of concerns and eliminating a hop, I don't think this would be possible given the types of access control decisions pomerium needs to make. As you've noted, many load balancers have some form of authentication front-end. But typically, these authentication frontends don't make any authorization decisions, instead they simply pass on the authentication details to backend services leaving the onus on the backend applications to make authorization decisions. This will get even trickier when support for device state and context come into the picture.

Since pomerium aims to allow for (increasingly sophisticated) access control decisions to be made universally in front of the application logic, I think that for the foreseeable future, the best way forward will be gate authorization with our own reverse proxy.

[victornoel]

@desimone indeed, I see what you mean, thanks for the explanation :)

I will close this and if someone has something to add to the discussion, it can still happen.

[victornoel]

Just for the record as I have been reading a bit about that, it seems that most proxy have in place mechanisms for external authentication. On top of the others cited above, we have:

• envoy with https://www.envoyproxy.io/docs/envoy/v1.10.0/configuration/http_filters/ext_authz_filter
• traefik with https://docs.traefik.io/configuration/entrypoints/#forward-authentication

Basically, the way it usually works is that the request is passed (usually only some headers) to the auth service, which decide if the access is 1) accepted 2) refused or 3) need auth. Usually it will use the return code (if using http) to specify one of the 3, for example a 301 means the auth service will take care of the rest of the workflow until it redirects to the original url.

I think this should be kept in mind for the future of pomerium, because more and more people will be expecting to use modern proxy such as envoy (which are able to handle correctly websockets, grpc and other non-L7 stuffs if I understand correctly).

I'm currently experimenting with contour (an envoy-based ingress for kubernetes) as a replacement of nginx, hence my current interest with the question :) There are some interesting discussions happening on the matter in https://github.com/heptio/contour/issues/432, https://github.com/heptio/contour/issues/986 and https://github.com/heptio/contour/pull/1014.

[tdorsey]

I'd like for this issue to be reconsidered. Turning pomerium into a full fledged ingress controller seems like a crowded field -- nginx, traefik, ambassador, and contour all already exist.

desimone: As you've noted, many load balancers have some form of authentication front-end. But typically, these authentication frontends don't make any authorization decisions, instead they simply pass on the authentication details to backend services leaving the onus on the backend applications to make authorization decisions.

This exactly describes what I want pomerium to do: integrate with the forward-auth capabilities of a pre-existing ingress controller. To use pomerium today, it means dropping traefik (and their nifty ingress dashboard).

Traefik has:

• conditional load balancing
• the aforementioned stats dashboard
• automatic certificate generation
• excellent request tracing capabilities
• no authorization system worth the name

Pomerium as this hypothetical authorization provider let's me keep my authorization system separated from my routing, and this is exactly what forward-auth is intended for.
These are the only ingress annotations needed to enable forward-auth (speaking for traefik and nginx, anyway)

    ingress.kubernetes.io/auth-type: forward
    ingress.kubernetes.io/auth-url: "https://<pomerium-oauth-start>
    ingress.kubernetes.io/auth-response-headers: "X-Forwarded-User"
    ingress.kubernetes.io/auth-trust-headers: "true"

The IC forwards the request to the auth-url, pomerium does whatever it likes, and sends back a 200. If the IC receives anything other than 2xx, they're denied.

[desimone]

@tdorsey @victornoel sorry, I missed both of your excellent follow up posts. I agree that this should be re-opened and reconsidered. Some of the recent changes in Pomerium's core should make this much more doable as well.

Please see the following proof of concept PR using Traefik : https://github.com/pomerium/pomerium/pull/324

Please let me know what you think, as it should be very similar to what @tdorsey described in his post. Those with experience using other proxies, does this more or less function the same way? It looks like envoy also supports full on gRPC which would be much preferable from a performance point of view; though all the old guard products seem to still use HTTP.

In addition to those listed above, I'm looking the following proxies:

• Ambassador
• Traefik
• Nginx
• AWS API Gateway

See also:

• https://github.com/pomerium/pomerium/issues/273
• https://github.com/pomerium/pomerium/issues/64
• https://github.com/pomerium/pomerium/issues/291

cc @fiahil @pecigonzalo

[victornoel]

@desimone great news!

My secret dream is to be able to use contour as a proxy and pomerium for authn/authz :)

But well, contour isn't there yet (see https://github.com/projectcontour/contour/issues/432) but it's based on envoy, so I'm rooting for envoy support.

[desimone]

Closed by #323 . Looking forward to everyone's feedback. Cheers.

[tlvenn]

@desimone #323 is currently closed in favor of this issue...

[desimone]

Sorry #324