Securing gRPC connections with TLS/SSL and Ambassador

gRPC is a high performance, polyglot RPC framework growing in popularity, particularly with microservice architectures. gRPC includes native support for TLS and SSL. This requires both your server and client to manage certificates and security, which gives developers one more thing to worry about (and do correctly!).

TLS/SSL termination with a reverse proxy

An alternative approach is to terminate TLS directly with a reverse proxy or API Gateway such as Ambassador Edge Stack. In this approach, the server no longer needs to manage certificates; Ambassador handles this. Ambassador then passes (unencrypted) gRPC traffic to the server. Obviously, this approach only works if the network between Ambassador and the server is secure in some other way.

With Ambassador’s native gRPC and TLS support, this is straightforward. After configuring Ambassador for TLS, make sure your client loads the root certificate so that TLS connection can be properly validated.

For more on setting up TLS/SSL termination with Ambassador and gRPC, see the Ambassador gRPC guide.

Originating TLS/SSL and gRPC

Ambassador can also originate gRPC connections over TLS/SSL if you need end-to-end encryption.

In this approach, your server code needs to be updated to read and validate the certificates used by Ambassador to originate TLS. More details on this approach are covered in the Originating TLS with gRPC section of the gRPC guide.

Using Ambassador with gRPC and TLS

Using Ambassador to terminate TLS with gRPC lets you gain the various benefits of the API Gateway, such as authentication, metrics, and dynamic routing. We’re continuing to improve our gRPC support, so please feel free to join us on Slack and let us know how we can do a better job with supporting gRPC.