Which channels should use SSL in a Kubernetes cluster?

1
votes

I have the following Kubernetes setup (forgive the poor ASCII art):

Azure SQL DB_1 > deployment_1 > service_1 \
Azure SQL DB_2 > deployment_2 > service_2  > -> nginx_ingress
Azure SQL DB_N > deployment_N > service_N /

The DBs are outside the Kubernetes cluster. They are exposed through a Private Endpoint to the VNet the Kubernetes cluster is on. They obtain a private IP address inside that VNet, and are otherwise unreachable.

Every deployment is a different microservice. Each one has a service in front of it to handle communication. In turn, all these services can be reached through the NGINX ingress. All services are configured as ClusterIPs, so they cannot be reached from outside the cluster. The only entrypoint from outside the VNet is through the ingress.

My question is, which of these channels should be secured with SSL, and where is it not worth it (for example, because of impact on performance)?

  1. The Ingress of course, will have SSL in front of it. This is a given.
  2. Should there be SSL between the ingress and the services?
  3. Should there be SSL between the services and the microservices behind them?
  4. The DB itself seems to already do encrypted connections automatically. Is there any reason why this would be unnecessary, or conversely, can/should it be made more secure somehow?

Of course, I understand that more encryption is usually A Good Thing. But for example, is it worth generating and keeping track of certificates for comms between the microservices and the services, since these are internal to the cluster and cannot be reached in any other way?

Thank you for any information / examples / experiences you can provide!

1
sslkubernetesmicroserviceskubernetes-ingress

1 Answers

3
votes

simple is to terminate the TLS at ingress layer only, as it is inside AKS ( I am assuming ) and AKS' VNET is secure, so no direct exposure to external world and only ingress nginx controller will be exposed to external world.

The DB based communication , if you are using SQL server , then is already under the hood of TLS.

Apart from this you can define CORS too, wherever required.