Provide support for integrating with an external auth service.

[larkinkevin]

• Ambassador supports authentication via the "AuthService" manifest (and a user-provided external auth service that satisfies a very simple API).
• It appears that Envoy likes this approach, because they're planning to incorporate it: Fold Ambassador auth functionality into ext_authz envoyproxy/envoy#2828.
• If/when Envoy provides this functionality, it would be great if Contour could expose it to users.

[ihrwein]

I wanted to raise a similar issue then managed to convince myself that although this feature would be useful it's not aligned with this project's goals (note that I'm just somebody from the Internet who found this project some days ago.).

My reasoning is that different teams can have different authentication requirements. Contour is to have one Ingress that delegates the traffic to team-managed services. Those services can be simple services or API gateways that hides other services and those API gateways would be a better place for authentication. Just my two cents.

[larkinkevin]

I can certainly see where you're coming from @ihrwein. I just opened this issue to track the feature request (I figured I should at least make the ask).

Will totally understand if the Contour folks decide this is not a feature they want to support (because it's not handled by the Ingress spec).

[rosskukulinski]

Hi @ihrwein and @larkinkevin - thanks for opening this issue. I think this is an interesting feature request and something that could be a useful addition to the new IngressRoute CRD we're heads down on at the moment.

We haven't taken a close look at the APIs exposed via envoyproxy/envoy#2828, but once it lands in an Envoy release, we'll take another peak.

[mattmoyer]

+1 for this feature. I'd love to have some Contour backends protected by the ext_authz filter in the style of an API gateway.

Envoy docs for the feature, since it doesn't look like those have been linked here yet:
https://www.envoyproxy.io/docs/envoy/latest/configuration/http_filters/ext_authz_filter.html

[pims]

I’d be happy to contribute a PoC for ext_authz filter configuration if the contour team still believes it's a valuable feature to add.

Are you dead set on having this only available through the new IngressRoute custom CRD or should I also consider how to integrate it with the native ingress definition?

[rosskukulinski]

I think this may also be related to adding similar functionality as to #68

[davecheney]

Removing the 0.11 milestone as external auth support is not available in a shipping envoy 1.9

[pims]

@davecheney Envoy 1.9.0 released on Dec 20, 2018 has support for ext_authz.

https://github.com/envoyproxy/envoy/blob/v1.9.0/docs/root/configuration/http_filters/ext_authz_filter.rst

Am I missing something?

[davecheney]

I’m sorry, that was my mistake. I confused this with another feature.

…

On 12 Mar 2019, at 10:18, Tim Bart ***@***.***> wrote: @davecheney Envoy 1.9.0 released on Dec 20, 2018 has support for ext_authz. https://github.com/envoyproxy/envoy/blob/v1.9.0/docs/root/configuration/http_filters/ext_authz_filter.rst Am I missing something? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.

[aslafy-z]

Any chance this goes back to 0.11.0 milestone @davecheney?

[davecheney]

I've readded the 0.11 milestone, but no promises, as usual, we're resource constrained and once we decide on a release date for 0.11, there may not be time to implement it.

[shabx]

Adding what customer shared in the ticket they have open for this issue.
They currently have teams using the NGINX External Authentication annotation that allows authentication against a pod running in GKP.
The documentation is at
https://github.com/kubernetes/ingress-nginx/blob/master/docs/user-guide/nginx-configuration/annotations.md#external-authentication

[davecheney]

Due to the need to ship Contour 0.11 to address a security issue in Envoy 1.9.0 this issus has been bumped to 0.12.

@shabx this issue has been reassigned to 0.12, however I feel that its likely that when we rationalise the backlog for 0.12 (there is far too much in there for our team) this feature will be removed from the milestone until there is a design document for it.

[jpeach]

Blocked by:

• Auth: Add ExtensionService CRD Auth: Add ExtensionService CRD #2710
• Auth: Enable ExtensionService CRD Auth: Enable ExtensionService CRD #2711
• Auth: Add an Informer to watch ExtensionServices Auth: Add an Informer to watch ExtensionServices #2712
• Auth: Create Envoy clusters from ExtensionServices Auth: Create Envoy clusters from ExtensionServices #2713
• Auth: Watch ExtensionServices availability and update Status conditions Auth: Watch ExtensionServices availability and update Status conditions #2714
• Auth: Add HTTPProxy authorization fields Auth: Add HTTPProxy authorization fields #2715
• Auth: Add external authorization documentation Auth: Add external authorization documentation #2716
• Auth: Add external auth integration tests Auth: Add external auth integration tests #2717
• Auth: Set ExtensionService status Conditions Auth: Set ExtensionService status Conditions #2874
• Auth: Support external services in ExtensionService Auth: Support externalname services in ExtensionService #2875
• Auth: Add metrics for ExtensionServices Auth: Add metrics for ExtensionServices #2889

[manast]

In terms of JWT authentication, Envoy directly supports verifying JWT tokens, without going to an external service. This is nice for performance, avoiding the overhead, on every HTTP request, of making another HTTP request to verify the auth. The nginx plus ingress controller also supports this method (direct JWT verification). Personally I'd like to see that as an option here, and not have to rely on a generic external auth endpoint through which all requests are routed.

That seems like a different feature, or if you like a refinement that can be implemented later. As for now, the external authorization even if not optimal in all cases would help in solving many use cases that are kind of impossible to achieve today.

[manast]

@jpeach Should I open a separate issue for implementing external_auth on TCP or would this one include it already? And close this one in such case #2855

https://www.envoyproxy.io/docs/envoy/latest/configuration/listeners/network_filters/ext_authz_filter#config-network-filters-ext-authz

[jpeach]

@jpeach Should I open a separate issue for implementing external_auth on TCP or would this one include it already?

@manast Yeh, could you please file a separate issue? This is scoped only to HTTP.

[manast]

@jpeach ok, done: #2888

[sunjayBhatia]

Closing this issue as we have linked more granular issues open