Services on

Authentication service

Mon, 01 Jan 0001 00:00:00 +0000

Emissary provides a highly flexible mechanism for authentication, via the AuthService resource. An AuthService configures Emissary to use an external service to check authentication and authorization for incoming requests. Each incoming request is authenticated before routing to its destination.

All requests are validated by the AuthService (unless the Mapping applied to the request sets bypass_auth). It is not possible to combine multiple AuthServices. While it is possible to create multiple AuthService resources, Emissary load-balances between them in a round-robin fashion. This is useful for canarying an AuthService change, but is not useful for deploying multiple distinct AuthServices. In order to combine multiple external services (either having multiple services apply to the same request, or selecting between different services for the different requests), instead of using an AuthService, use an Ambassador Edge Stack External Filter.

ExtAuth protocol

Mon, 01 Jan 0001 00:00:00 +0000

By design, the ExtAuth protocol used by the AuthService and by External Filters is highly flexible. The authentication service is the first external service invoked on an incoming request (e.g., it runs before the rate limit filter). Because the logic of authentication is encapsulated in an external service, you can use this to support a wide variety of use cases. For example:

Supporting traditional SSO authentication protocols, e.g., OAuth, OpenID Connect, etc.
Supporting HTTP basic authentication (see a sample implementation).
Only authenticating requests that are under a rate limit and rejecting authentication requests above the rate limit.
Authenticating specific services (URLs), and not others.

For each request, the ExtAuth service may either:

Log Service

Mon, 01 Jan 0001 00:00:00 +0000

By default, Emissary puts the access logs on stdout; such that the can be read using kubectl logs. The format of those logs, and the local destination of them, can be configured using the envoy_log_ settings in the ambassador Module. However, the options there only allow for logging local to Emissary’s Pod. By configuring a LogService, you can configure Emissary to report its access logs to a remote service, in addition to the usual ambassador Module configured logging.

Rate limit service

Mon, 01 Jan 0001 00:00:00 +0000

Rate limiting is a powerful technique to improve the availability and resilience of your services. In Emissary, each request can have one or more labels. These labels are exposed to a third-party service via a gRPC API. The third-party service can then rate limit requests based on the request labels.

Note that RateLimitService is only applicable to Emissary, and not Ambassador Edge Stack, as Ambassador Edge Stack includes a built-in rate limit service.

Tracing service

Mon, 01 Jan 0001 00:00:00 +0000

Applications that consist of multiple services can be difficult to debug, as a single request can span multiple services. Distributed tracing tells the story of your request as it is processed through your system. Distributed tracing is a powerful tool to debug and analyze your system in addition to request logging and metrics.

When enabled, the TracingService will instruct Emissary to initiate a trace on requests by generating and populating an x-request-id HTTP header. Services can make use of this x-request-id header in logging and forward it in downstream requests for tracing. Emissary also integrates with external trace visualization services, including Zipkin-compatible APIs such as Zipkin and Jaeger to allow you to store and visualize traces. You can read further on Envoy’s Tracing capabilities.