I've setup the following infrastructure in AKS / K8s
A. What does the CA provide besides an SSL connection between the device and the termination. It seems that the device that is using the mqtts:// endpoint is simply sending traffic to a load balancer that can verify the certificate.
B. In this stack the person is asking about using a client cert and verification at termination Which can be verified at the load balancer with the following annotations. I guess in this way, a (client-cert) will be checked at the load balancer.
This is illustrated in NGNIX
nginx.ingress.kubernetes.io/auth-tls-verify-client: "on"
nginx.ingress.kubernetes.io/auth-tls-secret: "default/mycerts"
Is this needed or will a simple CA cert do?
It is both ways because the broker is not going to send anything that is not CA based and the client can't send anything that isn't CA based.
I don't see why putting a client cert on the device/service and checking that at termination is useful beyond what the CA cert is already doing based on the actual URI.
In answer the person states:
The only thing is that your requests will not be verified but your client/browser unless the CA (Certificate Authority) is added as a trusted entity.
Here is the confusing part in the very next sentence:
Now with respect to mTLS you don't necessarily care if you use exactly the same CA, Cert, and Key to authenticate both ways. However, you would have to force your ingress to authenticate the client and with the Nginx ingress controller you can do it with these annotations:
Does this mean I would want to take my CA cert that is on the load balancer and put it on the client. Again, what does that do beyond the URI in the first place? It will be the same cert on all devices hence the URI.
In my opinion CA plus username and password auth is the best solution but not sure if I am missing something here and what is gold standard of this approach.