Transport Layer Security (TLS) on

Cleartext support

Mon, 01 Jan 0001 00:00:00 +0000

While most modern web applications choose to encrypt all traffic, there remain cases where supporting cleartext communications is important. Emissary supports both forcing automatic redirection to HTTPS and serving cleartext traffic on a Host.

The Listener and Host CRDs work together to manage HTTP and HTTPS routing. This document is meant as a quick reference to the Host resource: for a more complete treatment of handling cleartext and HTTPS, see Configuring Emissary Communications.

Cleartext Routing

To allow cleartext to be routed, set the requestPolicy.insecure.action of a Host to Route:

Mutual TLS (mTLS)

Mon, 01 Jan 0001 00:00:00 +0000

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.

Server Name Indication (SNI)

Mon, 01 Jan 0001 00:00:00 +0000

Emissary supports serving multiple Hosts behind a single IP address, each with their own certificate.

This is as easy to do as creating a Host for each domain or subdomain you want Emissary to serve, getting a certificate for each, and telling Emissary which Host the route should be created for.

The example below configures two Hosts and assigns routes to them.

Configuring a `Host`

The Host resources lets you separate configuration for each distinct domain and subdomain you plan on serving behind Emissary.

TLS Origination

Mon, 01 Jan 0001 00:00:00 +0000

Sometimes you may want traffic from Emissary to your services to be encrypted. For the cases where terminating TLS at the ingress is not enough, Emissary can be configured to originate TLS connections to your upstream services.

Basic configuration

Telling Emissary to talk to your services over HTTPS is easily configured in the Mapping definition by setting https:// in the service field.

---
apiVersion: getambassador.io/v3alpha1
kind: Mapping
metadata:
  name: basic-tls
spec:
  hostname: "*"
  prefix: /
  service: https://example-service

Advanced configuration using a `TLSContext`

If your upstream services require more than basic HTTPS support (for example, providing a client certificate or setting the minimum TLS version support) you must create a TLSContext for Emissary to use when originating TLS. For example:

Transport Layer Security (TLS) on

Cleartext support

Cleartext Routing

Mutual TLS (mTLS)

Server Name Indication (SNI)

Configuring a Host

TLS Origination

Basic configuration

Advanced configuration using a TLSContext

Configuring a `Host`

Advanced configuration using a `TLSContext`