Ambassador 0.50 GA Release Notes: SNI, New AuthService and Envoy v2 Support

Ambassador 0.50 GA Release Notes: SNI, New AuthService and Envoy v2 Support

  • February 2, 2019
Table of Contents

Ambassador 0.50 GA Release Notes: SNI, New AuthService and Envoy v2 Support

We are pleased to announce the GA release of Ambassador 0.50, with the headline features of Server Name Indication (SNI) support, more powerful rate limiting semantics, and a new AuthService. This release includes a major re-architecture under the hood that adds support for the Envoy Proxy v2 API and also uses the Aggregate Discovery Service (ADS) functionality, which removes the need for hot restarts. We are extremely grateful for everyone who contributed to this release, and also those who offered feedback via GitHub and our Slack.

We are constantly impressed by the community emerging around Ambassador and Envoy, and we have enjoyed talking to you many of you at KubeCon and other community events. Support for Server Name Indication (SNI) (issue #153), which allows the configuration of multiple TLS certificates where different domain names are used within the same Ambassador instance. Similar to other Ambassador functionality, we are enabling SNI to be configured on a per-mapping basis, with a separate global configuration that loads the necessary TLS certificates.

Ambassador now supports “request labels” that adds metadata to requests that can be used for advanced rate limiting use case. This deprecates the existing rate_limits functionality. Request labels are currently being used as a highly flexible mechanism for annotating requests for a third party rate limiting service, but in the future they can also be used to allow grouping and selection of requests within other functionality.

The integrated Ambassador Pro rate limiting service takes advantage of request labels to provide flexible rate limiting.

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
Server Name Indication (SNI) Support Now in Ambassador

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.

Read More