This section refers to using the Gloo Mesh Enterprise external auth server to authenticate requests for north-south traffic to the service mesh through the ingress gateway. For authentication of service-to-service traffic, see the east-west traffic authentication guide.
Gloo Mesh Enterprise provides a variety of authentication options to meet the needs of your environment, from basic user credentials to complex, fine-grained, and secure access control.
Envoy supports basic authentication options such as JSON web token (JWT) verification, but for many authentication requests at scale, prefers an external service supported through the external auth filter. Architecturally, Gloo Mesh provides a dedicated external authentication server (Ext Auth) to verify the user credentials and validate user permissions. Ext Auth can support several authentication and authorization (authN/Z) implementations, or you can provide your own auth server to implement custom logic.
We have seen how
AuthConfigs can be used to define granular authentication configurations for routes. For a detailed overview of the authN/authZ models implemented by Gloo Mesh Gateway, check out the other guides:
Basic auth: Authenticate using a dictionary of usernames and passwords on a virtual gateway
OAuth: Set up external auth with OAuth
API keys: Set up API key authentication
OPA authorization: Combine OpenID Connect with Open Policy Agent to achieve fine-grained policy with Gloo Mesh
LDAP: Authenticate and authorize requests using LDAP
Extauth within or external to the mesh
By default, extauth installs as a part of your mesh. This means you get all the benefits of being part of the mesh (observability, telemetry, mtls, etc.), but also means you get the drawbacks (extra network hop). The location for the extauth service can be configured to use an external service destination, i.e., external to the mesh.
Auth configuration overview
You can configure authentication in a top-level
AuthConfig custom resource, as shown in the following example.
spec consists of an array of
configs that are executed in sequence when a request matches the
AuthConfig (more on how requests are matched to
AuthConfigs shortly). If any of these authentication configs fails, the request is denied (this behavior is configurable). In most cases, an
AuthConfig has a single
apiVersion: enterprise.gloo.solo.io/v1 kind: AuthConfig metadata: name: basic-auth namespace: gloo-system spec: configs: - basicAuth: apr: users: user: hashedPassword: 14o4fMw/Pm2L34SvyyA2r. salt: 0adzfifo realm: gloo
Using the auth configuration
AuthConfig is created, it can be used to authenticate your routes. You can define authentication configuration your gateway at three different levels:
- on VirtualGateways
- on VirtualHosts, and
- on Routes
The configuration format is the same in all three cases. It must be specified under the relevant
options attribute and can take one of two forms. The first is used to enable authentication and requires you to reference an existing
AuthConfig. An example configuration of this kind follows:
options: extauth: configRef: # references the example AuthConfig we defined earlier name: basic-auth namespace: gloo-system
In the case of a route or weighted destination, the top attribute would be named
options as well.
The second form is used to disable authentication explicitly:
options: extauth: disable: true