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

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
CVE-2018-18264 Privilege escalation through Kubernetes dashboard

CVE-2018-18264 Privilege escalation through Kubernetes dashboard

A recently disclosed vulnerability in Kubernetes dashboard (CVE-2018-18264) exposes secrets to unauthenticated users. In this blog post we’ll explore some key takeaways regarding monitoring privilege escalation on Kubernetes. The Kubernetes dashboard is a web based user interface that allows users to manage applications and resources within the cluster.

Read More
Sidestepping Dependency Ordering with AppSwitch

Sidestepping Dependency Ordering with AppSwitch

We are going through an interesting cycle of application decomposition and recomposition. While the microservice paradigm is driving monolithic applications to be broken into separate individual services, the service mesh approach is helping them to be connected back together into well-structured applications. As such, microservices are logically separate but not independent.

Read More