Cleartext support
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.
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:
requestPolicy:
insecure:
action: Redirect
This allows routing for either HTTP and HTTPS, or only HTTP, depending on tlsSecret configuration:
- If the
Hostdoes not specify atlsSecret, it will only route HTTP, not terminating TLS at all. - If the
Hostdoes specify atlsSecret, it will route both HTTP and HTTPS.
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.
HTTP->HTTPS redirection
Most websites that force HTTPS will also automatically redirect any requests that come into it over HTTP:
Client Emissary
| |
| http://<hostname>/api |
| --------------------------> |
| |
| 301: https://<hostname>/api |
| <-------------------------- |
| |
| https://<hostname>/api |
| --------------------------> |
| |
In Emissary, this is configured by setting the insecure.action in a Host to Redirect.
requestPolicy:
insecure:
action: Redirect
Emissary determines which requests are secure and which are insecure using the
securityModel of the Listener that accepts the request.
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.