How to enable mTLS within two namespaces

[mrueda020]

I have two services in different namespaces let's say namespacea and namespaceb so how can I restrict that only services in namespacea can access to services in namespaceb using an Authz Policy sources with namespaces
I have been following these Authz policy examples

• https://istio.io/latest/docs/ops/configuration/security/security-policy-examples/#namespace-isolation
• https://istio.io/latest/docs/tasks/security/authentication/mtls-migration/
  But stills throws me 403 error since I have checked that the request header from my service on namespacea is missing the x-forwarded-client-cert since ssl is none.

I know within the same namespace the services can communicate using the namespace Authz isolation but if they are in different namespaces I face this issue.
I also have set the DestinationRule for service in namespaceb an set ttls mode ISTIO_MUTUAL and PeerAuthentication for both namespaces are in PERMISSIVE.
So my questions are how to enable the mTLS for both ns?, how can I specify that my service in namespacea has to use mTLS when sending the request to service in namespaceb in other words to send the ssl or the spiffe token
I am using istio on default profile

Update

I have done some testing and notice when I use the service ip or DNS of the service the header is present on the request but if I use the pod ip is not present.
What can cause this problem when using pod ip?

[hzxuzhonghu]

so how can I restrict that only services in namespacea can access to services in namespaceb using an Authz Policy sources with namespaces

You can create authorizationPolicy in namespaceb like this

Please show what is your config look like

[avisaradir]

I applied this authorization policy but I think the issue is on the side of namespace-a.

when Im running curl -v service.namespace.svc.cluster.local Im getting the following error curl: (56) Recv failure: Connection reset by peer and this is the log in the istio proxy

{
    "protocol": null,
    "duration": 0,
    "upstream_transport_failure_reason": null,
    "request_id": null,
    "response_code_details": null,
    "downstream_remote_address": "xx.xx.xx.xx:54000",
    "requested_server_name": null,
    "client_ip": null,
    "authority": null,
    "x_forwarded_for": null,
    "downstream_local_address": "172.20.123.123:3000",
    "route_name": null,
    "upstream_cluster": "BlackHoleCluster",
    "start_time": "2024-06-18T13:47:25.147Z",
    "upstream_service_time": null,
    "method": null,
    "bytes_sent": 0,
    "response_flags": "UH",
    "user_agent": null,
    "response_code": 0,
    "upstream_host": null,
    "bytes_received": 0,
    "upstream_local_address": null,
    "path": null,
 }

Do I need to apply anything on the side of namespace-a?

[howardjohn]

Either you are masking too much info to make it understood, or I think you are hitting #27619. Otherwise. Is 172.20.123.123:3000 the Service IP or the pod ip?

[avisaradir]

Ill clarify somethings, the error im getting is in the pod im running the curl command from.

"downstream_remote_address": "xx.xx.xx.xx:54000" is the curl pods ip.

"downstream_local_address": "172.20.123.123:3000" is the service ip.

#27619 this error doesn't seems to be related, we don't have cilium running on our cluster.

[mrueda020]

Hey @hzxuzhonghu
Thanks for replying
now my issue is that my service uses the pod ip to reach my service in namespaceb but as far I know istio is a service mesh so I am not able to use istio capabilities please note I have sidecar containers on both services , so my question would be is there any way to make istio to integrate pod IP into the mesh?

[rootsongjc]

When you directly use Pod IPs for communication, the traffic might bypass the Istio sidecar, leading to missing Istio headers and mTLS features. Istio operates at the service level and relies on Kubernetes services (and thus DNS) for its traffic management and security features.

Always use Kubernetes DNS names (like service.namespace.svc.cluster.local) instead of direct Pod IPs for communication between services.