This message was deleted.

there are many reasons: 1) if you specify trustcertfile in client, the client will not use the builtin root ca. 2) some OS (debian) will need ca-certificates packages. You can try openssl s_client -connect -show-cert proxy.xyz.com:6651 to check if the cert is verified or not.

what is the recommended approach for hostname verification of brokers? 1. Can I use externaldns or ingress to assign dns domain to brokers for tls? 2. Give proxy tls cert and use cross-cert with internal dns broker name like pulsar-broker.pulsar-broker.pulsar.svc.cluster.local

let istio handle mTLS and ingress gateway to handle tls termination.

Right, I've noticed that as well. I think even for small cluster istio the way to go for this. If you have any reference for implementation I'd appreciate it greatly.

mtls means (server to server authentication, zk to zk, broker to zk, broker to broker, bookie to zk and broker to bookie). what you want under istio term is “user authentication” and istio doesn’t support tls authentication. you have to use token based authentication like oidc, oauth2 or jwt for client authentication.

Yes I'll use oauth2 (auth0) for user authentication and istio for tls encryption of messages (proxy to broker, function to broker, client to proxy) client facing applications and managing certificates correct?

if you want pulsar tls authx in k8s, you can use proxy without istio. if you have istio, you don’t need pulsar-proxy.

I understand, as the client would connect to ingress component of istio rather than proxy