- Connecting Services
- Service Mesh
- Best Practices
- IDP Support
- Custom Resource Definitions
- Upgrading Ambassador
- Statistics and Monitoring
- Need Help?
Ambassador can be configured to both provide to and validate certificates from upstream services. This behavior is called mutual TLS (mTLS) and is a commonly done when using a service mesh to enforce end-to-end TLS for all services in your cluster.
To configure mTLS between Ambassador and your upstream services, you need to create a
TLSContext with certificates that are signed by the Certificate Authority (CA) of your upstream service.
Below are examples of how to configure Ambassador to do mTLS with two popular service meshes, Istio and Consul Connect.
Istio stores it's TLS certificates as Kubernetes secrets by default, so accessing them is a matter of YAML configuration changes.
- Load Istio's TLS certificates
Istio creates stores it's tls certificates in a form that Ambassador is currently unable to automatically read. Because of this, you will need to mount the
istio.default secret in a volume in the Ambassador container. This is done by configuring a
volumeMount in the Ambassador deployment manifest.
--- apiVersion: extensions/v1beta1 kind: Deployment metadata: name: ambassador spec: ... volumeMounts: - mountPath: /etc/istiocerts/ name: istio-certs readOnly: true restartPolicy: Always volumes: - name: istio-certs secret: optional: true secretName: istio.default
TLSContextto load these certificates
--- apiVersion: ambassador/v1 kind: TLSContext name: istio-upstream cert_chain_file: /etc/istiocerts/cert-chain.pem private_key_file: /etc/istiocerts/key.pem cacert_chain_file: /etc/istiocerts/root-cert.pem
Configure Ambassador to use this
TLSContextwhen making connections to upstream services.
tlsattribute in a
Mappingconfiguration tell's Ambassador to use the
TLSContextwe created above when making connections to upstream services.
--- apiVersion: ambassador/v1 kind: Mapping name: productpage_mapping prefix: /productpage/ rewrite: /productpage service: https://productpage:9080 tls: istio-upstream
Ambassador will now use the certificate stored in the
istio.default secret to originate TLS to istio-powered services. See the Ambassador with Istio documentation) for an example with more information.
Since Consul does not expose TLS Certificates as Kubernetes secrets, we will need a way to export those from Consul.
Install the Ambassador Consul connector.
kubectl apply -f https://www.getambassador.io/yaml/consul/ambassador-consul-connector.yaml
This will grab the certificate issued by Consul CA and store it in a Kubernetes secret named
ambassador-consul-connect. It will also create a Service named
ambassador-consul-connectorwhich will configure the following
--- apiVersion: ambassador/v1 kind: TLSContext name: ambassador-consul hosts:  secret: ambassador-consul-connect
Tell Ambassador to use the
TLSContextwhen proxying requests by setting the
tlsattribute in a
--- apiVersion: ambassador/v1 kind: Mapping name: qotm_mtls_mapping prefix: /qotm-consul-mtls/ service: https://qotm-proxy tls: ambassador-consul
Ambassador will now use the certificates loaded into the
TLSContext when proxying requests with
prefix: /qotm-consul-mtls. See the Consul example for an example configuration.
Note: The Consul connector can be configured with the following environment variables. The defaults will be best for most use-cases.
|_AMBASSADOR_ID||Set the Ambassador ID so multiple instances of this integration can run per-Cluster when there are multiple Ambassadors (Required if
|_CONSUL_HOST||Set the IP or DNS name of the target Consul HTTP API server||
|_CONSUL_PORT||Set the port number of the target Consul HTTP API server||
|_AMBASSADOR_TLS_SECRET_NAME||Set the name of the Kubernetes
|_AMBASSADOR_TLS_SECRET_NAMESPACE||Set the namespace of the Kubernetes
||(same Namespace as the Pod running this integration)|