-
Notifications
You must be signed in to change notification settings - Fork 681
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
design: Adds external-auth support #1014
Conversation
This document outlines a specification to allow Contour to make use of the [external authentication] http_filter of Envoy to implement authentication. Signed-off-by: Christian Simon <simon@swine.de>
Thanks for taking the time to write this up @simonswine! I am very curious as to what others think, but in my mind, Contour does not seem like the right place to implement the authentication/authorization server. Contour is an ingress controller, and adding the auth concerns seems to muddy its responsibilities and security posture. With that said, from a user's perspective, it might be painful to have to implement an external authN/Z server if I wanted to use this. I wonder if the Open Policy Agent would make sense here? It looks like there is an (improperly named) OPA adapter/plugin that implements the Envoy Ext Auth API: https://github.com/open-policy-agent/opa-istio-plugin Something else that is a bit unclear to me is: what are we trying to solve? The proposal talks about Basic Auth and OAuth, but #432 seems to be about exposing the right knobs so that users can bring their own AuthN/Z server. I think it might be beneficial to discuss auth use cases to try to come up with a solution. |
Glad to see someone pushing this forward!
I’m with @alexbrand here, implementing the authentication logic in Contour
seems like to much IMHO.
I would vote for a one, and only, way to represent an external auth that
directly implements the CheckRequest API:
The good parts:
* Less logic
* Less code to maintain
* Separation of concerns
* Very flexible for the end-user. They are in the position to decide what
kind of auth methods are going to be implemented/deployed.
* Less API surface, easier to give support
The bad parts:
* Tied to Envoy, probably not that easy to make Contour vendor agnostic in
case there is an idea to make it compatible with other proxies like nginx
* More components involved so no that easy to deploy for simple use cases.
Thats it, thanks again for working on this!
…On Fri, 12 Apr 2019 at 15:06, Alexander Brand ***@***.***> wrote:
Thanks for taking the time to write this up @simonswine
<https://github.com/simonswine>!
I am very curious as to what others think, but in my mind, Contour does
not seem like the right place to implement the authentication/authorization
server. Contour is an ingress controller, and adding the auth concerns
seems to muddy its responsibilities and security posture.
With that said, from a user's perspective, it might be painful to have to
implement an external authN/Z server if I wanted to use this. I wonder if
the Open Policy Agent would make sense here? It looks like there is an
(improperly named) OPA adapter/plugin that implements the Envoy Ext Auth
API: https://github.com/open-policy-agent/opa-istio-plugin
Something else that is a bit unclear to me is: what are we trying to
solve? The proposal talks about Basic Auth and OAuth, but #432
<#432> seems to be about exposing
the right knobs so that users can bring their own AuthN/Z server. I think
it might be beneficial to discuss auth use cases to try to come up with a
solution.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
<#1014 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/ACIPlodzV2-viaVFpYHjqcRMAqnybHpCks5vgITtgaJpZM4cq7zo>
.
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@simonswine thank you for working on this.
I have to be honest up front that #432 is not on the schedule for 0.12 so my time to review and comment on this proposal will be limited.
Some initial feedback (sorry my time is limited, maybe Alex or Steve can drive this):
The way envoys authz filter works is worrying, there is a large potential for screwing up when it needs to be turned on globally then turned off everywhere but where it is needed. For https routes I think we can avoid this by applying the filter at the listener level. for http routes maybe we can make the http listener look more like the https one.
Please take basic auth out of the picture. It's not in scope and complicated by http listeners which we cannot allow it on.
If we push basic auth out of scope the Authentication CRD is a lot of work to carry two parameters, can those parameters be merged into the IngressRoute CRD?
Thanks
Dave
I kind of like having the separation with the I'm wondering though if we should apply auth at a Root IngressRoute level, where all routes within a single |
Why not directly allow configuring the Once you make this configurable through the
Also, it seems like managed providers as well as other open source projects are embracing this 'Universal' API, for example: Google with its Traffic Director which implements WDYT? |
Yup that's what I was suggesting @glerchundi, I see a way to configure the external gRPC service. I did something similar with my work on RateLimiting if you look at that PR. I showed how to use the Lyft implementation, but users could still integrate their own if they wanted. |
Whoop!
Fantastic, i misunderstood what you were suggesting. We’re on the same path
then.
Thanks!
…On Fri, 24 May 2019 at 22:16, Steve Sloka ***@***.***> wrote:
Yup that's what I was suggesting @glerchundi
<https://github.com/glerchundi>, I see a way to configure the external
gRPC service. I did something similar with my work on RateLimiting if you
look at that PR. I showed how to use the Lyft implementation, but users
could still integrate their own if they wanted.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#1014>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AARA7FWOEDURAIL5SJHO5ETPXBEJZANCNFSM4HFLXTUA>
.
|
@simonswine do you plan to make changes to this PR in the short term? I'm interested in making some progress and I've some time in the next two months. So in case you feel I can take this one let me know. |
Marking this PR stale since there has been no activity for 14 days. It will be closed if there is no activity for another 90 days. |
this PR is now stale. removing from the board so that when we prioritize #432, we will consider all options (including this design) |
This document outlines a specification to allow Contour to make use of the external authentication http_filter of Envoy to implement authentication.
This is an early version of a design draft. I have created an ugly PoC for it and this represents my learnings and my suggested approach. Happy for any feedback!
The feature is described in #432