Mutual TLS (mTLS)
Many organizations have security concerns that require all network traffic throughout their cluster be encrypted. With traditional architectures, this was not that complicated of a requirement since internal network traffic was fairly minimal. With microservices, we are making many more requests over the network that must all be authenticated and secured.
In order for services to authenticate with each other, they will each need to provide a certificate and key that the other trusts before establishing a connection. This action of both the client and server providing and validating certificates is referred to as mutual TLS.
mTLS with Ambassador
Since Ambassador is a reverse proxy acting as the entry point to your cluster, Ambassador is acting as the client as it proxies requests to services upstream.
It is trivial to configure Ambassador to simply originate TLS connections as
the client to upstream services by setting
service: https://{{UPSTREAM_SERVICE}}
in the Mapping
configuration.
However, in order to do mTLS with services upstream, Ambassador must also
have certificates to authenticate itself with the service.
To do this, we can use the TLSContext
object to get certificates from a
Kubernetes Secret
and use those to authenticate with the upstream service.
---apiVersion: getambassador.io/v2kind: TLSContextmetadata:name: upstream-contextspec:hosts: []secret: upstream-certs
We give it host: []
since we do not want to use this to terminate TLS
connections from the client. We are just using this to load certificates for
requests upstream.
After loading the certificates, we can tell Ambassador when to use them by
setting the tls
parameter in a Mapping
:
apiVersion: getambassador.io/v2kind: Mappingmetadata:name: upstream-mappingspec:prefix: /upstream/service: upstream-servicetls: upstream-context
Now, when Ambassador proxies a request to upstream-service
, it will provide
the certificates in the upstream-certs
secret for authentication when
encrypting traffic.
Service Mesh
As you can imagine, when you have many services in your cluster all authenticating with each other, managing all of those certificates can become a very big challenge.
For this reason, many organizations rely on a service mesh for their service-to-service authentication and encryption.
Ambassador integrates with multiple service meshes and makes it easy to configure mTLS to upstream services for all of them. Click the links below to see how to configure Ambassador to do mTLS with any of these service meshes:
Questions?
We’re here to help. If you have questions, join our Slack or contact us.