-
Notifications
You must be signed in to change notification settings - Fork 687
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
Bypass Authentication via Configuration #174
Comments
This is now supported in Envoy, we can do this. Per @gsagula current Ambassador 0.50 Envoy already has the necessary code: |
Note #329, which asked about supporting regexes in the configuration of which mapping gets which auth. (Whether this can be supported is a question of the underlying Envoy support, of course.) |
I've started exploring this a bit, but I ran into an error:
This is the relevant snippet of the Envoy config that's generated: {
"route": {
"per_filter_config": {
"envoy.ext_authz": {
"disabled": true
}
},
"timeout": "3.000s",
"weighted_clusters": {
"clusters": [
{
"weight": 100,
"name": "cluster_httpbin_org_80"
}
]
},
"priority": null,
"prefix_rewrite": "/",
"host_rewrite": "httpbin.org"
},
"match": {
"prefix": "/httpbin/ip",
"headers": [
{
"exact_match": "[snip]:8443",
"name": ":authority"
}
],
"case_sensitive": true
}
} As far as I can tell, this is a valid config based on the docs. Is there anyone who's more familiar with configuring Envoy that could point me in the right direction here? For reference, here are the changes I've made compared to 0.50.0 (still a very early WIP): release/0.50.0...patricksanders:patricksanders/feature/auth-bypass |
As per Slack conversation, the correct way to use
|
implement some very basic ready and health probes
Many types of services need to be public or universally accessible without an authentication or authorization check. For example, Datawire's Scout service.
Another use case is dynamically generated hosts or paths, for example, using Forge it is common to use the
{{ service.name }}-{{ branch.name }}
strategy to provide independent URL's to access development versions of a service. Asking developers to continually update a rules table for that kind of information seems like a pain.To accomodate these use cases with the external auth module in Ambassador currently the module developer needs to create a way for developers to specify whitelist rules. Some strategies include updating an in-memory data structure such as a set of ignorable Hosts and Paths. Another idea might be an external database or some other piece of shared storage. The service author can then read and use that configuration to configure whitelist rules. However, this is not ideal... it puts a burden on the external auth developer to think about this functionality up front and also exposes a less than ideal UX.'
It would be preferable if Ambassador's configuration mechanism could specify whitelist properties that would tell Envoy to skip routing to the Auth service in certain cases, for example.
The bypass mechanism ideally should support host header and URL paths.
The text was updated successfully, but these errors were encountered: