- Features and Benefits
- Using Ambassador Edge Stack in Your Organization
- Ambassador Edge Stack vs. Other Software
- Certified Builds
- Ambassador Edge Stack Architecture
- Ambassador Edge Stack Deployment Architecture
- Continuous Delivery, Declarative Config, and GitOps
- Microservices API Gateways
- Rate Limiting Concepts
- Self-Service Routing and Deployment Control
- Safely Testing in Production
- OAuth & OIDC Overview
- Why Ambassador Edge Stack Uses Envoy Proxy (External Link)
- Configuring Ambassador Edge Stack
- Mapping Services
- Canary Releases
- Circuit Breakers
- Cross Origin Resource Sharing
- Header-based routing
- Host Header
- Host CRD
- Prefix Regex
- Rate Limits
- Remove Request Headers
- Remove Response Headers
- Add Request Headers
- Add Response Headers
- Automatic Retries
- Routing TCP Connections
- Traffic Shadowing
- Developer Portal
- Filter Reference
- Statistics and Monitoring
Ambassador Edge Stack can be configured to both provide certificates from upstream services, and to validate them. This behavior is called mutual TLS (mTLS) and is commonly done when using a service mesh to enforce end-to-end TLS for all services in your cluster.
To configure mTLS between Ambassador Edge Stack 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 Edge Stack to do mTLS with two popular service meshes, Istio and Consul Connect.
Istio stores its TLS certificates as Kubernetes secrets by default, so accessing them is a matter of YAML configuration changes.
- Load Istio's TLS certificates
Istio creates and stores its TLS certificates in a form that Ambassador Edge Stack is currently unable to automatically read. Because of this, you will need to mount the
istio.default secret in a volume in the Ambassador Edge Stack container. This is done by configuring a
volumeMount in the Ambassador Edge Stack deployment manifest.
---apiVersion: apps/v1kind: Deploymentmetadata:name: ambassadorspec:...volumeMounts:- mountPath: /etc/istiocerts/name: istio-certsreadOnly: truerestartPolicy: Alwaysvolumes:- name: istio-certssecret:optional: truesecretName: istio.default
TLSContextto load these certificates---apiVersion: getambassador.io/v2kind: TLSContextmetadata:name: istio-upstreamspec:cert_chain_file: /etc/istiocerts/cert-chain.pemprivate_key_file: /etc/istiocerts/key.pemcacert_chain_file: /etc/istiocerts/root-cert.pem
Configure Ambassador Edge Stack to use this
TLSContextwhen making connections to upstream services.
tlsattribute in a
Mappingconfiguration tells Ambassador Edge Stack to use the
TLSContextwe created above when making connections to upstream services.---apiVersion: getambassador.io/v2kind: Mappingmetadata:name: productpagespec:prefix: /productpage/rewrite: /productpageservice: https://productpage:9080tls: istio-upstream
Ambassador Edge Stack will now use the certificate stored in the
istio.default secret to originate TLS to istio-powered services. See the Ambassador Edge Stack 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 Edge Stack 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
TLSContext:---apiVersion: getambassador.io/v2kind: TLSContextmetadata:name: ambassador-consulspec:hosts: secret: ambassador-consul-connect
Tell Ambassador to use the
TLSContextwhen proxying requests by setting the
tlsattribute in a
Mapping---apiVersion: getambassador.io/v2kind: Mappingmetadata:name: qotm-mtlsspec:prefix: /qotm-consul-mtls/service: https://qotm-proxytls: ambassador-consul
Ambassador Edge Stack 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)|