text:
WebSSH on Intel CPU

[x] Doesn't work : [NSProcessInfo processInfo].isiOSAppOnMac

Bad behavior : Go to fullscreen on macOS instead of windowed

[x] Doesn't work : RMAppReceipt* receipt = [RMAppReceipt bundleReceipt];

Can't check receipt anymore

Thank you Arnaud for adding this as a future enhancement from my review comment, it will be truly amazing to have a single, iCloud synchronised application to manage my SSH clients between MacOS, iPhone, and iPad. I've been using iTerm2 and .ssh/config for years due to there being no decent alternatives aimed at the hobbyist market who don't want to pay silly money for a monthly subscription (I'm looking at you Termius).
Having the ability to configure all my ssh clients (lots of Raspberry Pi's, a couple of Docker servers, and some family IT) in a single app that is available on Mac, iPad, and iPhone, at a price that is just right, really makes your app stand out above all the others! I will certainly be letting all my Intel Mac owning friends know about this when available. :)
The other thing that makes your app stand out is your customer engagement! Responding to app reviews, listening to and implementing feedback, the ability to interact with you on Github, it's all positive stuff!
The future Proxy Jump feature just makes this even more better too! I have one more idea/feature request that I'll submit later today. :)

Thank you Arnaud for adding this as a future enhancement from my review comment

You're Welcome 👍

, it will be truly amazing to have a single, iCloud synchronised application to manage my SSH clients between MacOS, iPhone, and iPad.

Yes I was also looking for a such product and I decided to make it alive because I need it for home and office uses.

I've been using iTerm2 and .ssh/config for years due to there being no decent alternatives aimed at the hobbyist market who don't want to pay silly money for a monthly subscription (I'm looking at you Termius).

Termius is a great (perhaps the best) SSH client but, you're right the monthly subscription is a no go for me.

Having the ability to configure all my ssh clients (lots of Raspberry Pi's, a couple of Docker servers, and some family IT) in a single app that is available on Mac, iPad, and iPhone, at a price that is just right, really makes your app stand out above all the others!

Thank you so much for your support @jarrah31 ❗❤❗

I will certainly be letting all my Intel Mac owning friends know about this when available. :)

Thank you very much 😇

The other thing that makes your app stand out is your customer engagement!

I try to do my best to respond to every customer in a manner that everyone will be happy

Responding to app reviews, listening to and implementing feedback, the ability to interact with you on Github, it's all positive stuff!

Thank you so much @jarrah31 🙏

The future Proxy Jump feature just makes this even more better too!

I need it a lot because VPN doesn't fit all my needs

I have one more idea/feature request that I'll submit later today. :)

Of course you can 😉
Have a nice day ☀

Always waiting for a few third party libraries to be updated for x68_64 🕙

@jarrah31
WebSSH 16.0 - Gem has been submitted to Apple for verification.
It should supports Intel arch 🤞

There was a crash during the review 😢
I'm fixing the issue.

ls

@Ghareeb26

WebSSH is now available on macOS since 16.0
Please open an issue for any glitches.
Have a nice day ☀

I missed all my email notifications for this so apologies for the late reply.
This is really great news, I'm going to try this out now, thank you very much for implementing this new feature!

It really is great to finally have a decent MacOS SSH solution that syncs connections between iDevices without having to pay through the nose for the privilege. Thank you Arnaud!
Only issue I've seen so far is the pop-up notification bar was partially hidden when it notified I needed a pro subscription and when I restored my purchase.

Thank you a lot @jarrah31 for your feedback and support about WebSSH 🙏

@isontheline  I've noticed that there's no information in the app description about the ability to sync saved profiles between iPhone, iPad, and macOS, or the fact that macOS is supported too. This is an important feature for me and is something I would be looking for in the app description, so would it be possible to add this please to help future users?


text:
Read initial data from pre-instrumented files in "noop" instrumenter

This is part of my fix for using --all on externally instrumented files, as when using babel-plugin-istanbul (https://github.com/istanbuljs/babel-plugin-istanbul/issues/4). I laid out the idea for this part here.
Requires istanbuljs/istanbul-lib-instrument#28 and babel/babel#4746 (update: now both released, in istanbul-lib-instrument v1.2.0 and Babel v6.18.0 respectively).
To see the results and/or test this yourself, see the repo I've put up at https://github.com/motiz88/nyc-all-demo.
Known problems/kludges:

The code makes a special case in _maybeInstrumentSource for !this.instrument && this.all, in which case it will always go on to "instrument" the file (actually read the existing data in the noop instrumenter). This is because we can't know until we've read the file whether it is a transpiled version of a file we're interested in.
Instrumenting/testing when process.cwd() is a symlink causes problems at the moment, such as covered files being reported twice with different paths: one with 0% coverage and one with the actual coverage.

@motiz88 slick, I like that we ultimately take advantage of nyc already having logic for walking the directory structure, rather than moving this logic into babel-plugin-istanbul like I was originally thinking.
Instrumenting/testing when process.cwd() is a symlink causes problems at the moment
This isn't a blocker, but I bet this is a bug we could put some tests around and squash in the near future.

@motiz88 this will work fine if my project doesn't use babel, and we use --all, I'm sure our existing tests will catch this case.
We should also try to add a test for the new --all behavior; I'd be fine with doing it as a cli integration tests, and adding a new fixtures directory with babel config.

One thing to think about is that all the parsing and traversing is costly. And with this PR we walk the entire directory structure and parse every bit of JS we find (though actually I think node_modules is blacklisted somewhere - right?), all without knowing whether the user has even instrumented anything. So from a perf/least surprise standpoint, maybe we should keep the noop instrumenter the way it is, and let the user opt-in to looking for externally instrumented files.

@motiz88 it would be neat if we could get the best of both worlds; turn on the instrumenter hack for --all perhaps only if we detect we're in a babel environment. Perhaps there's a global set we can check?

@bcoe Hmm. I can't think of anything that I would want nyc to strictly assume about the way Babel is being used. It feels cleanest when we frame it as "loading stuff instrumented separately".
I kind of take back my concern about doing completely unintended work: If this applies only to !instrument && all, then the intent to load instrumented files from a different source is pretty clear, and so is the intent to report on files that have not been loaded in the coverage run.
I can imagine, however, still wanting to limit that crawl to a known location. If my sources are in src/ and my transpiled+instrumented files are in dist/, I want to be able to say so via the something like include and exclude, rather than let nyc loose on my entire directory tree.

@motiz88 this line of reasoning seems reasonable; If I've gone to the trouble of turning off the instrumenter, there's about a 99% chance I'm using babel 👍
Let's try to avoid adding more configuration dials and knobs if possible -- would love for things to feel magic.
One thing I've been meaning to ask; this approach will work well with babel-register?

@bcoe That's an interesting question.
Due to how babel-register works, files that are not required are never compiled. So nyc would have to instrument them to get the empty coverage object. Doesn't this already basically work when the config is all && instrument? (Haven't tested yet)
The one thing I can see being a problem is the babylon.parse call in istanbul-lib-instrument complaining on experimental syntax, which can be worked around by parsing with plugins: ["*"].

Okay, so with the two blocking PRs merged and released, this just needs tests, right? @bcoe I won't get around to it until at least tomorrow, sadly.

I am having multiple issues trying to set up a working test env on my Windows box. I don't believe I'll be able to write tests here any time soon. Maybe someone else can step in and complete this PR?

Changes Unknown when pulling 06262f60fa3debda5b0748543750d89800455314 on motiz88:read-initial-coverage into ** on istanbuljs:master**.

@motiz88 I can step up to the plate this weekend; I was hoping to test behavior with babel-register any ways.

@motiz88 released in:
npm cache clear; npm i nyc@next
This is a pretty big change, so would love the extra help testing against a few of your libraries.

source: gharchive/pull-request

authors: bcoe coveralls motiz88

repo: istanbuljs/nyc

license: isc

license_type: permissive

license_source: bigquery


text:
Fixes BusyBox nsenter from parsing iptables script args

Prevents BusyBox's build of nsenter from incorrectly parsing istio-iptables.sh arguments as its own. Discovered when using the Kubernetes distribution "k3s" (https://github.com/k3s-io/k3s/issues/1434). A similar fix was used for Linkerd.

Hi @marshallford. Thanks for your PR.
I'm waiting for a istio member to verify that this patch is reasonable to test. If it is, they should reply with /ok-to-test on its own line. Until that is done, I will not automatically test new commits in this PR, but the usual testing commands by org members will still work. Regular contributors should join the org to skip this step.
Once the patch is verified, the new status will be reflected by the ok-to-test label.
I understand the commands that are listed here.

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.

change seems reasonable but this repo is dead, thanks for reminding me we should archive it. Can you open in istio/istio (same code under "cni" repo)? Thanks!

Oops! Will do.

authors: howardjohn istio-testing marshallford

repo: istio/cni


text:
ICP k8s spec: allow override of image

If I want to override the image for a single component, I need to do a complex overlay. This should just be a part of the first class KubernetesResource

This is part of the new API but isn't plumbed through yet.

This is now doable e.g. istioctl manifest generate --set components.pilot.hub=foo
Same for tag.

source: gharchive/issue

authors: howardjohn ostromart

repo: istio/istio

license_source: github-api


text:
Develop e2e test for operator

Bug description
Please see this issue thread: https://github.com/istio/istio/issues/21063#issuecomment-585378472
Expected behavior
Steps to reproduce the bug
Version (include the output of istioctl version --remote and kubectl version and helm version if you used Helm)
How was Istio installed?
Environment where bug was observed (cloud vendor, OS, etc)

cc @dgn

closing in favor of a different contributor to reimplement this work: https://github.com/istio/istio/issues/21468

authors: howardjohn sdake


text:
Pilot OOM cause envoy return 503 NR

Bug description
In our scenes, we use envoy as gateway， pilot as the controller.
Recently，cause of ram pilot OOM. At the same time, envoy return 503 and the response flag is NR.
In envoy log ,we find no cluster

when pilot restarting , the route is ok, and return 200.
Expected behavior
How to avoid this scenes, when pilot OOM restart， not affect envoy route.
Steps to reproduce the bug
**Version **
we use istio: 1.4
envoy: 1.12
Additionally, please consider attaching a cluster state archive by attaching
the dump file to this issue.

Was the route that is 503ing actively changing? Ie a new service or virtual service or something is created then pilot OOM shortly after?

Was the route that is 503ing actively changing? Ie a new service or virtual service or something is created then pilot OOM shortly after?

Before pilot OOM, the route is ok.  But i found some ads pushing at the same time pilot OOM.

so it pushes some bad config then it crashes? can you provide. more info like logs and how much memory is used

Also please be aware of https://istio.io/latest/news/support/announcing-1.4-eol-final/

so it pushes some bad config then it crashes? can you provide. more info like logs and how much memory is used

Cause of endpoint changing，pilot OOM. At the same time, envoy return some 503 route. memory is 8G.
I can got crashing pilot logs,

Can you upgrade Istio? Even if we find a bug in Istio 1.4 we won't fix it, and we have made tons of performance optimizations since then

and see https://github.com/istio/istio/wiki/Analyzing-Istio-Performance

Hi, I'm colleague of @ethanhanjiahao . we have reproduced that pilot send bad config to envoy, it is similar to https://github.com/istio/istio/issues/20295 .
To make it easier to reproduce, we disable pilot GC to simulate OOM and set pilot replicas to 1, set initial readiness probe delay seconds to 60s .
The timeline is as following:
07:16:46 pilot OOM , config grpc closed , envoy first try to reconnect failed, envoy second try to connect failed
07:16:47 pilot container started
07:16:49 envoy reconnect success
07:16:51 pilot pod ip removed from iptables
07:18:23 pilot pod ready
There is a high latency between pilot pod crash and iptables update ( 07:16:46 ~ 07:16:51 , due to kube-proxy cpu throttle), so even if pilot is not ready, envoy can connect to pilot.
Istio version is 1.2 , there is an option to let grpc server start after cache synced, but it is not enabled in our deploy. So envoy can establish connection to pilot even if pilot is not ready.
My concern is pilot should not assume readiness probe is always reliable. seeing from master, there is no guarantee for that.
@howardjohn
following is packets captured during envoy reconnect

Thanks for the findings! @ramaraochavali I thought you had some code for  this, did it get lost?

No. There we have only handled the case for local Envoy by pushing https://github.com/istio/istio/blob/master/pilot/pkg/bootstrap/server.go#L362 and relying on readiness probes for other Envoys?
There are two issues I see here

In Istiod we do not have a check in readiness probe that validates caches have been synced. It is easy to add that.
Based on the above description, it looks like  even if add cache sync to readiness probe - Envoys still might connect. I think we should reconsider this PR https://github.com/istio/istio/pull/20296 (which we have reverted in-favour of relying on readiness probes) which rejects connections till caches have been synced.

WDYT?
If we agree with that approach, I can push a PR to cover both.

Yeah sounds reasonable to reject connections. Note: our syncing is still
broken a bit, see https://github.com/istio/istio/pull/24339
On Tue, Jul 21, 2020 at 7:13 AM Rama Chavali notifications@github.com
wrote:

No. There we have only handled the case for local Envoy by pushing
https://github.com/istio/istio/blob/master/pilot/pkg/bootstrap/server.go#L362
and relying on readiness probes for other Envoys?
There are two issues I see here

In Istiod we do not have a check in readiness probe that validates
caches have been synced. It is easy to add that.
Based on the above description, it looks like even if add cache sync
to readiness probe - Envoys still might connect. I think we should
reconsider this PR #20296 https://github.com/istio/istio/pull/20296
(which we have reverted in-favour of relying on readiness probes) which
rejects connections till caches have been synced.

WDYT?
If we agree with that approach, I can push a PR to cover both.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/istio/istio/issues/25495#issuecomment-661886670, or
unsubscribe
https://github.com/notifications/unsubscribe-auth/AAEYGXNN4PK55GUZA5DOUN3R4WPB5ANCNFSM4OZPQKIA
.

Ok. I will take a look and push a PR then

This https://github.com/istio/istio/pull/25733 should address this. Please let us know if there are any open issues. I am closing this issue.

authors: caitong93 ethanhanjiahao howardjohn ramaraochavali


text:
"GET / HTTP/2" 404 NR when trying trying to go via ingressgateway

In short, what we are trying to achieve is this:
Laptop > Ingress gateway > external service in the environment
So we have a VM that runs some services, that VM is accessible by the cluster. doing a curl from the ingress gateway  podconfirms it can access the VM.
The VM is on an HTTPS endpoint.
The end goal is to have the VM accessable by hitting the ingress gateway as this is one of the entry points to our environment.
There is an HTTP as well as an HTTPS endpoint on the VM. Using the same (apart from changing the tls to http in the VS and https with http in the Service Entry) works with the HTTP endpoint, but once we try HTTPS, it just doesn't work at all.
I have added a service entry, a destination rule and
apiVersion: networking.istio.io/v1alpha3
kind: ServiceEntry
metadata:
  name: test1
  namespace: istio-system
spec:
  hosts:
  - VM.endpoint.com
  ports:
  - number: 8123
    name: https
    protocol: HTTPS
  resolution: DNS
  location: MESH_EXTERNAL
---
apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
  name: test1
  namespace: istio-system
spec:
  host: VM.endpoint.com
---
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: test1
  namespace: istio-system
spec:
  gateways:
  - istio-system/tls-gateway
  hosts:
  - subdom.maindom.com
  tls:
  - match:
    - port: 443
      sniHosts:
      - subdom.maindom.com
    route:
    - destination:
        host: VM.endpoint.com
        port:
          number: 8123

Please add config dump from Ingressgateway pod: https://github.com/istio/istio/wiki/Troubleshooting-Istio. And ideally access log of failed request and the curl command used to reproduce

Also try istioctl analyze -A to see if it detect any issues

You have sniHosts: ["subdom.maindom.com"].  Can you supply the exact curl parameters you are using?  You must curl subdom.maindom.com.  It will not work without DNS unless you use curl's --resolve.

Sorry for taking ages guys. had to move to another cluster
Config dump:
config_dump.zip
curl:
$ curl https://k8s.REDACTED.com/ -v
* About to connect() to k8s.REDACTED.com port 443 (#0)
*   Trying 10.32.0.250...
* Connected to k8s.REDACTED.com (10.32.0.250) port 443 (#0)
* Initializing NSS with certpath: sql:/etc/pki/nssdb
*   CAfile: /etc/pki/tls/certs/ca-bundle.crt
  CApath: none
* SSL connection using TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
* Server certificate:
* 	subject: XXXXX
* 	start date: Jun 05 07:14:24 2020 GMT
* 	expire date: Jun 05 07:14:54 2021 GMT
* 	common name: kXXXXX
* 	issuer: XXXXXX
> GET / HTTP/1.1
> User-Agent: curl/7.29.0
> Host: k8s.REDACTED.com
> Accept: */*
>
< HTTP/1.1 404 Not Found
< date: Wed, 19 Aug 2020 10:06:23 GMT
< server: istio-envoy
< content-length: 0
<
* Connection #0 to host k8s.REDACTED.com left intact

Istio-proxy log:
[2020-08-19T10:06:21.354Z] "GET / HTTP/1.1" 404 NR "-" "-" 0 0 0 - "10.32.0.3" "curl/7.29.0" "db74d55d-c96c-462e-b596-1c991df72b51" "k8s.REDACTED.com" "-" - - 10.32.66.2:443 10.32.0.3:42776 k8s.REDACTED.com -
Clearer yaml than above to avoid confusion:
apiVersion: networking.istio.io/v1alpha3
kind: ServiceEntry
metadata:
  name: notebook
  namespace: istio-system
spec:
  hosts:
  - ventsislav-m.c.green-1-cpt-jojo-dev-1.internal
  ports:
  - number: 8123
    name: https
    protocol: HTTPS
  resolution: DNS
  location: MESH_EXTERNAL
---
apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
  name: notebook
  namespace: istio-system
spec:
  host: ventsislav-m.c.green-1-cpt-jojo-dev-1.internal
---
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: notebook
  namespace: istio-system
spec:
  gateways:
  - istio-system/tls-gateway
  hosts:
  - k8s.REDACTED.com
  tls:
  - match:
    - port: 443
      sniHosts:
      - k8s.REDACTED.com
    route:
    - destination:
        host: ventsislav-m.c.green-1-cpt-jojo-dev-1.internal
        port:
          number: 8123

Curl from ingressgateway pod to the external service:
$ curl https://ventsislav-m.c.green-1-cpt-jojo-dev-1.internal:8123 -v -k
* Rebuilt URL to: https://ventsislav-m.c.green-1-cpt-jojo-dev-1.internal:8123/
*   Trying 10.32.3.195...
* TCP_NODELAY set
* Connected to ventsislav-m.c.green-1-cpt-jojo-dev-1.internal (10.32.3.195) port 8123 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* successfully set certificate verify locations:
*   CAfile: /etc/ssl/certs/ca-certificates.crt
  CApath: /etc/ssl/certs
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* TLSv1.3 (IN), TLS handshake, Server hello (2):
* TLSv1.2 (IN), TLS handshake, Certificate (11):
* TLSv1.2 (IN), TLS handshake, Server key exchange (12):
* TLSv1.2 (IN), TLS handshake, Server finished (14):
* TLSv1.2 (OUT), TLS handshake, Client key exchange (16):
* TLSv1.2 (OUT), TLS change cipher, Client hello (1):
* TLSv1.2 (OUT), TLS handshake, Finished (20):
* TLSv1.2 (IN), TLS handshake, Finished (20):
* SSL connection using TLSv1.2 / ECDHE-ECDSA-AES256-GCM-SHA384
* ALPN, server did not agree to a protocol
* Server certificate:
*  subject: CN=ventsislav-m.europe-west1-b.c.green-1-cpt-jojo-dev-1.internal
*  start date: Aug 19 09:29:37 2020 GMT
*  expire date: Aug 26 09:30:07 2020 GMT
*  issuer: XXXXXX
*  SSL certificate verify result: unable to get local issuer certificate (20), continuing anyway.
> GET / HTTP/1.1
> Host: ventsislav-m.c.green-1-cpt-jojo-dev-1.internal:8123
> User-Agent: curl/7.58.0
> Accept: */*
>
< HTTP/1.1 302 Found
< Server: TornadoServer/6.0.3
< Content-Type: text/html; charset=UTF-8
< Date: Wed, 19 Aug 2020 10:18:44 GMT
< Location: /tree?
< Content-Length: 0
<
* Connection #0 to host ventsislav-m.c.green-1-cpt-jojo-dev-1.internal left intact

NAME                                         DOMAINS              MATCH                  VIRTUAL SERVICE
https.443.https.tls-gateway.istio-system     k8s.REDACTED.com     /elasticsearch/*       elasticsearch.elasticsearch
https.443.https.tls-gateway.istio-system     k8s.REDACTED.com     /elasticsearch         elasticsearch.elasticsearch
https.443.https.tls-gateway.istio-system     k8s.REDACTED.com     /REDACTED/*            REDACTED.REDACTED
https.443.https.tls-gateway.istio-system     k8s.REDACTED.com     /prometheus/*          prometheus-server.prometheus
https.443.https.tls-gateway.istio-system     k8s.REDACTED.com     /airflow/*             airflow.airflow
https.443.https.tls-gateway.istio-system     k8s.REDACTED.com     /airflow               airflow.airflow

You are calling on / but there is no config for this.

Your recent post and original post don't seem to align though... it should be noted, tls route is used only if we do passthrough TLS. If you are terminating TLS then it should be doing http routing.
From the config you are not doing any passhtrough. If you want to terminate and re-originate TLS you can do so with a DR

Ended up with an nginx in the middle as it was taking too long to find the proper solution.

authors: MrVentzi esnible howardjohn


text:
TLSV1_ALERT_UNKNOWN_CA for some deployments in cluster and Gateway with tlsMode SIMPLE

Bug description
We are migrating istio from 1.4.5 to 1.7.3 version, we recreated our cluster with istio 1.7.3 using istioctl. We started experiencing 503 errors for deployments with error TLSV1_ALERT_UNKNOWN_CA in ingressgateway pods. We are using Gateway with tlsMode: SIMPLE and ideally it shouldn't fail with CA error. Also, out of 5 deployments, 2 deployments started working after a day without any change to cluster but other deployments , request is terminating with TLSV1_ALERT_UNKNOWN_CA in in ingressgateway pods. And we just created deployments with different name but using same configuration for all deployments.
Complete error in istio-ingressgateway:
"GET /ping HTTP/2" 503 UF,URX "-" "TLS error: 268436504:SSL routines:OPENSSL_internal:TLSV1_ALERT_UNKNOWN_CA" 0 91 48 - "XX.XX.XX.XX" "curl/7.54.0" "487df73f-2d2c-4f3d-a724-d112039bsds3" "keerthg-test-card-5-v1.XX.XX.XX.com" "XX.XX.XX.XX:8200" outbound|8080|v1|keerthg-test-card-5-v1.default.svc.cluster.local - XX.XX.XX.XX:8443 XX.XX.XX.XX:47172 keerthg-test-card-5-v1.XX.XX.XX.com -
IngressGateway for HTTPS
apiVersion: networking.istio.io/v1alpha3
kind: Gateway
metadata:
name: httpsingressgateway # use FQDN name when referencing from other namespaces: httpsingressgateway.istio-system.svc.cluster.local
spec:
selector:
istio: ingressgateway # use istio default ingress gateway
servers:

port:
number: 443
name: https
protocol: HTTPS
tls:
mode: SIMPLE
credentialName: ingressgateway-certs
hosts:

"*"

[ ] Docs
[X ] Installation
[ ] Networking
[ ] Performance and Scalability
[ ] Extensions and Telemetry
[ ] Security
[ X] Test and Release
[X ] User Experience
[ X] Developer Infrastructure
Expected behavior

We should not see 503 errors and face TLSV1_ALERT_UNKNOWN_CA for gateway using tlsMode: SIMPLE.
8 It's scary that requests to similar deployments is working and others not.

Steps to reproduce the bug
Error is not consistent and provided Gateway config , istiocrl command etc. in description
Version (include the output of istioctl version --remote and kubectl version --short and helm version if you used Helm)
$ kubectl version --short
Client Version: v1.17.0
Server Version: v1.18.9-eks-d1db3c
Istio: 1.7.3
How was Istio installed?
istioctl command is used to generate Istio config:
istioctl manifest generate --namespace istio-system  --set meshConfig.disablePolicyChecks=true --set meshConfig.enableTracing=false --set meshConfig.enableAutoMtls=true   --set meshConfig.accessLogFile=/dev/stdout --set meshConfig.outboundTrafficPolicy.mode=REGISTRY_ONLY  --set meshConfig.enablePrometheusMerge=false --set values.global.proxy.autoInject=disabled  --set values.global.proxy.resources.requests.cpu=100m  --set values.global.defaultResources.requests.cpu=100m --set components.pilot.k8s.hpaSpec.minReplicas=5 --set components.pilot.k8s.hpaSpec.maxReplicas=50  --set components.ingressGateways.NodePort > istio-1.7.3.yaml
Environment where bug was observed (cloud vendor, OS, etc)
AWS EKS

Can you get a configdump from the ingress pod? SEe https://github.com/istio/istio/wiki/Troubleshooting-Istio
Do you have any other Gateways that are MUTUAL type?

Config from ingress pod:
{
 "configs": [
  {
   "@type": "type.googleapis.com/envoy.admin.v3.BootstrapConfigDump",
   "bootstrap": {
    "node": {
     "id": "router~XX.XX>XX~istio-ingressgateway-556d8ddccd-qbp58.istio-system~istio-system.svc.cluster.local",
     "cluster": "istio-ingressgateway",
     "metadata": {
      "SERVICE_ACCOUNT": "istio-ingressgateway-service-account",
      "MESH_ID": "cluster.local",
      "SDS": "true",
      "WORKLOAD_NAME": "istio-ingressgateway",
      "OWNER": "kubernetes://apis/apps/v1/namespaces/istio-system/deployments/istio-ingressgateway",
      "ROUTER_MODE": "sni-dnat",
      "ISTIO_VERSION": "1.7.4",
      "PROXY_CONFIG": {
       "controlPlaneAuthPolicy": "MUTUAL_TLS",
       "drainDuration": "45s",
       "proxyMetadata": {
        "DNS_AGENT": ""
       },
       "terminationDrainDuration": "5s",
       "tracing": {
        "zipkin": {
         "address": "zipkin.istio-system:9411"
        }
       },
       "statusPort": 15020,
       "serviceCluster": "istio-ingressgateway",
       "envoyMetricsService": {},
       "discoveryAddress": "istiod.istio-system.svc:15012",
       "binaryPath": "/usr/local/bin/envoy",
       "concurrency": 0,
       "envoyAccessLogService": {},
       "statNameLength": 189,
       "configPath": "./etc/istio/proxy",
       "parentShutdownDuration": "60s",
       "proxyAdminPort": 15000
      },
      "PLATFORM_METADATA": {
       "aws_instance_id": "i-01315f41cb98eba21",
       "aws_account_id": "346303860452",
       "aws_availability_zone": "us-west-2a",
       "aws_region": "us-west-2"
      },
      "CLUSTER_ID": "Kubernetes",
      "LABELS": {
       "app": "istio-ingressgateway",
       "service.istio.io/canonical-revision": "latest",
       "pod-template-hash": "556d8ddccd",
       "heritage": "Tiller",
       "istio": "ingressgateway",
       "chart": "gateways",
       "service.istio.io/canonical-name": "istio-ingressgateway",
       "release": "istio"
      },
      "ISTIO_PROXY_SHA": "istio-proxy:5694187abcc4aea15a701bff18858a2e9216e609",
      "NAME": "istio-ingressgateway-556d8ddccd-qbp58",
      "NAMESPACE": "istio-system",
      "EXCHANGE_KEYS": "NAME,NAMESPACE,INSTANCE_IPS,LABELS,OWNER,PLATFORM_METADATA,WORKLOAD_NAME,MESH_ID,SERVICE_ACCOUNT,CLUSTER_ID",
      "INSTANCE_IPS": "X.X.X.X"
     },
     "locality": {
      "region": "us-west-2",
      "zone": "us-west-2a"
     },
     "hidden_envoy_deprecated_build_version": "5694187abcc4aea15a701bff18858a2e9216e609/1.15.1-dev/Clean/RELEASE/BoringSSL",
     "user_agent_name": "envoy",
     "user_agent_build_version": {
      "version": {
       "major_number": 1,
       "minor_number": 15,
       "patch": 1
      },
      "metadata": {
       "build.type": "RELEASE",
       "ssl.version": "BoringSSL",
       "revision.status": "Clean",
       "revision.sha": "5694187abcc4aea15a701bff18858a2e9216e609",
       "build.label": "dev"
      }
     },
     "extensions": [
      {
       "name": "raw_udp_listener",
       "category": "envoy.udp_listeners"
      },
      {
       "name": "envoy.client_ssl_auth",
       "category": "envoy.filters.network"
      },
      {
       "name": "envoy.echo",
       "category": "envoy.filters.network"
      },
      {
       "name": "envoy.ext_authz",
       "category": "envoy.filters.network"
      },
      {
       "name": "envoy.filters.network.client_ssl_auth",
       "category": "envoy.filters.network"
      },
      {
       "name": "envoy.filters.network.direct_response",
       "category": "envoy.filters.network"
      },
      {
       "name": "envoy.filters.network.dubbo_proxy",
       "category": "envoy.filters.network"
      },
      {
       "name": "envoy.filters.network.echo",
       "category": "envoy.filters.network"
      },
      {
       "name": "envoy.filters.network.ext_authz",
       "category": "envoy.filters.network"
      },
      {
       "name": "envoy.filters.network.http_connection_manager",
       "category": "envoy.filters.network"
      },
      {
       "name": "envoy.filters.network.kafka_broker",
       "category": "envoy.filters.network"
      },
      {
       "name": "envoy.filters.network.local_ratelimit",
       "category": "envoy.filters.network"
      },
      {
       "name": "envoy.filters.network.metadata_exchange",
       "category": "envoy.filters.network"
      },
      {
       "name": "envoy.filters.network.mongo_proxy",
       "category": "envoy.filters.network"
      },
      {
       "name": "envoy.filters.network.mysql_proxy",
       "category": "envoy.filters.network"
      },
      {
       "name": "envoy.filters.network.postgres_proxy",
       "category": "envoy.filters.network"
      },
      {
       "name": "envoy.filters.network.ratelimit",
       "category": "envoy.filters.network"
      },
      {
       "name": "envoy.filters.network.rbac",
       "category": "envoy.filters.network"
      },
      {
       "name": "envoy.filters.network.redis_proxy",
       "category": "envoy.filters.network"
      },
      {
       "name": "envoy.filters.network.rocketmq_proxy",
       "category": "envoy.filters.network"
      },
      {
       "name": "envoy.filters.network.sni_cluster",
       "category": "envoy.filters.network"
      },
      {
       "name": "envoy.filters.network.sni_dynamic_forward_proxy",
       "category": "envoy.filters.network"
      },
      {
       "name": "envoy.filters.network.tcp_cluster_rewrite",
       "category": "envoy.filters.network"
      },
      {
       "name": "envoy.filters.network.tcp_proxy",
       "category": "envoy.filters.network"
      },
      {
       "name": "envoy.filters.network.thrift_proxy",
       "category": "envoy.filters.network"
      },
      {
       "name": "envoy.filters.network.wasm",
       "category": "envoy.filters.network"
      },
      {
       "name": "envoy.filters.network.zookeeper_proxy",
       "category": "envoy.filters.network"
      },
      {
       "name": "envoy.http_connection_manager",
       "category": "envoy.filters.network"
      },
      {
       "name": "envoy.mongo_proxy",
       "category": "envoy.filters.network"
      },
      {
       "name": "envoy.ratelimit",
       "category": "envoy.filters.network"
      },
      {
       "name": "envoy.redis_proxy",
       "category": "envoy.filters.network"
      },
      {
       "name": "envoy.tcp_proxy",
       "category": "envoy.filters.network"
      },
      {
       "name": "forward_downstream_sni",
       "category": "envoy.filters.network"
      },
      {
       "name": "mixer",
       "category": "envoy.filters.network"
      },
      {
       "name": "sni_verifier",
       "category": "envoy.filters.network"
      },
      {
       "name": "envoy.transport_sockets.alts",
       "category": "envoy.transport_sockets.upstream"
      },
      {
       "name": "envoy.transport_sockets.quic",
       "category": "envoy.transport_sockets.upstream"
      },
      {
       "name": "envoy.transport_sockets.raw_buffer",
       "category": "envoy.transport_sockets.upstream"
      },
      {
       "name": "envoy.transport_sockets.tap",
       "category": "envoy.transport_sockets.upstream"
      },
      {
       "name": "envoy.transport_sockets.tls",
       "category": "envoy.transport_sockets.upstream"
      },
      {
       "name": "raw_buffer",
       "category": "envoy.transport_sockets.upstream"
      },
      {
       "name": "tls",
       "category": "envoy.transport_sockets.upstream"
      },
      {
       "name": "envoy.transport_sockets.alts",
       "category": "envoy.transport_sockets.downstream"
      },
      {
       "name": "envoy.transport_sockets.quic",
       "category": "envoy.transport_sockets.downstream"
      },
      {
       "name": "envoy.transport_sockets.raw_buffer",
       "category": "envoy.transport_sockets.downstream"
      },
      {
       "name": "envoy.transport_sockets.tap",
       "category": "envoy.transport_sockets.downstream"
      },
      {
       "name": "envoy.transport_sockets.tls",
       "category": "envoy.transport_sockets.downstream"
      },
      {
       "name": "raw_buffer",
       "category": "envoy.transport_sockets.downstream"
      },
      {
       "name": "tls",
       "category": "envoy.transport_sockets.downstream"
      },
      {
       "name": "dubbo.hessian2",
       "category": "envoy.dubbo_proxy.serializers"
      },
      {
       "name": "dubbo",
       "category": "envoy.dubbo_proxy.protocols"
      },
      {
       "name": "envoy.ip",
       "category": "envoy.resolvers"
      },
      {
       "name": "envoy.retry_priorities.previous_priorities",
       "category": "envoy.retry_priorities"
      },
      {
       "name": "envoy.resource_monitors.fixed_heap",
       "category": "envoy.resource_monitors"
      },
      {
       "name": "envoy.resource_monitors.injected_resource",
       "category": "envoy.resource_monitors"
      },
      {
       "name": "envoy.access_loggers.file",
       "category": "envoy.access_loggers"
      },
      {
       "name": "envoy.access_loggers.http_grpc",
       "category": "envoy.access_loggers"
      },
      {
       "name": "envoy.access_loggers.tcp_grpc",
       "category": "envoy.access_loggers"
      },
      {
       "name": "envoy.access_loggers.wasm",
       "category": "envoy.access_loggers"
      },
      {
       "name": "envoy.file_access_log",
       "category": "envoy.access_loggers"
      },
      {
       "name": "envoy.http_grpc_access_log",
       "category": "envoy.access_loggers"
      },
      {
       "name": "envoy.tcp_grpc_access_log",
       "category": "envoy.access_loggers"
      },
      {
       "name": "envoy.wasm_access_log",
       "category": "envoy.access_loggers"
      },
      {
       "name": "auto",
       "category": "envoy.thrift_proxy.transports"
      },
      {
       "name": "framed",
       "category": "envoy.thrift_proxy.transports"
      },
      {
       "name": "header",
       "category": "envoy.thrift_proxy.transports"
      },
      {
       "name": "unframed",
       "category": "envoy.thrift_proxy.transports"
      },
      {
       "name": "envoy.filters.udp.dns_filter",
       "category": "envoy.filters.udp_listener"
      },
      {
       "name": "envoy.filters.udp_listener.udp_proxy",
       "category": "envoy.filters.udp_listener"
      },
      {
       "name": "envoy.filters.dubbo.router",
       "category": "envoy.dubbo_proxy.filters"
      },
      {
       "name": "envoy.dog_statsd",
       "category": "envoy.stats_sinks"
      },
      {
       "name": "envoy.metrics_service",
       "category": "envoy.stats_sinks"
      },
      {
       "name": "envoy.stat_sinks.dog_statsd",
       "category": "envoy.stats_sinks"
      },
      {
       "name": "envoy.stat_sinks.hystrix",
       "category": "envoy.stats_sinks"
      },
      {
       "name": "envoy.stat_sinks.metrics_service",
       "category": "envoy.stats_sinks"
      },
      {
       "name": "envoy.stat_sinks.statsd",
       "category": "envoy.stats_sinks"
      },
      {
       "name": "envoy.statsd",
       "category": "envoy.stats_sinks"
      },
      {
       "name": "envoy.filters.connection_pools.http.generic",
       "category": "envoy.upstreams"
      },
      {
       "name": "envoy.filters.connection_pools.http.http",
       "category": "envoy.upstreams"
      },
      {
       "name": "envoy.filters.connection_pools.http.tcp",
       "category": "envoy.upstreams"
      },
      {
       "name": "envoy.bootstrap.wasm",
       "category": "envoy.bootstrap"
      },
      {
       "name": "envoy.filters.listener.http_inspector",
       "category": "envoy.filters.listener"
      },
      {
       "name": "envoy.filters.listener.original_dst",
       "category": "envoy.filters.listener"
      },
      {
       "name": "envoy.filters.listener.original_src",
       "category": "envoy.filters.listener"
      },
      {
       "name": "envoy.filters.listener.proxy_protocol",
       "category": "envoy.filters.listener"
      },
      {
       "name": "envoy.filters.listener.tls_inspector",
       "category": "envoy.filters.listener"
      },
      {
       "name": "envoy.listener.http_inspector",
       "category": "envoy.filters.listener"
      },
      {
       "name": "envoy.listener.original_dst",
       "category": "envoy.filters.listener"
      },
      {
       "name": "envoy.listener.original_src",
       "category": "envoy.filters.listener"
      },
      {
       "name": "envoy.listener.proxy_protocol",
       "category": "envoy.filters.listener"
      },
      {
       "name": "envoy.listener.tls_inspector",
       "category": "envoy.filters.listener"
      },
      {
       "name": "envoy.dynamic.ot",
       "category": "envoy.tracers"
      },
      {
       "name": "envoy.lightstep",
       "category": "envoy.tracers"
      },
      {
       "name": "envoy.tracers.datadog",
       "category": "envoy.tracers"
      },
      {
       "name": "envoy.tracers.dynamic_ot",
       "category": "envoy.tracers"
      },
      {
       "name": "envoy.tracers.lightstep",
       "category": "envoy.tracers"
      },
      {
       "name": "envoy.tracers.opencensus",
       "category": "envoy.tracers"
      },
      {
       "name": "envoy.tracers.xray",
       "category": "envoy.tracers"
      },
      {
       "name": "envoy.tracers.zipkin",
       "category": "envoy.tracers"
      },
      {
       "name": "envoy.zipkin",
       "category": "envoy.tracers"
      },
      {
       "name": "default",
       "category": "envoy.dubbo_proxy.route_matchers"
      },
      {
       "name": "envoy.cluster.eds",
       "category": "envoy.clusters"
      },
      {
       "name": "envoy.cluster.logical_dns",
       "category": "envoy.clusters"
      },
      {
       "name": "envoy.cluster.original_dst",
       "category": "envoy.clusters"
      },
      {
       "name": "envoy.cluster.static",
       "category": "envoy.clusters"
      },
      {
       "name": "envoy.cluster.strict_dns",
       "category": "envoy.clusters"
      },
      {
       "name": "envoy.clusters.aggregate",
       "category": "envoy.clusters"
      },
      {
       "name": "envoy.clusters.dynamic_forward_proxy",
       "category": "envoy.clusters"
      },
      {
       "name": "envoy.clusters.redis",
       "category": "envoy.clusters"
      },
      {
       "name": "envoy.internal_redirect_predicates.allow_listed_routes",
       "category": "envoy.internal_redirect_predicates"
      },
      {
       "name": "envoy.internal_redirect_predicates.previous_routes",
       "category": "envoy.internal_redirect_predicates"
      },
      {
       "name": "envoy.internal_redirect_predicates.safe_cross_scheme",
       "category": "envoy.internal_redirect_predicates"
      },
      {
       "name": "envoy.retry_host_predicates.omit_canary_hosts",
       "category": "envoy.retry_host_predicates"
      },
      {
       "name": "envoy.retry_host_predicates.omit_host_metadata",
       "category": "envoy.retry_host_predicates"
      },
      {
       "name": "envoy.retry_host_predicates.previous_hosts",
       "category": "envoy.retry_host_predicates"
      },
      {
       "name": "envoy.compression.gzip.compressor",
       "category": "envoy.compression.compressor"
      },
      {
       "name": "envoy.compression.gzip.decompressor",
       "category": "envoy.compression.decompressor"
      },
      {
       "name": "envoy.filters.thrift.rate_limit",
       "category": "envoy.thrift_proxy.filters"
      },
      {
       "name": "envoy.filters.thrift.router",
       "category": "envoy.thrift_proxy.filters"
      },
      {
       "name": "envoy.grpc_credentials.aws_iam",
       "category": "envoy.grpc_credentials"
      },
      {
       "name": "envoy.grpc_credentials.default",
       "category": "envoy.grpc_credentials"
      },
      {
       "name": "envoy.grpc_credentials.file_based_metadata",
       "category": "envoy.grpc_credentials"
      },
      {
       "name": "auto",
       "category": "envoy.thrift_proxy.protocols"
      },
      {
       "name": "binary",
       "category": "envoy.thrift_proxy.protocols"
      },
      {
       "name": "binary/non-strict",
       "category": "envoy.thrift_proxy.protocols"
      },
      {
       "name": "compact",
       "category": "envoy.thrift_proxy.protocols"
      },
      {
       "name": "twitter",
       "category": "envoy.thrift_proxy.protocols"
      },
      {
       "name": "envoy.filters.network.upstream.metadata_exchange",
       "category": "envoy.filters.upstream_network"
      },
      {
       "name": "envoy.buffer",
       "category": "envoy.filters.http"
      },
      {
       "name": "envoy.cors",
       "category": "envoy.filters.http"
      },
      {
       "name": "envoy.csrf",
       "category": "envoy.filters.http"
      },
      {
       "name": "envoy.ext_authz",
       "category": "envoy.filters.http"
      },
      {
       "name": "envoy.fault",
       "category": "envoy.filters.http"
      },
      {
       "name": "envoy.filters.http.adaptive_concurrency",
       "category": "envoy.filters.http"
      },
      {
       "name": "envoy.filters.http.admission_control",
       "category": "envoy.filters.http"
      },
      {
       "name": "envoy.filters.http.aws_lambda",
       "category": "envoy.filters.http"
      },
      {
       "name": "envoy.filters.http.aws_request_signing",
       "category": "envoy.filters.http"
      },
      {
       "name": "envoy.filters.http.buffer",
       "category": "envoy.filters.http"
      },
      {
       "name": "envoy.filters.http.cache",
       "category": "envoy.filters.http"
      },
      {
       "name": "envoy.filters.http.compressor",
       "category": "envoy.filters.http"
      },
      {
       "name": "envoy.filters.http.cors",
       "category": "envoy.filters.http"
      },
      {
       "name": "envoy.filters.http.csrf",
       "category": "envoy.filters.http"
      },
      {
       "name": "envoy.filters.http.decompressor",
       "category": "envoy.filters.http"
      },
      {
       "name": "envoy.filters.http.dynamic_forward_proxy",
       "category": "envoy.filters.http"
      },
      {
       "name": "envoy.filters.http.dynamo",
       "category": "envoy.filters.http"
      },
      {
       "name": "envoy.filters.http.ext_authz",
       "category": "envoy.filters.http"
      },
      {
       "name": "envoy.filters.http.fault",
       "category": "envoy.filters.http"
      },
      {
       "name": "envoy.filters.http.grpc_http1_bridge",
       "category": "envoy.filters.http"
      },
      {
       "name": "envoy.filters.http.grpc_http1_reverse_bridge",
       "category": "envoy.filters.http"
      },
      {
       "name": "envoy.filters.http.grpc_json_transcoder",
       "category": "envoy.filters.http"
      },
      {
       "name": "envoy.filters.http.grpc_stats",
       "category": "envoy.filters.http"
      },
      {
       "name": "envoy.filters.http.grpc_web",
       "category": "envoy.filters.http"
      },
      {
       "name": "envoy.filters.http.gzip",
       "category": "envoy.filters.http"
      },
      {
       "name": "envoy.filters.http.header_to_metadata",
       "category": "envoy.filters.http"
      },
      {
       "name": "envoy.filters.http.health_check",
       "category": "envoy.filters.http"
      },
      {
       "name": "envoy.filters.http.ip_tagging",
       "category": "envoy.filters.http"
      },
      {
       "name": "envoy.filters.http.jwt_authn",
       "category": "envoy.filters.http"
      },
      {
       "name": "envoy.filters.http.lua",
       "category": "envoy.filters.http"
      },
      {
       "name": "envoy.filters.http.on_demand",
       "category": "envoy.filters.http"
      },
      {
       "name": "envoy.filters.http.original_src",
       "category": "envoy.filters.http"
      },
      {
       "name": "envoy.filters.http.ratelimit",
       "category": "envoy.filters.http"
      },
      {
       "name": "envoy.filters.http.rbac",
       "category": "envoy.filters.http"
      },
      {
       "name": "envoy.filters.http.router",
       "category": "envoy.filters.http"
      },
      {
       "name": "envoy.filters.http.squash",
       "category": "envoy.filters.http"
      },
      {
       "name": "envoy.filters.http.tap",
       "category": "envoy.filters.http"
      },
      {
       "name": "envoy.filters.http.wasm",
       "category": "envoy.filters.http"
      },
      {
       "name": "envoy.grpc_http1_bridge",
       "category": "envoy.filters.http"
      },
      {
       "name": "envoy.grpc_json_transcoder",
       "category": "envoy.filters.http"
      },
      {
       "name": "envoy.grpc_web",
       "category": "envoy.filters.http"
      },
      {
       "name": "envoy.gzip",
       "category": "envoy.filters.http"
      },
      {
       "name": "envoy.health_check",
       "category": "envoy.filters.http"
      },
      {
       "name": "envoy.http_dynamo_filter",
       "category": "envoy.filters.http"
      },
      {
       "name": "envoy.ip_tagging",
       "category": "envoy.filters.http"
      },
      {
       "name": "envoy.lua",
       "category": "envoy.filters.http"
      },
      {
       "name": "envoy.rate_limit",
       "category": "envoy.filters.http"
      },
      {
       "name": "envoy.router",
       "category": "envoy.filters.http"
      },
      {
       "name": "envoy.squash",
       "category": "envoy.filters.http"
      },
      {
       "name": "istio.alpn",
       "category": "envoy.filters.http"
      },
      {
       "name": "istio_authn",
       "category": "envoy.filters.http"
      },
      {
       "name": "mixer",
       "category": "envoy.filters.http"
      },
      {
       "name": "envoy.health_checkers.redis",
       "category": "envoy.health_checkers"
      },
      {
       "name": "envoy.extensions.http.cache.simple",
       "category": "http_cache_factory"
      }
     ]
    },
    "static_resources": {
     "listeners": [
      {
       "address": {
        "socket_address": {
         "address": "0.0.0.0",
         "port_value": 15090
        }
       },
       "filter_chains": [
        {
         "filters": [
          {
           "name": "envoy.http_connection_manager",
           "typed_config": {
            "@type": "type.googleapis.com/envoy.extensions.filters.network.http_connection_manager.v3.HttpConnectionManager",
            "stat_prefix": "stats",
            "route_config": {
             "virtual_hosts": [
              {
               "name": "backend",
               "domains": [
                "*"
               ],
               "routes": [
                {
                 "match": {
                  "prefix": "/stats/prometheus"
                 },
                 "route": {
                  "cluster": "prometheus_stats"
                 }
                }
               ]
              }
             ]
            },
            "http_filters": [
             {
              "name": "envoy.router",
              "typed_config": {
               "@type": "type.googleapis.com/envoy.extensions.filters.http.router.v3.Router"
              }
             }
            ]
           }
          }
         ]
        }
       ]
      },
      {
       "address": {
        "socket_address": {
         "address": "0.0.0.0",
         "port_value": 15021
        }
       },
       "filter_chains": [
        {
         "filters": [
          {
           "name": "envoy.http_connection_manager",
           "typed_config": {
            "@type": "type.googleapis.com/envoy.extensions.filters.network.http_connection_manager.v3.HttpConnectionManager",
            "stat_prefix": "agent",
            "route_config": {
             "virtual_hosts": [
              {
               "name": "backend",
               "domains": [
                "*"
               ],
               "routes": [
                {
                 "match": {
                  "prefix": "/healthz/ready"
                 },
                 "route": {
                  "cluster": "agent"
                 }
                }
               ]
              }
             ]
            },
            "http_filters": [
             {
              "name": "envoy.router",
              "typed_config": {
               "@type": "type.googleapis.com/envoy.extensions.filters.http.router.v3.Router"
              }
             }
            ]
           }
          }
         ]
        }
       ]
      }
     ],
     "clusters": [
      {
       "name": "prometheus_stats",
       "type": "STATIC",
       "connect_timeout": "0.250s",
       "load_assignment": {
        "cluster_name": "prometheus_stats",
        "endpoints": [
         {
          "lb_endpoints": [
           {
            "endpoint": {
             "address": {
              "socket_address": {
               "address": "127.0.0.1",
               "port_value": 15000
              }
             }
            }
           }
          ]
         }
        ]
       }
      },
      {
       "name": "agent",
       "type": "STATIC",
       "connect_timeout": "0.250s",
       "load_assignment": {
        "cluster_name": "prometheus_stats",
        "endpoints": [
         {
          "lb_endpoints": [
           {
            "endpoint": {
             "address": {
              "socket_address": {
               "address": "127.0.0.1",
               "port_value": 15020
              }
             }
            }
           }
          ]
         }
        ]
       }
      },
      {
       "name": "sds-grpc",
       "type": "STATIC",
       "connect_timeout": "1s",
       "http2_protocol_options": {},
       "load_assignment": {
        "cluster_name": "sds-grpc",
        "endpoints": [
         {
          "lb_endpoints": [
           {
            "endpoint": {
             "address": {
              "pipe": {
               "path": "./etc/istio/proxy/SDS"
              }
             }
            }
           }
          ]
         }
        ]
       }
      },
      {
       "name": "xds-grpc",
       "type": "STRICT_DNS",
       "connect_timeout": "1s",
       "max_requests_per_connection": 1,
       "circuit_breakers": {
        "thresholds": [
         {
          "max_connections": 100000,
          "max_pending_requests": 100000,
          "max_requests": 100000
         },
         {
          "priority": "HIGH",
          "max_connections": 100000,
          "max_pending_requests": 100000,
          "max_requests": 100000
         }
        ]
       },
       "http2_protocol_options": {},
       "dns_lookup_family": "V4_ONLY",
       "transport_socket": {
        "name": "envoy.transport_sockets.tls",
        "typed_config": {
         "@type": "type.googleapis.com/envoy.extensions.transport_sockets.tls.v3.UpstreamTlsContext",
         "common_tls_context": {
          "validation_context": {
           "trusted_ca": {
            "filename": "./var/run/secrets/istio/root-cert.pem"
           },
           "match_subject_alt_names": [
            {
             "exact": "istiod.istio-system.svc"
            }
           ]
          },
          "alpn_protocols": [
           "h2"
          ],
          "tls_certificate_sds_secret_configs": [
           {
            "name": "default",
            "sds_config": {
             "api_config_source": {
              "api_type": "GRPC",
              "grpc_services": [
               {
                "envoy_grpc": {
                 "cluster_name": "sds-grpc"
                }
               }
              ],
              "transport_api_version": "V3"
             },
             "initial_fetch_timeout": "0s",
             "resource_api_version": "V3"
            }
           }
          ]
         },
         "sni": "istiod.istio-system.svc"
        }
       },
       "upstream_connection_options": {
        "tcp_keepalive": {
         "keepalive_time": 300
        }
       },
       "load_assignment": {
        "cluster_name": "xds-grpc",
        "endpoints": [
         {
          "lb_endpoints": [
           {
            "endpoint": {
             "address": {
              "socket_address": {
               "address": "istiod.istio-system.svc",
               "port_value": 15012
              }
             }
            }
           }
          ]
         }
        ]
       },
       "respect_dns_ttl": true
      },
      {
       "name": "zipkin",
       "type": "STRICT_DNS",
       "connect_timeout": "1s",
       "dns_lookup_family": "V4_ONLY",
       "load_assignment": {
        "cluster_name": "zipkin",
        "endpoints": [
         {
          "lb_endpoints": [
           {
            "endpoint": {
             "address": {
              "socket_address": {
               "address": "zipkin.istio-system",
               "port_value": 9411
              }
             }
            }
           }
          ]
         }
        ]
       },
       "respect_dns_ttl": true
      }
     ]
    },
    "dynamic_resources": {
     "lds_config": {
      "ads": {},
      "resource_api_version": "V3"
     },
     "cds_config": {
      "ads": {},
      "resource_api_version": "V3"
     },
     "ads_config": {
      "api_type": "GRPC",
      "grpc_services": [
       {
        "envoy_grpc": {
         "cluster_name": "xds-grpc"
        }
       }
      ],
      "transport_api_version": "V3"
     }
    },
    "tracing": {
     "http": {
      "name": "envoy.zipkin",
      "typed_config": {
       "@type": "type.googleapis.com/envoy.config.trace.v3.ZipkinConfig",
       "collector_cluster": "zipkin",
       "collector_endpoint": "/api/v2/spans",
       "trace_id_128bit": true,
       "shared_span_context": false,
       "collector_endpoint_version": "HTTP_JSON"
      }
     }
    },
    "admin": {
     "access_log_path": "/dev/null",
     "profile_path": "/var/lib/istio/data/envoy.prof",
     "address": {
      "socket_address": {
       "address": "127.0.0.1",
       "port_value": 15000
      }
     }
    },
    "stats_config": {
     "stats_tags": [
      {
       "tag_name": "cluster_name",
       "regex": "^cluster\\.((.+?(\\..+?\\.svc\\.cluster\\.local)?)\\.)"
      },
      {
       "tag_name": "tcp_prefix",
       "regex": "^tcp\\.((.*?)\\.)\\w+?$"
      },
      {
       "tag_name": "response_code",
       "regex": "(response_code=\\.=(.+?);\\.;)|_rq(_(\\.d{3}))$"
      },
      {
       "tag_name": "response_code_class",
       "regex": "_rq(_(\\dxx))$"
      },
      {
       "tag_name": "http_conn_manager_listener_prefix",
       "regex": "^listener(?=\\.).*?\\.http\\.(((?:[_.[:digit:]]*|[_\\[\\]aAbBcCdDeEfF[:digit:]]*))\\.)"
      },
      {
       "tag_name": "http_conn_manager_prefix",
       "regex": "^http\\.(((?:[_.[:digit:]]*|[_\\[\\]aAbBcCdDeEfF[:digit:]]*))\\.)"
      },
      {
       "tag_name": "listener_address",
       "regex": "^listener\\.(((?:[_.[:digit:]]*|[_\\[\\]aAbBcCdDeEfF[:digit:]]*))\\.)"
      },
      {
       "tag_name": "mongo_prefix",
       "regex": "^mongo\\.(.+?)\\.(collection|cmd|cx_|op_|delays_|decoding_)(.*?)$"
      },
      {
       "tag_name": "reporter",
       "regex": "(reporter=\\.=(.*?);\\.;)"
      },
      {
       "tag_name": "source_namespace",
       "regex": "(source_namespace=\\.=(.*?);\\.;)"
      },
      {
       "tag_name": "source_workload",
       "regex": "(source_workload=\\.=(.*?);\\.;)"
      },
      {
       "tag_name": "source_workload_namespace",
       "regex": "(source_workload_namespace=\\.=(.*?);\\.;)"
      },
      {
       "tag_name": "source_principal",
       "regex": "(source_principal=\\.=(.*?);\\.;)"
      },
      {
       "tag_name": "source_app",
       "regex": "(source_app=\\.=(.*?);\\.;)"
      },
      {
       "tag_name": "source_version",
       "regex": "(source_version=\\.=(.*?);\\.;)"
      },
      {
       "tag_name": "source_cluster",
       "regex": "(source_cluster=\\.=(.*?);\\.;)"
      },
      {
       "tag_name": "destination_namespace",
       "regex": "(destination_namespace=\\.=(.*?);\\.;)"
      },
      {
       "tag_name": "destination_workload",
       "regex": "(destination_workload=\\.=(.*?);\\.;)"
      },
      {
       "tag_name": "destination_workload_namespace",
       "regex": "(destination_workload_namespace=\\.=(.*?);\\.;)"
      },
      {
       "tag_name": "destination_principal",
       "regex": "(destination_principal=\\.=(.*?);\\.;)"
      },
      {
       "tag_name": "destination_app",
       "regex": "(destination_app=\\.=(.*?);\\.;)"
      },
      {
       "tag_name": "destination_version",
       "regex": "(destination_version=\\.=(.*?);\\.;)"
      },
      {
       "tag_name": "destination_service",
       "regex": "(destination_service=\\.=(.*?);\\.;)"
      },
      {
       "tag_name": "destination_service_name",
       "regex": "(destination_service_name=\\.=(.*?);\\.;)"
      },
      {
       "tag_name": "destination_service_namespace",
       "regex": "(destination_service_namespace=\\.=(.*?);\\.;)"
      },
      {
       "tag_name": "destination_port",
       "regex": "(destination_port=\\.=(.*?);\\.;)"
      },
      {
       "tag_name": "destination_cluster",
       "regex": "(destination_cluster=\\.=(.*?);\\.;)"
      },
      {
       "tag_name": "request_protocol",
       "regex": "(request_protocol=\\.=(.*?);\\.;)"
      },
      {
       "tag_name": "request_operation",
       "regex": "(request_operation=\\.=(.*?);\\.;)"
      },
      {
       "tag_name": "request_host",
       "regex": "(request_host=\\.=(.*?);\\.;)"
      },
      {
       "tag_name": "response_flags",
       "regex": "(response_flags=\\.=(.*?);\\.;)"
      },
      {
       "tag_name": "grpc_response_status",
       "regex": "(grpc_response_status=\\.=(.*?);\\.;)"
      },
      {
       "tag_name": "connection_security_policy",
       "regex": "(connection_security_policy=\\.=(.*?);\\.;)"
      },
      {
       "tag_name": "permissive_response_code",
       "regex": "(permissive_response_code=\\.=(.*?);\\.;)"
      },
      {
       "tag_name": "permissive_response_policyid",
       "regex": "(permissive_response_policyid=\\.=(.*?);\\.;)"
      },
      {
       "tag_name": "source_canonical_service",
       "regex": "(source_canonical_service=\\.=(.*?);\\.;)"
      },
      {
       "tag_name": "destination_canonical_service",
       "regex": "(destination_canonical_service=\\.=(.*?);\\.;)"
      },
      {
       "tag_name": "source_canonical_revision",
       "regex": "(source_canonical_revision=\\.=(.*?);\\.;)"
      },
      {
       "tag_name": "destination_canonical_revision",
       "regex": "(destination_canonical_revision=\\.=(.*?);\\.;)"
      },
      {
       "tag_name": "cache",
       "regex": "(cache\\.(.+?)\\.)"
      },
      {
       "tag_name": "component",
       "regex": "(component\\.(.+?)\\.)"
      },
      {
       "tag_name": "tag",
       "regex": "(tag\\.(.+?);\\.)"
      },
      {
       "tag_name": "wasm_filter",
       "regex": "(wasm_filter\\.(.+?)\\.)"
      }
     ],
     "use_all_default_tags": false,
     "stats_matcher": {
      "inclusion_list": {
       "patterns": [
        {
         "prefix": "reporter="
        },
        {
         "prefix": "cluster_manager"
        },
        {
         "prefix": "listener_manager"
        },
        {
         "prefix": "http_mixer_filter"
        },
        {
         "prefix": "tcp_mixer_filter"
        },
        {
         "prefix": "server"
        },
        {
         "prefix": "cluster.xds-grpc"
        },
        {
         "prefix": "wasm"
        },
        {
         "prefix": "component"
        }
       ]
      }
     }
    },
    "layered_runtime": {
     "layers": [
      {
       "name": "deprecation",
       "static_layer": {
        "envoy.deprecated_features:envoy.config.listener.v3.Listener.hidden_envoy_deprecated_use_original_dst": true
       }
      },
      {
       "name": "admin",
       "admin_layer": {}
      }
     ]
    }
   },
   "last_updated": "2020-11-03T02:06:23.168Z"
  },
}

Question: Do you have any other Gateways that are MUTUAL type?

Can you get a configdump from the ingress pod? SEe https://github.com/istio/istio/wiki/Troubleshooting-Istio
Attached config in above comment.

Do you have any other Gateways that are MUTUAL type?

We have two Gateway , one in istio-system namespace and other one in custom-namespace and both are using SIMPLE mode. Other gateway in custom-namespace works fine and we have this issue in istio-system namespace.

the config dump seems to just be showing the bootstrap configuration and is missing all the interesting portion

configdump is over 10000 lines and i need to remove lot of content which i can't share. Is there anything specific your looking for?

Also seeing this issue. How can I send you a dump @howardjohn?

Specifically looking for the listener on port 443/8443. But the full one can be useful to avoid back and forth. You can send me on slack if you need to (same username)

For @2ZZ , this is fixed by https://github.com/istio/istio/pull/28273. May be different issue for @keerthig9 . Can verify by looking for anything with file-root in the config dump (at the bottom)

I will get configdump soon, Meanwhile i see other custom Gateway in custom namespace is working fine and have issues with only istio-ingressgateway which is default. Do u think any of below flags will be issue for default ingress
"ingressClass": "istio",
    "ingressService": "istio-ingressgateway",
    "ingressControllerMode": "STRICT",
    "accessLogFile": "/dev/stdout",

What does "ingressControllerMode": "STRICT" means? Can we have Gateway with tlsMode: SIMPLE when all below flags are enabled?
"ingressControllerMode": "STRICT",  "controlPlaneAuthPolicy": "MUTUAL_TLS", "enableAutoMtls": true,??

all these refer to https://istio.io/latest/docs/tasks/traffic-management/ingress/kubernetes-ingress/, should be fine

We were using below config to enable mtls in 1.4.5, is it applicable now? Having this config will have any impact?
---
# Default TLS Destination Rule for XXX-system namespace
---
apiVersion: "networking.istio.io/v1alpha3"
kind: "DestinationRule"
metadata:
  name: "default"
  namespace: XXX-system
spec:
  host: "*.local"
  trafficPolicy:
    tls:
      mode: ISTIO_MUTUAL
---

Ah, I was thinking original the error was between client and gasteway, but it is in gateway to keerthg-test-card-5-v1.default.svc.cluster.local
Can you give more info about keerthg-test-card-5-v1.default.svc.cluster.local, in particular the destination rule v1?
When you do get a config dump get it from keerthg-test-card-5-v1.default.svc.cluster.local as well as the gateway if possible!

Attached config dump for ingress and my test deployment
keerthg-test-config_dump.log
ingressgateway-config_dump.log

Cardrelated deployment resources:
DestinationRule
$ kubectl get destinationrule keerthg-test-card-9-v1 -o yaml
apiVersion: networking.istio.io/v1beta1
kind: DestinationRule
metadata:
  creationTimestamp: "2020-11-04T01:21:07Z"
  generation: 1
  managedFields:
  - apiVersion: networking.istio.io/v1alpha3
    fieldsType: FieldsV1
    fieldsV1:
      f:spec:
        .: {}
        f:host: {}
        f:subsets: {}
        f:trafficPolicy:
          .: {}
          f:connectionPool:
            .: {}
            f:http:
              .: {}
              f:http1MaxPendingRequests: {}
            f:tcp:
              .: {}
              f:connectTimeout: {}
              f:maxConnections: {}
          f:loadBalancer:
            .: {}
            f:simple: {}
          f:tls:
            .: {}
            f:mode: {}
    manager: solitaire-prod-linux
    operation: Update
    time: "2020-11-04T01:21:07Z"
  name: keerthg-test-card-9-v1
  namespace: default
  resourceVersion: "9964"
  selfLink: /apis/networking.istio.io/v1beta1/namespaces/default/destinationrules/keerthg-test-card-9-v1
  uid: 5a1b45c5-3dad-4253-985c-0180048a7a0e
spec:
  host: keerthg-test-card-9-v1
  subsets:
  - labels:
      version: v1
    name: v1
  trafficPolicy:
    connectionPool:
      http:
        http1MaxPendingRequests: 8
      tcp:
        connectTimeout: 0.100s
        maxConnections: 16
    loadBalancer:
      simple: LEAST_CONN
    tls:
      mode: ISTIO_MUTUAL

VirtualService:
$ kubectl get virtualservice keerthg-test-card-9-v1 -o yaml
apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
  creationTimestamp: "2020-11-04T01:21:07Z"
  generation: 1
  managedFields:
  - apiVersion: networking.istio.io/v1alpha3
    fieldsType: FieldsV1
    fieldsV1:
      f:spec:
        .: {}
        f:gateways: {}
        f:hosts: {}
        f:http: {}
    manager: solitaire-prod-linux
    operation: Update
    time: "2020-11-04T01:21:07Z"
  name: keerthg-test-card-9-v1
  namespace: default
  resourceVersion: "9963"
  selfLink: /apis/networking.istio.io/v1beta1/namespaces/default/virtualservices/keerthg-test-card-9-v1
  uid: c40dc3dc-c126-47b8-a197-c3da1c50bf21
spec:
  gateways:
  - httpsingressgateway.istio-system.svc.cluster.local
  hosts:
  - keerthg-test-card-9-v1.devo.us-west-2.testing.aaa.com
  http:
  - route:
    - destination:
        host: keerthg-test-card-9-v1
        port:
          number: 8080
        subset: v1

I am pretty sure this is fixed by https://github.com/istio/istio/pull/28273
As a temporary workaround until that is shipped you can remove destination-rule/originate-tls-for-aaaa-api

Oh that just merged. You can find info about running pre-release builds at https://github.com/istio/istio/wiki/Dev Builds if you want to try it out or wait 1-2 weeks for the release

#28273

I removed destination-rule/originate-tls-for-aaaa-api and it works. We need this destinationrule for external calls and we cannot leave it, Any workaround? Removing tls from destination rule avoids the issue?
When will be next istio release with fix?

One more question: We also have error logs in ingressgateway pods for DestinationRule certificate error as it cant find secret of DestinationRule certificate. is this also related to https://github.com/istio/istio/pull/28273
Error:
2020-10-21T07:19:21.297898Z    info    sds    resource:aaaa-ca-certs-cacert new connection 2020-10-21T07:19:21.301919Z    warn    secretfetcher    Cannot find secret aaaa-ca-certs-cacert, searching for fallback secret gateway-fallback 2020-10-21T07:19:21.301940Z    error    secretfetcher    cannot find secret aaaa-ca-certs-cacert and cannot find fallback secret gateway-fallback 2020-10-21T07:19:21.301946Z    warn    cache    resource:aaaa-ca-certs-cacert SecretFetcher cannot find secret aaaa-ca-certs-cacert from cache 2020-10-21T07:19:21.301958Z    warn    sds    resource:aaaa-ca-certs-cacert waiting for gateway secret for proxy

it is the caCertitficate part that breaks it. release should be out in 1-2
weeks.
On Wed, Nov 4, 2020 at 10:30 AM keerthig9 notifications@github.com wrote:

#28273 https://github.com/istio/istio/pull/28273
I removed destination-rule/originate-tls-for-aaaa-api and it works. We
need this destinationrule for external calls and we cannot leave it, Any
workaround? Removing tls from destination rule avoids the issue?
When will be next istio release with fix?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/istio/istio/issues/28493#issuecomment-721899989, or
unsubscribe
https://github.com/notifications/unsubscribe-auth/AAEYGXJZFZ6IEDJYCILIO3LSOGMTBANCNFSM4TH2H2OQ
.

One more question: We also have error logs in ingressgateway pods for DestinationRule certificate error as it cant find secret of DestinationRule certificate. is this also related to #28273
Error:

2020-10-21T07:19:21.297898Z info sds resource:aaaa-ca-certs-cacert new connection
2020-10-21T07:19:21.301919Z warn secretfetcher Cannot find secret aaaa-ca-certs-cacert, searching for fallback secret gateway-fallback
2020-10-21T07:19:21.301940Z error secretfetcher cannot find secret aaaa-ca-certs-cacert and cannot find fallback secret gateway-fallback
2020-10-21T07:19:21.301946Z warn cache resource:aaaa-ca-certs-cacert SecretFetcher cannot find secret aaaa-ca-certs-cacert from cache
2020-10-21T07:19:21.301958Z warn sds resource:aaaa-ca-certs-cacert waiting for gateway secret for proxy`

Can you please check this?

Closing this as the original issue is fixed now in the new release.
@keerthig9 this means the Secret doesn't exist, please see https://istio.io/latest/docs/tasks/traffic-management/ingress/secure-ingress/


text:
Istio egress gateway with SNI-proxy with routing settings in one namespace seems to be applying for other namespaces as well

(NOTE: This is used to report product bugs:
To report a security vulnerability, please visit https://istio.io/about/security-vulnerabilities
To ask questions about how to use Istio, please visit https://discuss.istio.io)
Bug description
[ ] Docs
[ ] Installation
[X ] Networking
[ ] Performance and Scalability
[ ] Extensions and Telemetry
[ ] Security
[ ] Test and Release
[ ] User Experience
[ ] Developer Infrastructure
[ ] Upgrade
Expected behavior
I have followed the steps mentioned here https://istio.io/latest/docs/tasks/traffic-management/egress/wildcard-egress-hosts/#wildcard-configuration-for-arbitrary-domains to deploy egress gateway and route https traffic for wildcard domains in one namespace, say dev.
Steps to reproduce the bug
Install istio with egress gateway by following steps mentioned here https://istio.io/latest/docs/tasks/traffic-management/egress/wildcard-egress-hosts/#wildcard-configuration-for-arbitrary-domains
Below is the IstioOperator template used:
apiVersion: install.istio.io/v1alpha1
kind: IstioOperator
spec:
  profile: default
  values:
    global:
      configValidation: true
      proxy:
        autoInject: enabled
    gateways:
      istio-egressgateway:
        runAsRoot: true
      istio-ingressgateway:
        runAsRoot: true
  components:
    ingressGateways:
      - name: istio-ingressgateway
        enabled: true
        k8s:
          overlays:
            - kind: Service
              name: istio-ingressgateway
              patches:
                - path: spec.ports[80]
                  value:
                    name: grpc-port
                    port: 9000
                    protocol: TCP
                    targetPort: 9000
                - path: spec.ports[90]
                  value:
                    name: http-health
                    port: 9001
                    protocol: TCP
                    targetPort: 9001
    egressGateways:
      - name: istio-egressgateway-with-sni-proxy
        enabled: true
        label:
          app: istio-egressgateway-with-sni-proxy
          istio: egressgateway-with-sni-proxy
        k8s:
          service:
            ports:
            - port: 443
              name: https
          overlays:
          - kind: Deployment
            name: istio-egressgateway-with-sni-proxy
            patches:
            - path: spec.template.spec.containers[-1]
              value: |
                name: sni-proxy
                image: nginx
                resources:
                  limits:
                    cpu: "2"
                    memory: 1Gi
                  requests:
                    cpu: 100m
                    memory: 128Mi
                volumeMounts:
                - name: sni-proxy-config
                  mountPath: /etc/nginx
                  readOnly: true
                securityContext:
                  runAsNonRoot: false
                  runAsUser: 0
            - path: spec.template.spec.volumes[-1]
              value: |
                name: sni-proxy-config
                configMap:
                  name: egress-sni-proxy-configmap
                  defaultMode: 292 # 0444

Install all the components required for istio to route traffic via egress gateway only in the dev namespace, below are the manifests:
kubectl apply -n dev -f - <<EOF
apiVersion: networking.istio.io/v1alpha3
kind: ServiceEntry
metadata:
  name: sni-proxy
spec:
  hosts:
  - sni-proxy.local
  location: MESH_EXTERNAL
  ports:
  - number: 8443
    name: tcp
    protocol: TCP
  resolution: STATIC
  endpoints:
  - address: 127.0.0.1
---
apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
  name: disable-mtls-for-sni-proxy
spec:
  host: sni-proxy.local
  trafficPolicy:
    tls:
      mode: DISABLE
EOF

cat <<EOF | kubectl -n dev create -f -
apiVersion: networking.istio.io/v1alpha3
kind: ServiceEntry
metadata:
  name: wikipedia
spec:
  hosts:
  - "*.org"
  - "*.com"
  - "*.net"
  - "*.io"
  ports:
  - number: 443
    name: tls
    protocol: TLS
EOF

kubectl apply -n dev -f - <<EOF
apiVersion: networking.istio.io/v1alpha3
kind: Gateway
metadata:
  name: istio-egressgateway-with-sni-proxy
spec:
  selector:
    istio: egressgateway-with-sni-proxy
  servers:
  - port:
      number: 443
      name: tls-egress
      protocol: TLS
    hosts:
    - "*.org"
    - "*.com"
    - "*.net"
    - "*.io"
    tls:
      mode: ISTIO_MUTUAL
---
apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
  name: egressgateway-for-wikipedia
spec:
  host: istio-egressgateway-with-sni-proxy.istio-system.svc.cluster.local
  subsets:
    - name: wikipedia
      trafficPolicy:
        loadBalancer:
          simple: ROUND_ROBIN
        portLevelSettings:
        - port:
            number: 443
          tls:
            mode: ISTIO_MUTUAL
---
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: direct-wikipedia-through-egress-gateway
spec:
  hosts:
  - "*.org"
  - "*.com"
  - "*.net"
  - "*.io"
  gateways:
  - mesh
  - istio-egressgateway-with-sni-proxy
  tls:
  - match:
    - gateways:
      - mesh
      port: 443
      sniHosts:
      - "*.org"
      - "*.com"
      - "*.net"
      - "*.io"
    route:
    - destination:
        host: istio-egressgateway-with-sni-proxy.istio-system.svc.cluster.local
        subset: wikipedia
        port:
          number: 443
      weight: 100
  tcp:
  - match:
    - gateways:
      - istio-egressgateway-with-sni-proxy
      port: 443
    route:
    - destination:
        host: sni-proxy.local
        port:
          number: 8443
      weight: 100
---
# The following filter is used to forward the original SNI (sent by the application) as the SNI of the
# mutual TLS connection.
# The forwarded SNI will be will be used to enforce policies based on the original SNI value.
apiVersion: networking.istio.io/v1alpha3
kind: EnvoyFilter
metadata:
  name: forward-downstream-sni
spec:
  configPatches:
  - applyTo: NETWORK_FILTER
    match:
      context: SIDECAR_OUTBOUND
      listener:
        portNumber: 443
        filterChain:
          filter:
            name: istio.stats
    patch:
      operation: INSERT_BEFORE
      value:
         name: forward_downstream_sni
         config: {}
EOF

Launching a pod in dev namespace works as expected and I am able to see the logs in egress-gateway sni-proxy pod.
Now when I create a pod in another namespace and try to access any https endpoint, it fails.
If I want the https traffic to work in the another namespace, then I will have to add all the above resources there to route traffic via egress gateway.
Version (include the output of istioctl version --remote and kubectl version --short and helm version --short if you used Helm)
$ istioctl version --remote
client version: 1.7.4
control plane version: 1.8.1
data plane version: 1.8.1 (49 proxies)`

$ kubectl version --short
Client Version: v1.19.3
Server Version: v1.18.9-eks-d1db3c

How was Istio installed?
istio was installed using istioctl
Environment where the bug was observed (cloud vendor, OS, etc)
on Amazon EKS 1.18
Additionally, please consider running istioctl bug-report and attach the generated cluster-state tarball to this issue.
Refer cluster state archive for more details.

Is anyone able to help with this? Thanks!


text:
Should the ztunnel DaemonSet have priorityClassName: system-node-critical?

Describe the feature request
The HelmChart for deploying ztunnel does not explicity set the priorityClassName, nor does it offer a setting in the template to set the value.  The istio-cni chart explicitly sets the priorityClassName here: https://github.com/istio/istio/blob/61ed8d599a84ff458a334479cd9dddeb61c52ebd/manifests/charts/istio-cni/templates/daemonset.yaml#L62
I would think that the ztunnel DaemonSet should also be classified as system-node-critical
Without this, when you try to deploy or upgrade ztunnel, pods can get stuck in Pending status with a message like '0/8 nodes are available: 1 Insufficient memory. preemption: 0/8 nodes are available: 8 No preemption victims found for incoming pod..'.  Setting the higher priority will ensure that ztunnel runs on all nodes.
Describe alternatives you've considered
I can set this value with a kustomization process on the helm chart, but I think that system-node-critical should be the default or only possibility, like the istio-cni DaemonSet.
Affected product area (please put an X in all that apply)
[X ] Ambient
[ ] Docs
[ ] Dual Stack
[X ] Installation
[ ] Networking
[ ] Performance and Scalability
[ ] Extensions and Telemetry
[ ] Security
[ ] Test and Release
[X ] User Experience
[ ] Developer Infrastructure
Affected features (please put an X in all that apply)
[ ] Multi Cluster
[ ] Virtual Machine
[ ] Multi Control Plane
Additional context
This is a very easy PR to submit, which I can do, but I wanted to see if there was a good reason this should not be the default.

remember this was discussed somewhere before.  @costinm

I did search for this in issues and I couldn't find anything related to the ztunnel chart.  I do see requests for setting this in other charts and it has been added as an option to the gateway chart.

IMO, Ztunnel should be put higher priority than gateway

Agreed - CNI and ztunnel should both be critical.
Unpopular opinion: CNI and ztunnel should also be in the same helm chart ( popular opinion seems to be that
ztunnel should be implemented by the CNI layer directly - but for some reason us having a single helm chart for both
is not ok )

Note I didn't say 'same helm daemon set', as 2 separate containers - which would likely be even less popular - but how a native CNI implementation would likely do it ...

I created a PR for this change (linked above).  I am waiting for our Security Chief to approve our CLA when she gets back from Thanksgiving vacation.

fixed by https://github.com/istio/istio/issues/47867

authors: RobCannon costinm hzxuzhonghu zirain


text:
Services with sidecar cannot talk to services without sidecar when mTLS is globally turned on

Before customer installing istio sidecar, we have a svc A talking to svc B via http.
However, if we install sidecar for svc A, and mTLS is turned on globally, i.e., by running istio-auth.yaml in this page: https://istio.io/docs/setup/kubernetes/quick-start.html#installation-steps. Then svc A cannot talk to svc B any more. Because svc A always sends https traffic while svc B expects http traffic.
The idea is when pilot constructs CDS, if mTLS is turned on globally, we always add ssl_context (v1 api)/tls_context (v2 api) to it, no matter whether the upstream service has sidecar or not. This is a bug when upstream service does not have sidecar.

Thanks Tao, this sounds reasonable.  What is the rough time frame for this?

I am talking with Networking team for support, i.e., we need to know whether the upstream has sidecar.

After chatting with @louiscryan , it seems this is pretty expensive to detect whether the other side has sidecar. He will add more context in this issue.

we're going to have this issue with mesh expansion and other situations where endpoints are registered but we don't know or control how they are registered. I'm wary of depending on Envoy to effectively register an endpoint for a service in the near term. This issue is exacerbated by folks directly creating ServiceEntry resources.
DestinationRule controls how a service is connected to at this layer and AuthorizationPolicy dictates what a service endpoint implements. The flag mentioned above controls global enablement of mTLS and is risky to use in existing clusters where the operator hasn't validated proper migration, i.e its really only safe to use for new clusters.
For folks incrementally rolling out mTLS they should use a combination of AuthorizationPolicy and DestRule to control the migration. AuthPolicy can declare that an endpoint accepts mTLS or Plaintext, then DestRule is updated to require mTLS when reaching that endpoint, then AuthPolicy can be updated to require mTLS once the metrics show that there is no Plaintext traffic.

@louiscryan just to make sure we are on the same page... Let's say I have a simple guestbook app that has 2 services (A and B).  I'm moving A to the istio mesh and B continues to run in the same k8s cluster.  A (with envoy side car) calls B (no envoy).  Can you apply AuthorizationPolicy for service B effectively when service B doesn't have side car?    Or are you suggesting using the new Auth policy to disable mTLS for the namespace X that A is deployed to?   And once service B is also moved to the mesh with service A, then user can 1)  test require mTLS among A and B using dest rule 2) enable mTLS for namespace X using Auth policy.
Essentially, user needs to turn off the mTLS globally for the mesh prior to 0.8... with 0.8, this is nicer because users can turn it on or off per namespace via the new AuthPolicy.

@incfly @diemtvu

For B (no envoy) we can't apply authorization policy or MTLS. What we can
do is set a DestinationPolicy
that configures 'no tls' for connections from A to B.
In 0.8 user should be able to turn on/off MTLS explicitly via
DestinationPolicy, per service (envoy-cluster or hostname).
The default helm templates are set with global MTLS off - we still ship the
'demo' istio-auth.yaml, but we expect
most users will use 'helm template' or 'helm' instead, so at install or
update they can set the global MTLS policy,
and to use DestinationPolicy to fine tune it.
On Mon, Apr 30, 2018 at 6:33 PM, Lin Sun notifications@github.com wrote:

@louiscryan https://github.com/louiscryan just to make sure we are on
the same page... Let's say I have a simple guestbook app that has 2
services (A and B). I'm moving A to the istio mesh and B continues to run
in the same k8s cluster. A (with envoy side car) calls B (no envoy). Can
you apply AuthorizationPolicy for service B effectively when service B
doesn't have side car? Or are you suggesting using the new Auth policy to
disable mTLS for the namespace X that A is deployed to? And once service B
is also moved to the mesh with service A, then user can 1) test require
mTLS among A and B using dest rule 2) enable mTLS for namespace X using
Auth policy.
Essentially, user needs to turn off the mTLS globally for the mesh prior
to 0.8... with 0.8, this is nicer because users can turn it on or off per
namespace via the new AuthPolicy.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/istio/istio/issues/5296#issuecomment-385577408, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AAFI6iKv-BXwG3vUn19odsZTi-fyz4iFks5tt7t_gaJpZM4Ts63E
.

There is another strange interaction here - if they are migrating from 0.7
to 0.8/alpha3.
In this case I'm not sure what should happen - in 0.7 we used some service
annotations
to disable mtls for some services. I assume users will keep them while they
upgrade to 0.8,
and create equivalent DestinationPolicy.
On Tue, May 1, 2018 at 4:31 PM, Costin Manolache costin@gmail.com wrote:

For B (no envoy) we can't apply authorization policy or MTLS. What we can
do is set a DestinationPolicy
that configures 'no tls' for connections from A to B.
In 0.8 user should be able to turn on/off MTLS explicitly via
DestinationPolicy, per service (envoy-cluster or hostname).
The default helm templates are set with global MTLS off - we still ship
the 'demo' istio-auth.yaml, but we expect
most users will use 'helm template' or 'helm' instead, so at install or
update they can set the global MTLS policy,
and to use DestinationPolicy to fine tune it.
On Mon, Apr 30, 2018 at 6:33 PM, Lin Sun notifications@github.com wrote:

@louiscryan https://github.com/louiscryan just to make sure we are on
the same page... Let's say I have a simple guestbook app that has 2
services (A and B). I'm moving A to the istio mesh and B continues to run
in the same k8s cluster. A (with envoy side car) calls B (no envoy). Can
you apply AuthorizationPolicy for service B effectively when service B
doesn't have side car? Or are you suggesting using the new Auth policy to
disable mTLS for the namespace X that A is deployed to? And once service B
is also moved to the mesh with service A, then user can 1) test require
mTLS among A and B using dest rule 2) enable mTLS for namespace X using
Auth policy.
Essentially, user needs to turn off the mTLS globally for the mesh prior
to 0.8... with 0.8, this is nicer because users can turn it on or off per
namespace via the new AuthPolicy.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/istio/istio/issues/5296#issuecomment-385577408, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AAFI6iKv-BXwG3vUn19odsZTi-fyz4iFks5tt7t_gaJpZM4Ts63E
.

@costinm @wattli would the service annotation in 0.7 continue to work in 0.8?   It would not be obvious to user to change the service annotation to destinationpolicy as service annotation is at the service yaml today in 0.7. cc @esnible

authors: costinm linsun louiscryan wattli


text:
[pilot] Export virtual service and destination rule metadata

Added some unit test coverage to #11060 (big thanks to @rshriram for doing the hard work).
This PR adds virtual service and destination rule metadata to generated Envoy config. This should enable mixer client to retrieve this information and use it to create appropriate attributes.
This is targeted at release-1.1 as the original PR was as well.  The diff can easily be applied to master if that is more appropriate.
Manually verified with bookinfo in example cluster (snippets):
{
     "cluster": {
      "name": "outbound|9080|details-abort-dr-subset-v1|details.default.svc.cluster.local",
      },
      "metadata": {
       "filter_metadata": {
        "istio": {
         "destination-rule": "details-abort-dr.default.cluster.local"
        }
       }
      },
},

{
      "route_config": {
          "metadata": {
           "filter_metadata": {
            "istio": {
             "virtual-service": "details-abort-vs.default.cluster.local"
            }
           }
     },
}

@wenchenglu can we merge this PR into release-1.1?


text:
Changing sha for proxy in istio/istio.deps

For release 1.1

[APPROVALNOTIFIER] This PR is NOT APPROVED
This pull-request has been approved by: utka
To fully approve this pull request, please assign additional approvers.
We suggest the following additional approver: linsun
If they are not already assigned, you can assign the PR to them by writing /assign @linsun in a comment when ready.
The full list of commands accepted by this bot can be found here.
The pull request process is described here

Needs approval from an approver in each of these files:

OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

@utka: The following test failed, say /retest to rerun them all:

Test name
Commit
Details
Rerun command

prow/istio-integ-k8s-tests.sh
bd37f29a743919720d105ecef56ba6a4f34e886f
link
/test istio-integ-k8s-tests

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.

@utka: The following tests failed, say /retest to rerun them all:

Test name
Commit
Details
Rerun command

prow/istio-integ-k8s-tests.sh
bd37f29a743919720d105ecef56ba6a4f34e886f
link
/test istio-integ-k8s-tests

prow/istio-pilot-multicluster-e2e.sh
bd37f29a743919720d105ecef56ba6a4f34e886f
link
/test istio-pilot-multicluster-e2e

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.

authors: istio-testing utka


text:
update go control plane to v0.8.6 and istio/api to the latest

Please provide a description for what this PR is for.
And to help us figure out who should review this PR, please
put an X in all the areas that this PR affects.
[ ] Configuration Infrastructure
[ ] Docs
[ ] Installation
[ ] Networking
[ ] Performance and Scalability
[ ] Policies and Telemetry
[ ] Security
[ ] Test and Release
[ ] User Experience
[ ] Developer Infrastructure

@crazyxy: The following test failed, say /retest to rerun them all:

Test name
Commit
Details
Rerun command

integ-new-install-k8s-presubmit-tests-master
26a95dfceb5a147263bfc8c8ed829920f80c7265
link
/test integ-new-install-k8s-presubmit-tests-master

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.

@crazyxy: The following test failed, say /retest to rerun them all:

Test name
Commit
Details
Rerun command

integ-new-install-k8s-presubmit-tests-master
0b127a4f9551001a11ca36a266b2a7d6668c176a
link
/test integ-new-install-k8s-presubmit-tests-master

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.

@crazyxy: The following tests failed, say /retest to rerun them all:

Test name
Commit
Details
Rerun command

integ-new-install-k8s-presubmit-tests-master
0b127a4f9551001a11ca36a266b2a7d6668c176a
link
/test integ-new-install-k8s-presubmit-tests-master

istio-racetest-master
0b127a4f9551001a11ca36a266b2a7d6668c176a
link
/test istio-racetest-master

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.

/test istio-racetest-master

@crazyxy: The following tests failed, say /retest to rerun them all:

Test name
Commit
Details
Rerun command

integ-new-install-k8s-presubmit-tests-master
0b127a4f9551001a11ca36a266b2a7d6668c176a
link
/test integ-new-install-k8s-presubmit-tests-master

istio-racetest-master
0b127a4f9551001a11ca36a266b2a7d6668c176a
link
/test istio-racetest-master

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.

/test istio-racetest-master

@crazyxy: The following tests failed, say /retest to rerun them all:

Test name
Commit
Details
Rerun command

integ-new-install-k8s-presubmit-tests-master
0b127a4f9551001a11ca36a266b2a7d6668c176a
link
/test integ-new-install-k8s-presubmit-tests-master

istio-racetest-master
0b127a4f9551001a11ca36a266b2a7d6668c176a
link
/test istio-racetest-master

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.

@crazyxy: The following tests failed, say /retest to rerun them all:

Test name
Commit
Details
Rerun command

istio-racetest-master
0b127a4f9551001a11ca36a266b2a7d6668c176a
link
/test istio-racetest-master

integ-new-install-k8s-presubmit-tests-master
bf2c6f9d16ccdbe379e0ad3c6c34383ef3c58b9e
link
/test integ-new-install-k8s-presubmit-tests-master

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.

authors: crazyxy istio-testing


text:
Use k8s.io/apimachinery yaml decoder in kubesource

Previously we used our own library for splitting multipart documents, but it had a bug (#18998). To avoid this in the future we now use the same decoder used by the k8s project.

In response to a cherrypick label: new pull request created: #19048

authors: istio-testing selmanj