Custom Auth Plugins for Envoy based API Gateway

At, Gloo is our cloud-native, next-generation API Gateway built on Envoy Proxy and runs natively on Kubernetes (and Consul, and elsewhere). Gloo has been built from its foundations to be extensible and pluggable, from the proxy itself to the control plane. One aspect of extensibility we often hear from our users and customers is the ability to extend the out of the box security features. When our users deploy Gloo, there is often a requirement to stay backward compatible (especially when we are replacing existing legacy, non-cloud-native Gateways), so these extensibility points are crucial.

Both open-source Gloo as well as Gloo Enterprise give the user a few customization options. Let’s take a look.

Gloo Control Plane

In the Gloo control plane, the ExtAuth service is responsible for implementing the security checks when a request flows through the proxy. In this diagram, we see the ExtAuth logically deployed in the control plane, though for performance reasons we have options to reduce latency (like implement in the Gateway itself, as a sidecar, as a daemon set, etc).

Gloo control plane components

The communication between the Gateway (Envoy) and the ExtAuth service is over gRPC. In the open-source Gloo project, you can bring your own ExtAuth service and configure it to deny/allow requests based on custom logic. In Gloo Enterprise, we have an out of the box ExtAuth service that can be configured for the following security policies:

And others. A powerful and useful option for extending the out of the box security features is the ability to write your own plugins and include them into the ExtAuth service deployment. This means you can get the best of both worlds: extensibility without having to completely rewrite/bring your own ExtAuth service.

Extending ExtAuth with custom plugins

We’ve recently released a 5-part video series (each video between 5–7m or so) going into details about writing plugins for the ExtAuth service. These plugins are written in Go and loaded as shared modules. The plugins get loaded dynamically at runtime within the ExtAuth service:

Using initcontainer to copy plugins to /auth-plugins directory, which then get loaded by ExtAuth service

We’ve also got detailed examples ( of an ExtAuth plugin as well as step-by-step documentation:

Take a look at the video play list!

Feedback welcome on on Twitter @soloio_inc or directly to me @christianposta