0

I have a Service "service1" in Namespace "a" which is part of the Istio Servicemesh and has both REGISTRY_ONLY configured in the Sidecar as well as Strict mTLS configured in the PeerAuthentication.

Inside the Cluster there exists another ClusterIP Service "service2" in Namespace "b" (service2.b.svc.cluster.local) backed by Pods that is not part of the Mesh (No Sidecars/Configs/etc.). I do not have access to view or edit things in Namespace "b".

Service "service1" needs to call Service "service2" but the calls are routed to BlackHoleCluster according to the Logs of the Sidecar. How do i enable this communication?

[2023-06-13T12:00:00.000Z] "- - -" 0 UH - - "-" 0 0 0 - "-" "-" "-" "-" "-" BlackHoleCluster - 100.52.158.17:443 100.60.22.142:35254 - -

I have tried including the Service inside the Sidecar Configuration but it does not seem to be able to recognize the plain Kubernetes Service.

apiVersion: networking.istio.io/v1beta1
kind: Sidecar
metadata:
  name: default
  namespace: a
spec:
  egress:
    - hosts:
        - ./*
        - b/*
  outboundTrafficPolicy:
    mode: REGISTRY_ONLY

The only way i have found to make it work is to create a ServiceEntry Object that explicitly contains the Services ClusterIP as a VIP-Address. (Does not work without specifying the Address)

apiVersion: networking.istio.io/v1beta1
kind: ServiceEntry
metadata:
  name: se-service2
  namespace: a
spec:
  hosts:
    - service2.b.svc.cluster.local
  addresses:
    - 100.52.158.17 # Assigned ClusterIP of "service2.b.svc.cluster.local" 
  exportTo:
    - .
  location: MESH_EXTERNAL
  ports:
    - name: https
      number: 443
      protocol: HTTPS
  resolution: DNS

Is there a better way to configure this without the explicit ClusterIP? I feel like Istio should be able to use the definition of the Target-Service to figure this out automatically.

TechnicianLP
  • 33
  • 5

1 Answers1

0

You should be able to configure the sidecar of the service1 in ns a to disable mTLS when talking to service in ns b by using a destination rule:

apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
  name: no-mtls
  namespace: a
spec:
  workloadSelector:
    matchLabels:
      service-name: service1 # adjust to match your pod
  host: service2.b.svc.cluster.local
  trafficPolicy:
    tls:
      mode: SIMPLE # or DISABLE
Chris
  • 5,109
  • 3
  • 19
  • 40
  • The Problem is the traffic being routed to BlackHoleCluster. Ive tried your DestinationRule with no noticable difference. – TechnicianLP Jun 13 '23 at 13:09
  • Have you tried to switch the `outboundTrafficPolicy` to verify that it's caused by that? You could also check the proxy config of your pod with `istioctl pc all service1.a`. – Chris Jun 14 '23 at 06:06
  • removing the outboundTrafficPolicy and/or adding the above ServiceEntry does fix the Problem and allow for functional communication. The Main Reason for my question was finding a better solution than adding a ServiceEntry with the explicitly ClusterIP of the Service. – TechnicianLP Jun 14 '23 at 07:44