api
api copied to clipboard
istio
add auto_sni and auto_san field in ClientTLSSettings
Introducing the required fields to add auto_sni and auto_san feature for istio destination rule sni settings related issue: https://github.com/istio/istio/issues/27847
@ZhiHanZ: The following test failed, say /retest to rerun all failed tests:
| Test name | Commit | Details | Rerun command |
|---|---|---|---|
| release-notes_api | c827fe7731284fb2357f0d741b9274281143c947 | link | /test release-notes_api |
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.
@ZhiHanZ: PR needs rebase.
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.
Is there already an implementation of the auto_san and auto_sni property in the ClientTLSSetting or someone working or continuing on this PR? Did someone find the possibility to configure them via a custom EnvoyFilter? Thanks!
@ZhiHanZ @lizan Any history on why there was no activity on this PR further?
+1 Although the EnvoyFitler suggested by @breuerjo works pretty well, it would be great to have this included in the api. I'm interested in this PR as well. Any latest updates on this? @lizan
+1 we configure wildcard hosts in destinationRule , but we would like to auto-gen sni and san info, this PR can help. Any plan to support it?
@ZhiHanZ : If you are not planning to pursue this(I assume so, as there is no activity for quite sometime now), is it okay if I pick this up for further development?
FYI: I have created the below RFC to resume work on this task : https://docs.google.com/document/d/1pTUl-Ng3nXAWJb7UGJtalftznpxQEfID/edit
As per the latest discussions in the networking working group, an API change is not needed for supporting the same. The details are updated in the RFC, I think if you are okay, you can close this PR. I will be working on the implementation as per the RFC @ZhiHanZ