ext_authz: add support for passing destination service labels#16955
ext_authz: add support for passing destination service labels#16955lizan merged 20 commits intoenvoyproxy:mainfrom
Conversation
Signed-off-by: Rama Chavali <rama.rao@salesforce.com>
Signed-off-by: Rama Chavali <rama.rao@salesforce.com>
|
@lizan can you PTAL when you get chance? |
|
|
||
| // Optional labels that will be passed to :ref:`labels<envoy_v3_api_field_service.auth.v3.AttributeContext.Peer.labels>` in | ||
| // :ref:`destination<envoy_v3_api_field_service.auth.v3.AttributeContext.destination>` if provided. | ||
| map<string, string> destination_labels = 15; |
There was a problem hiding this comment.
do you expect these fields to be set at per route config so ext_authz get different labels per route? I'm thinking if we should use cluster metadata or something else instead of directly pass this in the config.
There was a problem hiding this comment.
Right now there is no such use case. But we never know. Using cluster metadata seems an interesting idea. What is the advantage of using cluster metadata than this? Is n't cluster metadata need to be configured for every service if the choice of using ext authz is done by few services using envoy filter or request authentication (in Istio world)? Are there any downsides of specifying in config?
There was a problem hiding this comment.
Just thinking loud, I was assuming this labels would be overlapping with cluster metadata so it blows the config size in LDS/RDS. I'd rather put them in a generic place but ext_authz specific.
There was a problem hiding this comment.
Another idea I was thinking was since these are destination labels - Could we use bootstrap metadata some how? If labels are there in bootstrap metadata - we just pass it - May be we will have to agree on some standard key?
There was a problem hiding this comment.
Another idea I was thinking was since these are destination labels - Could we use bootstrap metadata some how? If labels are there in bootstrap metadata - we just pass it - May be we will have to agree on some standard key?
Yeah that's my confusing point as well, if bootstrap metadata works why not use them? We can agree on standard key, or make the key configurable here.
There was a problem hiding this comment.
Ok. I think that makes sense to me. Should we start with agree on a key for now and if we need add config in future here?
There was a problem hiding this comment.
Should we standardize on LABELS as the key to start with?
There was a problem hiding this comment.
@lizan What do you think about adding a config "bootstrap_metadata_labels_key" and pass labels from that key?
Signed-off-by: Rama Chavali <rama.rao@salesforce.com>
Signed-off-by: Rama Chavali <rama.rao@salesforce.com>
Signed-off-by: Rama Chavali <rama.rao@salesforce.com>
|
@lizan moved to use bootstrap metadata key. Can you PTAL? |
Signed-off-by: Rama Chavali <rama.rao@salesforce.com>
| * dns resolver: added *DnsResolverOptions* protobuf message to reconcile all of the DNS lookup option flags. By setting the configuration option :ref:`use_tcp_for_dns_lookups <envoy_v3_api_field_config.core.v3.DnsResolverOptions.use_tcp_for_dns_lookups>` as true we can make the underlying dns resolver library to make only TCP queries to the DNS servers and by setting the configuration option :ref:`no_default_search_domain <envoy_v3_api_field_config.core.v3.DnsResolverOptions.no_default_search_domain>` as true the DNS resolver library will not use the default search domains. | ||
| * dns resolver: added *DnsResolutionConfig* to combine :ref:`dns_resolver_options <envoy_v3_api_field_config.core.v3.DnsResolutionConfig.dns_resolver_options>` and :ref:`resolvers <envoy_v3_api_field_config.core.v3.DnsResolutionConfig.resolvers>` in a single protobuf message. The field *resolvers* can be specified with a list of DNS resolver addresses. If specified, DNS client library will perform resolution via the underlying DNS resolvers. Otherwise, the default system resolvers (e.g., /etc/resolv.conf) will be used. |
Signed-off-by: Rama Chavali <rama.rao@salesforce.com>
Signed-off-by: Rama Chavali <rama.rao@salesforce.com>
Signed-off-by: Rama Chavali <rama.rao@salesforce.com>
Signed-off-by: Rama Chavali <rama.rao@salesforce.com>
Signed-off-by: Rama Chavali <rama.rao@salesforce.com>
Signed-off-by: Rama Chavali <rama.rao@salesforce.com>
Signed-off-by: Rama Chavali <rama.rao@salesforce.com>
Signed-off-by: Rama Chavali <rama.rao@salesforce.com>
|
/retest |
|
Retrying Azure Pipelines: |
Signed-off-by: Rama Chavali <rama.rao@salesforce.com>
|
/retest |
|
Retrying Azure Pipelines: |
|
/retest |
|
Retrying Azure Pipelines: |
Signed-off-by: Rama Chavali <rama.rao@salesforce.com>
…roxy#16955) Additional Description: add support for passing destination service labels Risk Level: Low Testing: Updated Docs Changes: Updated Release Notes: Added Fixes envoyproxy#16898 Signed-off-by: Rama Chavali <rama.rao@salesforce.com>
Commit Message:add support for passing destination service labels
Additional Description: add support for passing destination service labels
Risk Level: Low
Testing: Updated
Docs Changes: Updated
Release Notes: Added
Fixes #16898