0

My use case is the following I want o intercept calls to the LDAP in 172.28.0.3:389 and forward to 172.28.0.3:636 with TLS.

I have followed the steps of egress tls originate and it works fine. Now I am trying to use the gateway, unfortunately I am having problems setting up the ports. I have basically copied and paste the setup of documentation and adapted the protocols from HTTP and HTTPS to TCP and the ports 80 and 443 to 389 and 636 respectively:

    apiVersion: networking.istio.io/v1alpha3
    kind: ServiceEntry
    metadata:
      name: cnn
    spec:
      hosts:
      - ldap.host
      addresses:
      - 172.28.0.3
      ports:
      - number: 389
        name: tcp
        protocol: TCP
      - number: 636
        name: tcp-secure
        protocol: TCP
      resolution: STATIC
      endpoints:
       - address: 172.28.0.3

------ 


apiVersion: networking.istio.io/v1alpha3
kind: Gateway
metadata:
  name: istio-egressgateway
spec:
  selector:
    istio: egressgateway
  servers:
  - port:
      number: 389 # I am not sure about this
      name: tpc-port-for-tls-origination
      protocol: tcp
    hosts:
    - ldap.host
---
apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
  name: egressgateway-for-cnn
spec:
  host: istio-egressgateway.istio-system.svc.cluster.local
  subsets:
  - name: cnn


apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: direct-cnn-through-egress-gateway
spec:
  hosts:
  - ldap.host
  gateways:
  - istio-egressgateway
  - mesh
  tcp: # I AM NOT SURE ABOUT THIS PART
  - match:
    - gateways:
      - mesh
      port: 389
    route:
    - destination:
        host: istio-egressgateway.istio-system.svc.cluster.local
        subset: cnn
        port:
          number: 389
      weight: 100
  - match:
    - gateways:
      - istio-egressgateway
      port: 389
    route:
    - destination:
        host: ldap.host
        port:
          number: 636
      weight: 100
---
apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
  name: originate-tls-for-edition-cnn-com
spec:
  host: ldap.host
  trafficPolicy:
    loadBalancer:
      simple: ROUND_ROBIN
    portLevelSettings:
    - port:
        number: 636
      tls:
        mode: SIMPLE # initiates HTTPS for connections to edition.cnn.com

I have the feeling that the problem is on the VirtualService, however I have tried many things but without success, any hint what might be the issue would be highly appreciated.

Wytrzymały Wiktor
  • 11,492
  • 5
  • 29
  • 37
Learner
  • 29
  • 1
  • 5
  • What do you see in the logs? When debugging this kind of stuff, I usually check the access logs of the sidecar where the request originates and the access logs in the egress gateway: that should give you an idea on which component is giving you issues. Unfortunately I cannot help yet with this specific issue, I'm quite new in setting up egress gateways as well :). – Mark May 16 '21 at 07:57
  • @Mark Thanks for the reply, in my previous question (https://stackoverflow.com/q/67490310/15898429) I had to month the caCertificate inside the pod, but that seems wrong, do you know if there is a way of using caCertificates without having the deploy them inside the application pod? – Learner May 16 '21 at 16:07

1 Answers1

1

Looking into this post and previous post: it looks like you are interested with external custom authentication provider which support LDAP integration. For example you can use keycloak, Auth0, Google Auth.

This documentation shows an external authentication, that it can be integrated with istio. Please note that the documentation may be outdated (02/2018).


Here you can find similar problem:

As far as I'm concerned LDAP is not working in istio. Workaround here would be either keycloak or auth0 You can integrate both of them with istio, but it's just for authentication, It won't work as LDAP itself, at least as far as I know.


You can also eanble authentication with JSON Web Token (JWT) validation. Istio takes care of the task of validating the JWT tokens in the incoming user requests. So if you implement Istio JWT authentication feature, your application code doesn’t need to bother about the JWT token validation. Istio will do it for you. Not JWT token generation. Istio will not generate the tokens for you. You have to have an Authentication micro-service that generates the token. Here is thread on how to authenticate end users using JWT.

Mikołaj Głodziak
  • 4,775
  • 7
  • 28
  • Thanks for your reply, but in my case I already have Keycloak configured, I have the LDAP configured with Keycloak, I just want to move the custom certificate of the LDAP from the Keycloak POD to the istio. I thought I would be able to achieve that with the egressgateway – Learner May 17 '21 at 10:37
  • Look at Egress Gateways with TLS Origination [here](https://www.bookstack.cn/read/istio-1.6-en/241724). I attach you also an [official documentation](https://istio.io/v1.6/docs/tasks/traffic-management/egress/egress-gateway-tls-origination/) – Mikołaj Głodziak May 17 '21 at 10:51
  • thanks :), that is exactly what I did and why I have create this question. – Learner May 17 '21 at 11:12
  • I have read a lot of stuff I still don't get where the caCertificate file has to be presented, POD? istiod ? proxy, I thought was POD but I am wrong – Learner May 17 '21 at 15:42
  • If I good understand your problem, certs should be in the directory: `samples/certs/`. Look [here](https://istio.io/v1.6/docs/tasks/security/cert-management/plugin-ca-cert/) for more information. There is a guide, how to plugin existing certificates. – Mikołaj Głodziak May 18 '21 at 07:11
  • Those are other type of certificates, root ones for the cluster. I end up solving by using TLS origination without gateway, injecting the certificates inside the proxies using istio 1.10 custom injection template feature – Learner May 20 '21 at 20:20