-
Notifications
You must be signed in to change notification settings - Fork 273
authz_filter: configuration to support Ambassador authorization flow #563
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
Changes from 8 commits
61e546f
2c8f23c
9810412
e6c5342
fdd6594
49dedbd
3128f16
339db0e
f663e11
0f55cb6
b0c3389
79d770a
f024a1b
a8db286
e16fcdb
5eceb00
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -9,7 +9,7 @@ import "validate/validate.proto"; | |
|
|
||
| // [#not-implemented-hide:] | ||
| // External Authorization filter calls out to an external service over the | ||
| // gRPC Authorization API defined by | ||
| // gRPC or HTTP Authorization API defined by | ||
| // :ref:`external_auth <envoy_api_msg_auth.CheckRequest>`. | ||
| // A failed check will cause this filter to return 403 Forbidden. | ||
| message ExtAuthz { | ||
|
|
@@ -23,4 +23,25 @@ message ExtAuthz { | |
| // is NOT denied then traffic will be permitted. | ||
| // Defaults to false. | ||
| bool failure_mode_allow = 2; | ||
|
|
||
| // When this value is set to true, the filter must call an HTTP authorization service only. | ||
| bool use_http_service = 3; | ||
|
|
||
| // The external authorization HTTP service configuration. Only applicable when `use_http_service` | ||
| // is true. | ||
| message HttpService { | ||
|
|
||
| // Sets the cluster name which the authorization request must be sent to. | ||
| string cluster = 1; | ||
|
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. you can mandate this be set. see https://github.com/gsagula/data-plane-api/blob/339db0e1225d31e13ea3d35e7a8459abfbda3970/envoy/api/v2/core/grpc_service.proto#L25 Do you think there would ever be a need for a TLS configuration and also could the http service be made a core service (like grpc_service). (Not asking for you to change anything but thinking out loud).
Member
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. TLS config is configured at the cluster level, so I think this is covered. |
||
|
|
||
| // Sets the time in milliseconds within the service should respond to an authorization request. | ||
| uint32 timeout_ms = 2; | ||
|
Member
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. This should be a |
||
|
|
||
| // Sets a list of authorization response headers that are allowed to be injected in the | ||
| // downstream client request before dispatching it to the upstream. | ||
| repeated string allowed_headers = 3; | ||
|
Member
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Why is this necessary? Don't we trust the authz server to do the right thing?
Member
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. +1
Member
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I just copied this from the Datawire's filter. It seems to prevent that all authz headers get copied over to the original request. E.g., content-length. @kflynn Would you mind to help us with this one? Thanks! There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. @htuch @mattklein123 Folks we've talked to have been less comfortable with given an auth service carte blanche to change anything it wants going upstream, more comfortable with only allowing it to change known things (cf some of the comments around trust on https://docs.google.com/document/d/1L3aRk9yaT6Lsb4epI6rdjCdStOuwTfhoeSP82zunkGg/edit).
Member
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I'm not sure I really buy this. Why would the filter then trust anything the auth service does? Whether the decision, the response, etc.? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. @mattklein123 I think there were three underlying concerns:
Member
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I agree that it seems a bit arbitrary just policing the headers. If we don't trust the auth service, it can do a lot bad things, e.g. inject content in the reply for the body. I can see that in some applications, you do want to strip headers unconditionally, when something passes between internal <-> external on edge proxies. We could use a separate filter in the stack for this, would that work in your application? It seems if the auth server can't set that header, backends probably shouldn't be trusted to do it either? |
||
|
|
||
| // Sets an optional prefix to the value of request header `path` in the authorization request. | ||
| string path_prefix = 4; | ||
| } | ||
| } | ||
| Original file line number | Diff line number | Diff line change | ||
|---|---|---|---|---|
|
|
@@ -26,4 +26,22 @@ message CheckRequest { | |||
| message CheckResponse { | ||||
| // Status `OK` allows the request. Any other status indicates the request should be denied. | ||||
| google.rpc.Status status = 1; | ||||
|
|
||||
| // An optional message which contains the attributes of an HTTP response object. This message is | ||||
|
Member
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. This PR doesn't make clear how exactly this will work. Does the HTTP service send back a proto with this? Or is this an enhancement for the normal gRPC authz service to provide it the same capabilities as the HTTP authz service?
Member
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. @htuch This should be an enhancement for the standard gRPC authz service to be able to respond to HTTP downstream client. I'm not sure if we need
Member
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I think it's definitely the right thing for the gRPC authz service to make it explicit here. Metadata is really about the channel between the gRPC authz server and Envoy, it shouldn't be used to provide additional response information. |
||||
| // particularly useful when the authorization service needs to send specific responses to the | ||||
| // downstream client or to modify the request headers before dispatching them to the upstream. | ||||
| // E.g., when the authorization status is not OK, this message can be used by the authorization | ||||
|
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Could you clarify the behavior when the response does not include a
Member
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. That's right if no extra attributes are passed from a gRPC authz service to the filter, the behavior should continue the same. |
||||
| // service to the tell the filter to respond with specific HTTP headers, body, and status code. | ||||
| // When the authorization status is OK, this object may include the headers that should be | ||||
| // modified in the original request before it gets sent to the upstream. | ||||
|
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Is the desired behavior that the
Member
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. @saumoh Sorry for these confusing words. Yes, it should allow modifying the existing headers as well as inject new ones. I will rephrase all this comment. Thanks for pointing this out. |
||||
| message HttpResponse { | ||||
| // Http status code. | ||||
| int32 status_code = 1; | ||||
|
Member
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. You probably want to make this consistent with other uses of status code in the API, e.g. data-plane-api/envoy/api/v2/route/route.proto Line 582 in 641920a
|
||||
|
|
||||
| // Http entity headers. | ||||
| map<string, string> headers = 2; | ||||
|
|
||||
| // Http entity body. | ||||
| string body = 3; | ||||
| } | ||||
| } | ||||
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.
I think an enum instead of a bool would allow future extensibility
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.
Better IMO would actually be to make this a
oneofand just mergeHttpServiceas one of the options inside theoneof. This is in general what we are trying to do elsewhere. This brings the enum and the "only use if enum is set" logic together. If this impacts the already implemented non-HTTP code I would just go ahead and change it now since IMO I still consider this filter under development.Uh oh!
There was an error while loading. Please reload this page.
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.
Unless I'm missing something, It seems that the impact on the already implemented non-HTTP code would be the same with either
enumoroneof.The ExtAuthz message would look something like this:
And the decision on which client to use, somewhere here: https://github.com/envoyproxy/envoy/blob/da0dc5f5dac12651f211e321f9cd7b2c70bedde9/source/server/config/http/ext_authz.cc#L17
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.
The
oneofis a simpler way to represent mutually exclusive config when it's more than just a scalar value, i.e. the message. What you have there is basically what it would look like.