- Connecting Services
- Service Mesh
- Best Practices
- IDP Support
- Custom Resource Definitions
- Upgrading Ambassador
- Statistics and Monitoring
- Need Help?
Most modern websites that force HTTPS will also automatically redirect any requests that come into it over HTTP.
Client Ambassador | | | http://<hostname>/api | | --------------------------> | | 301: https://<hostname>/api | | <-------------------------- | | https://<hostname>/api | | --------------------------> | | |
Ambassador exposes configuration for this in two ways:
- Redirecting based off the incoming port
- Redirecting based off the incoming protocol (via the
Typically, port-based redirection is the preferred method since it is simpler to manage and will work with all use cases. Redirecting based off the
x-forwarded-proto header requires an L7 load-balancer or proxy in front of Ambassador to set that header.
Port-based redirection opens up Ambassador to listen on a defined port and issue a
301 redirect to HTTPS for all traffic that comes in on that port.
In the example at the top of the page;
- The client sends a standard http request (port 80) to Ambassador.
- The request hits Ambassador's redirect listener and Ambassador returns a
301redirect to https.
- The client resends the request as a standard https request (port 443) to Ambassador.
To configure Ambassador to handle this behavior you need to create a
Module that sets
TLSContextto handle TLS termination
apiVersion: ambassador/v1 kind: TLSContext name: tls hosts: ["*"] secret: ambassador-cert
Moduleto create the redirect listener in Ambassador on Ambassadors http port. By default, this is port
apiVersion: ambassador/v1 kind: Module name: tls config: server: redirect_cleartext_from: 8080
Verify the port assignments on the Ambassador service are correct.
The below service definition uses the default http and https port assignments
apiVersion: v1 kind: Service metadata: name: ambassador spec: ports: - name: http port: 80 targetPort: 8080 - name: https port: 443 targetPort: 8443 selector: service: ambassador
As shown above, Ambassador performs this http -> https redirection by issuing a
301 redirect to
<hostname> represents the domain name/IP address and port of the incoming request. This means if a port is defined on an incoming request, it will be redirected to https on that port. Because of this, cleartext redirection is not supported when using non-default http and https ports.
Ambassador can perform HTTP -> HTTPS redirection based off the protocol of the incoming request. This is done by checking the
x-forwarded-proto header that can be set by an L7 load balancer or proxy sitting in front of Ambassador.
While port-based redirection is preferred for most use cases, using the
x-forwarded-proto header to redirect to HTTPS is useful when the front load balancer or proxy is terminating TLS.
Protocol-based redirection is configured in the Ambassador
apiVersion: ambassador/v1 kind: Module name: ambassador config: use_remote_address: false x_forwarded_proto_redirect: true
Note: Ambassador will need to be restarted for this configuration to take affect.
See the AWS documentation an example of protocol-based redirection with TLS termination happening at the load balancer.