Support PeerAuthentication.MutualTLS.Mode Strict for RMI connections

[JessHolle]

Is this the right place to submit this?

• This is not a security vulnerability or a crashing bug
• This is not a question about how to use Istio

Bug Description

Our RMI connections are blocked unless we use PeerAuthentication.MutualTLS.Mode Permissive/Disabled.

We want the service mesh to handle MTLS here, so we don't have to do so ourselves -- inclusive of RMI.

Version

kubectl version --short
Flag --short has been deprecated, and will be removed in the future. The --short output will become the default.
Client Version: v1.27.3
Kustomize Version: v5.0.1
Server Version: v1.29.2

istioctl version
client version: 1.19.0
control plane version: 1.19.0
data plane version: 1.19.0 (2 proxies)

Additional Information

No response

[JessHolle]

Or perhaps put another way, Istio's Auto mTLS does not seem to be getting applied to RMI connections...

[keithmattix]

IIUC RMI uses tcp and/or http so it should have auto mTLS applied. Are both Java applications in the mesh?

[JessHolle]

Yes, RMI uses TCP and both Java applications are in the mesh.

[keithmattix]

What address are you using for RMI: a pod ip or a service ip?

[JessHolle]

Service IP.

[keithmattix]

Hmmm I'm not super familiar with Java and RMI; does this issue help? #15293

[JessHolle]

We can look at that issue again. But... RMI does work if we set PeerAuthentication.MutualTLS.Mode to Permissive/Disable.

[keithmattix]

/cc @ramaraochavali @howardjohn any ideas here? Only thing I can thing of is that RMI doesn't like auto tls

[howardjohn]

Not really, this needs more info on what it means to be "blocked". Access logs, etc

Probably it is sending to specific pod IPs instead of service VIPs

[JessHolle]

So... sorry for the noise here, but it turns out there was a port misconfiguration underlying our issues.

Yes, RMI works fine with Istio mTLS -- as expected.

[JessHolle]

Closing this issue as per my previous comment.