Eshoponcontainers: SSL termination for internal communication between gRPC or GraphQL services

[rafsanulhasan]

There are a couple of questions I'm confused about. It's about SSL offloading or SSL temination on API Gateway. Most of the speakers described that internal microservices (APIs) should rely each other in terms of security and thus SSL should be terminated at API gateway level which also improves performance because it offloads SSL handshake.

My question/confusion is, when I'm using latest tools like gRPC or GraphQL instead of REST, they require the services to be hosted using SSL. So while using GraphQL, for instance, should I terminate SSL into API GW level? or should I use different endpoints for public and internal endpoints in the microservices? Like for internal communication, if I use insecure endpoints, it would be okay for rest services, but is it okay for gRPC or GraphQL services (since they don't allow insecure endpoints and goes against compliance)? And since we are in a "SSL everywhere" hype, does using insecure endpoint a best practice for microservices architecture?

Thanks in advance for reading the long post and your valuable time...

[mvelosop]

Hi @rafsanulhasan, thanks for the feedback. That's an interesting question!

I tend to be cautious about "best practices" because most of what I've seen don't mention context, and I think that, as usual, there's no silver bullet and every solution has to be tailored to the context at hand.

I don't know about GraphQL, but you can use gRPC over HTTP, actually the communication between the aggregator and the microservices is carried out this way, without HTTPS.

The HTTPS overhead is probably not important for most typical LOB application for a small company, but it could make a real difference under a very large load, that could probably be translated to infrastructure cost.

And then, there could be industry-specific compliance restrictions.

eShopOnContainers doesn't use HTTPS mostly to simplify setup, although that might change, mostly because the release of Chrome 80.

BTW, if you want to explore HTTPS in docker-compose, the "Hosting ASP.NET Core images with Docker Compose over HTTPS" article seems like a good place to start. I tried with the Identity microservice and seems to be working.

Hope this helps.

[eiximenis]

Hi!

So while using GraphQL, for instance, should I terminate SSL into API GW level?

If running on Kubernetes, could do SSL ending at ingress level with a public valid cert, and then use internal https calls using custom TLS certs. If relying in a custom CA those certs can be generated by Helm at deploy time, or by Kubernetes itself through the cert api. It's normal to generate the certs at deploy time because you need the fqdn of the service, and that value can be unknown until deployment time (i.e. if you deploy on different namespaces based on your environment).

or should I use different endpoints for public and internal endpoints in the microservices?

Note that in k8s you always have the two endpoimts: external through ingress and internal throgh service. Those endpoints have different fqdn, thus need different ssl certs. If possible I try to avoid TLS in internal endpoints (more complex to manage), but as pointed out before, sometimes this is not possible.

Hope this helps!

[mvelosop]

Closing this issue now but feel free to comment, will reopen if needed.