Secret skupper-local-client can no longer be used to establish router connections from the Rhea library

[ted-ross]

If my pod mounts the skupper-local-client secret as /etc/messaging, Rhea-based JS apps can no longer connect to the router. This worked in previous releases. Broken in 1.0.1

[grs]

What is the error and what is the content of the /etc/messaging/connect.json?

[ted-ross]

connect.json:

{
    "scheme": "amqps",
    "host": "skupper-local-client.default.svc.cluster.local",
    "port": "5671",
    "tls": {
        "ca": "/etc/messaging/ca.crt",
        "cert": "/etc/messaging/tls.crt",
        "key": "/etc/messaging/tls.key",
        "verify": true
    }
}

[ted-ross]

Error server side:
SERVER (info) [C48] Connection from 172.17.0.1:5245 (to :5671) failed: amqp:connection:framing-error SSL Failure: error:14094410:SSL routines:ssl3_read_bytes:sslv3 alert handshake failure

Error client side:
'SSL Failure: error:0A000086:SSL routines::certificate verify failed'

[ted-ross]

If I replace the host with skupper-router-local, I can get a good connection. It appears that the content of connect.json no longer matches the Kubernetes service name.

[ted-ross]

Note: Those errors came from a test I tried using skstat and an /etc/hosts entry for the hostname in connect.json. When using a Rhea-based client inside the namespace, there are no errors logged. This is probably due to the failure of the name to resolve to an IP address.

[ted-ross]

Here are the services in my namespace:

$ kubectl get services
NAME                   TYPE           CLUSTER-IP       EXTERNAL-IP      PORT(S)                           AGE
kubernetes             ClusterIP      10.96.0.1        <none>           443/TCP                           4d1h
skupper                LoadBalancer   10.104.101.51    10.104.101.51    8080:30918/TCP,8081:30583/TCP     133m
skupper-router         LoadBalancer   10.109.121.245   10.109.121.245   55671:32186/TCP,45671:32257/TCP   133m
skupper-router-local   ClusterIP      10.107.132.117   <none>           5671/TCP                          133m

[ted-ross]

It appears that the FQDN in the connect.json host field is constructed from the secret name, not the service name.

[ted-ross]

#786 fixes this issue.