admin管理员组

文章数量:1401273

I am using STRICT peerauthetication model for ALL Pods in my default namespace. Also, ISTIO_MUTUAL destinationRule is ON for default namespace pods.

When peerauthentication is PERMISSIVE, curl from host VM to zookeeper is:

user@host:~$ curl -k -v -L 10.103.19.172:2181

  • Trying 10.103.19.172:2181...
  • TCP_NODELAY set
  • Connected to 10.103.19.172 (10.103.19.172) port 2181 (#0)

GET / HTTP/1.1 Host: 10.103.19.172:2181 User-Agent: curl/7.68.0 Accept: /

  • Empty reply from server
  • Connection #0 to host 10.103.19.172 left intact curl: (52) Empty reply from server user@host:~$

(Same happens fro kafka to zookeeper)- all good.

When it is STRICT:

user@host:~$ curl -k -v -L 10.103.19.172:2181

  • Trying 10.103.19.172:2181...
  • TCP_NODELAY set
  • Connected to 10.103.19.172 (10.103.19.172) port 2181 (#0)

GET / HTTP/1.1 Host: 10.103.19.172:2181 User-Agent: curl/7.68.0 Accept: /

  • Recv failure: Connection reset by peer
  • Closing connection 0 curl: (56) Recv failure: Connection reset by peer user@host:~$

I am using STRICT peerauthetication model for ALL Pods in my default namespace. Also, ISTIO_MUTUAL destinationRule is ON for default namespace pods.

When peerauthentication is PERMISSIVE, curl from host VM to zookeeper is:

user@host:~$ curl -k -v -L 10.103.19.172:2181

  • Trying 10.103.19.172:2181...
  • TCP_NODELAY set
  • Connected to 10.103.19.172 (10.103.19.172) port 2181 (#0)

GET / HTTP/1.1 Host: 10.103.19.172:2181 User-Agent: curl/7.68.0 Accept: /

  • Empty reply from server
  • Connection #0 to host 10.103.19.172 left intact curl: (52) Empty reply from server user@host:~$

(Same happens fro kafka to zookeeper)- all good.

When it is STRICT:

user@host:~$ curl -k -v -L 10.103.19.172:2181

  • Trying 10.103.19.172:2181...
  • TCP_NODELAY set
  • Connected to 10.103.19.172 (10.103.19.172) port 2181 (#0)

GET / HTTP/1.1 Host: 10.103.19.172:2181 User-Agent: curl/7.68.0 Accept: /

  • Recv failure: Connection reset by peer
  • Closing connection 0 curl: (56) Recv failure: Connection reset by peer user@host:~$
  • kubernetes
  • curl
  • istio
  • istio-sidecar
  • istio-kiali
Share Improve this question asked Mar 25 at 6:07 MadhusoodanMadhusoodan 6081 gold badge7 silver badges20 bronze badges 1
  • I have changed my answer can you please have a look at this now and let me know if you need any further assistance, I will be happy to assist you. – Imran Premnawaz Commented Mar 27 at 3:50
Add a comment  | 

2 Answers 2

Reset to default 0

If you are seeing "connection reset by peer" errors, it could be due to the client not having the correct mTLS certificates or the server not expecting mTLS traffic.

If the zookeeper is the external service , you should configure Istio to allow the non-mTLS traffic for that specific service. And you can do this by creating an Istio PeerAuthentication and DestinationRule that disables mTLS for traffic between the host VM and zookeeper. Refer to this documentation for more information on this.

Also you will need to create a client certificate for the host VM to authenticate itself with Istio’s mTLS. You can use Istio’s certificate authority to generate client certificates for your VM and configure curl to use that certificate.

You can verify your mTLS status between host VM and zookeeper as mentioned below,

Istiocl authn tls-check
<zookeeper-service-name>.<namespace>.svc.cluster.local

Refer to this documentation to know more about how to configure and how to use Istio authentication policies.

Fixed it. See the question I posted at https://istio.slack/archives/C37A4KAAD/p1743157328271189

--set values.pilot.env.ENABLE_NATIVE_SIDECARS=true fixes it.

SO my istioctl command was:

istioctl install \
  --set meshConfig.defaultConfig.holdApplicationUntilProxyStarts=true \
  --set meshConfig.defaultConfig.proxyMetadata.REWRITE_PROBE_LEGACY_LOCALHOST_DESTINATION=true \
  --set meshConfig.defaultConfig.proxyMetadata.ISTIO_META_REWRITE_APP_HTTP_PROBERS=true \
  --set components.cni.enabled=true \
  --set values.pilot.env.ENABLE_NATIVE_SIDECARS=true \
  --set values.pilot.env.ENABLE_TLS_ON_SIDECAR_INGRESS=true

本文标签：

版权声明：本文标题：kubernetes - Issues with istio-proxy to apps communication while using STRICT peerauthentication with MUTUAL_TLS destinationrule 内容由网友自发贡献，该文观点仅代表作者本人， 转载请联系作者并注明出处：http://www.betaflare.com/web/1744214982a2595594.html， 本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌抄袭侵权/违法违规的内容，一经查实，本站将立刻删除。