0

In a microservices scenario, each web-api container should serve itself through HTTPS or is it ok to internally work through HTTP and have all ingresses configured with certificates and redirecting to port 80 of the containers?

I think the easiest approach is to protect only the outside traffic, because to configure an Asp.Net Core WebAPI to serve itself (kestrel) through HTTPS (for example) you have to mount the certificate in a volume and provide the certificate password. It's a little bit complicated.

What is the best practice?

Jackson Mourão
  • 103
  • 2

3 Answers3

2

It depends on requirements and resources, if you have On-Prem or baremetal, etc.

No requirements to secure traffic

If there are no requirements regarding securing client traffic inside the cluster, you can terminate client SSL connection on ingress-controller and use HTTP between the Pods.

Secure requirements

If there is a need to secure client traffic to destinated pod, it can be obtain in two ways.

  • L3 LoadBalancer with NodePort, configured with SSL Passtrought on Ingress.
  • If trafic will require to use SSL but it's not required to deliver SSL directly to the designated Pod, it would be easier to implement it by configuring Istio Mesh with mTLS. This option will allow you route traffic using HTTP headers and you don't need to manage certificates manually. Please check this for more information.

As Best Practises always tend to be as much secure as it is possible, it's always recommend to use secure connection. Despite that, some scenarios just don't need that.

PjoterS
  • 615
  • 3
  • 11
1

If your cluster is running in the cloud and using an external cloud balancer, your ingress and pods could be sitting on different machines or datacenters. In this case, you should indeed enforce TLS from the ingress to the pods.

In any case, the load balancer and your cluster should be in the same (hopefully restricted) VPC.

davidmontoyago
  • 141
  • 3
1

It also depends on the attack vectors you are protecting against.

If you are worried that someone could sniff the traffic between your Kubernetes nodes, then you could consider using a network plugin (CNI) which supports encryption such as WeaveNet or you could place all your nodes on a VPN network using Wireguard or OpenVPN.

If you want to protect the services on the cluster from each other, you should consider something like Istio which encrypts the traffic between pods.

amq
  • 703
  • 2
  • 6
  • 9