Server Name Indication (SNI) Support Now in Ambassador

Server Name Indication (SNI) Support Now in Ambassador

  • January 27, 2019
Table of Contents

Server Name Indication (SNI) Support Now in Ambassador

We’ve discussed many interesting use cases for SNI support within the edge proxy/gateway with both open source and commercially supported users of Ambassador. In a nutshell (and with thanks to Wikipedia), SNI is an extension to the TLS protocol which allows a client to indicate which hostname it is attempting to connect to at the start of the TCP handshaking process. This allows the server to present multiple certificates on the same IP address and TCP port number, which in turn enables the serving of multiple secure websites or API services without requiring all those sites to use the same certificate.

For those of you who have configured edge proxies and API gateways in the past, SNI is the conceptual equivalent to HTTP/1.1 name-based virtual hosting, but for HTTPS. Many people are running Kubernetes clusters that offer multiple backend services to end-users, and frequently they want to serve secure traffic while presenting multiple hostnames as, for example, this allows the easy differentiation of services (e.g. www.datawire.io and api.dw.io) on offer, and supports the exposure of multiple in-house (web addressable) brands that share backend services from a single cluster (e.g. www.fashion-brand-one.com and www.fashion-brand-two.com). The Ambassador SNI documentation provides a step-by-step guide to configuration, but I’ve also provided a summary here.

Source: getambassador.io

Tags :
Share :
comments powered by Disqus

Related Posts

Jaeger integration in Kiali

Jaeger integration in Kiali

Kiali has the ability to show traces obtained from Istio. Jaeger collects traces for monitoring and troubleshooting microservices-based distributed systems, and both Istio and Kiali use the data that Jaeger provides. Originally this was done via a separate tab in the UI.

Read More
APIServer dry-run and kubectl diff

APIServer dry-run and kubectl diff

Declarative configuration management, also known as configuration-as-code, is one of the key strengths of Kubernetes. It allows users to commit the desired state of the cluster, and to keep track of the different versions, improve auditing and automation through CI/CD pipelines. The Apply working-group is working on fixing some of the gaps, and is happy to announce that Kubernetes 1.13 promoted server-side dry-run and kubectl diff to beta.

Read More
Rate Limiting at the Edge

Rate Limiting at the Edge

I’m sure many of you have heard of the “Death Star Security” model—the hardening of the perimeter, without much attention paid to the inner core—and while this is generally considered bad form in the current cloud native landscape, there is still many things that do need to be implemented at edge in order to provide both operational and business logic support. One of these things is rate limiting. Modern applications and APIs can experience a burst of traffic over a short time period, for both good and bad reasons, but this needs to be managed well if your business model relies upon the successful completion of requests by paying customers.

Read More