This is the user-facing auth configuration. When processed by Gloo, certain configuration types (i.a. oauth, opa)
will be translated, e.g. to resolve resource references. See the ExtAuthConfig.AuthConfig for the final config
format that will be included in the extauth snapshot.
List of auth configs to be checked for requests on a route referencing this auth config, By default, every config must be authorized for the entire request to be authorized. This behavior can be changed by defining names for each config and defining boolean_expr below. State is shared between successful requests on the chain, i.e., the headers returned from each successful auth service get appended into the final auth response. +kubebuilder:validation:Required +kubebuilder:validation:MinItems=1.
How to handle processing of named configs within an auth config chain. An example config might be: `( basic1
failOnRedirect
bool
How the service should handle a redirect response from an OIDC issuer. In the default false mode, the redirect will be considered a successful response, and the client will receive a 302 with a location header. If this is set to true, the client will instead receive a 401 unauthorized response. This is useful in cases where API calls are being made or other such occurrences where the client cannot handle the redirect.
optional: used when defining complex boolean logic, if boolean_expr is defined below. Also used in logging. If omitted, an automatically generated name will be used (e.g. config_0, of the pattern ‘config_$INDEX_IN_CHAIN’). In the case of plugin auth, this field is ignored in favor of the name assigned on the plugin config itself.
+kubebuilder:validation:XValidation:rule=“has(self.apr) ? !has(self.encryption) && !has(self.userList) : has(self.encryption) && has(self.userList)",message=“Either apr or both encryption and userSource must be set; apr may not be set alongside either encryption or userSource”. Only one of basicAuth, oauth, oauth2, apiKeyAuth, pluginAuth, opaAuth, ldap, jwt, passThroughAuth, hmacAuth, opaServerAuth, or portalAuth can be set.
This is a “dummy” extauth service which can be used to support multiple auth mechanisms with JWT authentication. If Jwt authentication is to be used in the boolean expression in an AuthConfig, you can use this auth config type to include Jwt as an Auth config. In addition, allow_missing_or_failed_jwt must be set on the Virtual Host or Route that uses JWT auth or else the JWT filter will short circuit this behaviour. Only one of jwt, basicAuth, oauth, oauth2, apiKeyAuth, pluginAuth, opaAuth, ldap, passThroughAuth, hmacAuth, opaServerAuth, or portalAuth can be set.
A reference to an AuthConfig. This is used to configure the Gloo Edge Enterprise extauth server. Only one of configRef, disable, or customAuth can be set.
Optional, if set the communication to the upstream will be via GRPC. Only one of grpcService or httpService can be set.
userIdHeader
string
If the auth server trusted id of the user, it will be set in this header. Specifically this means that this header will be sanitized form the incoming request.
Set this if you also want to send the body of the request, and not just the headers.
clearRouteCache
bool
Clears route cache in order to allow the external authorization service to correctly affect routing decisions. Filter clears all cached routes when: 1. The field is set to true. 2. The status returned from the authorization service is a HTTP 200 or gRPC 0. 3. At least one authorization response header is added to the client request, or is used for altering another client request header.
statusOnError
int
Sets the HTTP status that is returned to the client when there is a network error between the filter and the authorization server. The default status is HTTP 403 Forbidden. If set, this must be one of the following: - 100 - 200 201 202 203 204 205 206 207 208 226 - 300 301 302 303 304 305 307 308 - 400 401 402 403 404 405 406 407 408 409 410 411 412 413 414 415 416 417 421 422 423 424 426 428 429 431 - 500 501 502 503 504 505 506 507 508 510 511.
Determines the API version for the ext_authz transport protocol that will be used by Envoy to communicate with the auth server. Defaults to V2. For more info, see the transport_api_version field here.
statPrefix
string
Optional additional prefix to use when emitting statistics. This allows to distinguish emitted statistics between configured ext_authz filters in an HTTP filter chain.
ApiVersion
Describes the transport protocol version to use when connecting to the ext auth server.
Name
Description
V3
Use v3 API.
GrpcService
"authority": string
Field
Type
Description
authority
string
Set the authority header when calling the GRPC service.
These headers will be copied from the incoming request to the request going to the auth server. Note that in addition to the user’s supplied matchers: 1. Host, Method, Path and Content-Length are automatically included to the list. 2. Content-Length will be set to 0 and the request to the authorization service will not have a message body.
headersToAdd
map<string, string>
These headers that will be included to the request to authorization service. Note that client request of the same key will be overridden.
allowedHeadersRegex
[]string
Headers that match these regex patterns will be copied from the incoming request to the request going to the auth server.
When this is set, authorization response headers that have a header in this list will be added to the original client request and sent to the upstream. Note that coexistent headers will be overridden.
allowedClientHeaders
[]string
When this is set, authorization response headers in this list will be added to the client’s response when the auth request is denied. Note that when this list is not set, all the authorization response headers, except Authority (Host) will be in the response to the client. When a header is included in this list, Path, Status, Content-Length, WWW-Authenticate and Location are automatically added.
allowedUpstreamHeadersToAppend
[]string
When this is set, authorization response headers that have a correspondent match will be added to the client’s response. Note that coexistent headers will be appended.
Sets the maximum size of a message body that the filter will hold in memory. Envoy will return HTTP 413 and will not initiate the authorization process when buffer reaches the number set in this field. Note that this setting will have precedence over failure_mode_allow. Defaults to 4KB.
allowPartialMessage
bool
When this field is true, Envoy will buffer the message until max_request_bytes is reached. The authorization request will be dispatched and no 413 HTTP error will be returned by the filter.
packAsBytes
bool
When this field is true, Envoy will send the body sent to the external authorization service with raw bytes.
CustomAuth
Gloo is not expected to configure the ext auth server in this case.
This is used with custom auth servers.
When a request matches the virtual host, route, or weighted destination on which this configuration is defined, Gloo will add the given context_extensions to the request that is sent to the external authorization server. This allows the server to base the auth decision on metadata that you define on the source of the request. This attribute is analogous to Envoy’s config.filter.http.ext_authz.v2.CheckSettings. See the official Envoy documentation for more details.
name
string
[Enterprise-only] Only required in the case where multiple auth servers are configured in Settings This name must match a key in the named_extauth Settings.
AuthPlugin
Deprecated: The pluginAuth config type is deprecated and will be removed in a future release. Use passThroughAuth instead.
This is the legacy/simple basic auth config. It supports the APR and SHA-1 hashing algorithms.
When using basic auth, requests can pass only one Authorization header. You cannot use basic auth config in
conjunction with other auth configs that rely on the Authorization header as well. In case of such a conflict,
use a different type of auth config or configure a different header, such as X-Auth.
The encryption type to use to store the password on the server If ‘encryption’ is defined, ‘user_source’ must be defined and the top level ‘apr’ field must not be defined or the config will fail validation.
HMAC is a message authentication technique that can use multiple algorithms for finding credentials and generating signed messages.
It conforms to https://www.ietf.org/rfc/rfc2104.txt
The url of the issuer. We will look for OIDC information in issuerUrl+ “.well-known/openid-configuration”.
authEndpointQueryParams
map<string, string>
extra query parameters to apply to the Ext-Auth service’s authorization request to the identity provider.
appUrl
string
we to redirect after successful auth, if we can’t determine the original url this should be your publicly available app url. +kubebuilder:validation:Required +kubebuilder:validation:MinLength=1.
callbackPath
string
a callback path relative to app url that will be used for OIDC callbacks. needs to not be used by the application.
provide issuer location and let gloo handle OIDC flow for you. requests authorized by validating the contents of ID token. can also authorize the access token if configured. +kubebuilder:validation:XValidation:rule=“has(self.clientAuthentication) ? !has(self.clientSecretRef) && !has(self.disableClientSecret) : has(self.clientSecretRef)
provide the access token on the request and let gloo handle authorization. according to https://datatracker.ietf.org/doc/html/rfc6750 you can pass tokens through: - form-encoded body parameter. recommended, more likely to appear. e.g.: Authorization: Bearer mytoken123 - URI query parameter e.g. access_token=mytoken123 - and (preferably) secure cookies. Only one of accessTokenValidation, oidcAuthorizationCode, or oauth2 can be set.
Enterprise-Only: THIS FEATURE IS IN TECH PREVIEW. APIs are versioned as alpha and subject to change. provide issuer location and let Gloo handle Oauth2 flow for you. requests authorized by validating the contents of access token. Prefer to use OIDC for better security. +kubebuilder:validation:XValidation:rule=“has(self.clientSecretRef)
address of the redis. can be address:port or unix://path/to/unix.sock.
db
int
db to use. can leave unset for db 0.
poolSize
int
size of the connection pool. can leave unset for default. defaults to 10 connections per every CPU.
tlsCertMountPath
string
enabled with a socket type of TLS. this is the tls cert mount path for this particular host. the generic secret can include the keys ‘ca.crt’, ‘tls.crt’, and ‘tls.key’. the secret can contain the root-ca ,‘ca.crt’, at minimum. If a certificate is needed, both the ‘tls.crt’ and ‘tls.key’ need to be included. reference this to equal the ‘mountPath’ on the ‘redis.certs[x].mountPath’ in the helm chart values. an example of a mount path is ‘/certs’.
should we fail auth flow when failing to get a session from redis, or allow it to continue, potentially starting a new auth flow and setting a new session.
Refresh expired id-tokens using the refresh-token. The tokens refreshes when the client issues a call. Defaults to false. To enable refreshing, set to true.
Domain used to validate against requests in order to ensure that request host name matches target domain. If the target domain is provided will prevent requests that do not match the target domain according to the domain matching specifications in RFC 6265. For more information, see https://datatracker.ietf.org/doc/html/rfc6265#section-5.1.3.
Refresh expired id-tokens using the refresh-token. The tokens refreshes when the client issues a call. Defaults to true. To disable refreshing, set to false.
Specifies a time buffer in which an id-token will be refreshed prior to its actual expiration. Defaults to 2 seconds. A duration of 0 will only refresh tokens after they have already expired. To refresh tokens, you must also set ‘allowRefreshing’ to ‘true’; otherwise, this field is ignored.
targetDomain
string
Domain used to validate against requests in order to ensure that request host name matches target domain. If the target domain is provided will prevent requests that do not match the target domain according to the domain matching specifications in RFC 6265. For more information, see https://datatracker.ietf.org/doc/html/rfc6265#section-5.1.3.
headerName
string
If set, the name of the header that will include the randomly generated session id This would be used as part of the code exchange with the Oauth2 token endpoint.
Whether the cookie should be restricted to a first-party or same-site context. The default mode is LaxMode.
domain
string
Cookie domain.
SameSite
The SameSite options. The default value is LaxMode.
Name
Description
DefaultMode
Default Mode is the same as LaxMode but will not show up in the Cookie Header. This value is ignored.
LaxMode
Cookies are not sent on normal cross-site subrequests, but are sent when navigating to the origin site.
StrictMode
Cookies are sent only in first-party contexts and are not sent along with requests initiated by third-party websites. Warning: Do not use this mode if the app and the IdP have different domains. In this case, some browsers incorrectly detect the redirect from /callback to /login as a cross-site request.
NoneMode
Cookies are sent in all contexts. Cookie NotSecure must be unset.
CipherConfig
the cipher config is used to encrypt session cookie values. This is currently only available for OIDC.
list of response types that the provider supports.
subjects
[]string
list of subject identifier types that the provider supports.
idTokenAlgs
[]string
list of json web signature signing algorithms that the provider supports for encoding claims in a jwt.
authMethods
[]string
list of client authentication methods supported by the provider token endpoint.
claims
[]string
list of claim types that the provider supports.
revocationEndpoint
string
url of the provider token revocation endpoint.
endSessionEndpoint
string
url of the provider end session endpoint.
JwksOnDemandCacheRefreshPolicy
The json web key set (JWKS) (https://datatracker.ietf.org/doc/html/rfc7517) is discovered at an interval
from a remote source. When keys rotate in the remote source, there may be a delay in the
local source picking up those new keys. Therefore, a user could execute a request with a token
that has been signed by a key in the remote JWKS, but the local cache doesn’t have the key yet.
The request would fail because the key isn’t contained in the local set. Since most IdPs publish key
keys in their remote JWKS before they are used, this is not an issue most of the time.
This policy lets you define the behavior for when a user has a token with a key
not yet in the local cache.
"never": .google.protobuf.Empty"always": .google.protobuf.Empty"maxIdpReqPerPollingInterval": int
Never refresh the local JWKS cache on demand. If a key is not in the cache, it is assumed to be malicious. This is the default policy since we assume that IdPs publish keys before they rotate them, and frequent polling finds the newest keys. Only one of never, always, or maxIdpReqPerPollingInterval can be set.
If a key is not in the cache, fetch the most recent keys from the IdP and update the cache. NOTE: This should only be done in trusted environments, since missing keys will each trigger a request to the IdP. Using this in an environment exposed to the internet will allow malicious agents to execute a DDoS attack by spamming protected endpoints with tokens signed by invalid keys. Only one of always, never, or maxIdpReqPerPollingInterval can be set.
maxIdpReqPerPollingInterval
int
If a key is not in the cache, fetch the most recent keys from the IdP and update the cache. This value sets the number of requests to the IdP per polling interval. If that limit is exceeded, we will stop fetching from the IdP for the remainder of the polling interval. Only one of maxIdpReqPerPollingInterval, never, or always can be set.
The method type used by the end session endpoint, defaults to GET.
MethodType
The Method used to make the request.
Name
Description
GetMethod
Uses GET method when making the request
PostMethod
Uses POST method when making the request
ClaimToHeader
Map a single claim from an OAuth2 or OIDC token to a header in the request to the upstream destination.
"claim": string"header": string"append": bool
Field
Type
Description
claim
string
The claim name from the token, such as sub.
header
string
The header to copy the claim to, such as x-sub.
append
bool
If the header exists, append the claim value to the header (true), or overwrite any existing value (false). The default behavior is to overwrite any existing value (false).
Azure
For apps in Microsoft Azure, configure Microsoft Entra ID as the OpenID Connect (OIDC) provider.
This way, you can enable distributed claims and caching for when users are members of more than 200 groups.
The client ID for the ExtAuthService app that is registered in MS Entra, to access the Microsoft Graph API to retrieve distributed claims. This app is NOT the app that you want to configure external auth for.
tenantId
string
The tenant ID represents the MS Entra organization ID where the ExtAuthService app is registered. This tenant ID may or may not be the same as in the top level OidcAuthorizationCodeConfig, depending on how your Azure account is provisioned.
The client secret of the ExtAuthService app that is registered with MS Entra to communicate with the MS Graph API. The client secret data must be placed in a k8s secret under a key called ‘client-secret’.
Redis connection details to cache MS Entera claims. This way, you avoid performance issues of accessing the Microsoft Graph API too many times. Note that this setting does NOT turn on Redis caching for the user session. To turn on Redis user session caching, use the userSessionConfig field.
your client secret as registered with the issuer. This is required unless disable_client_secret is true This field has been deprecated and can be set in the client_secret option of client_authentication.
issuerUrl
string
The url of the issuer. We will look for OIDC information in issuerUrl+ “.well-known/openid-configuration” +kubebuilder:validation:Required +kubebuilder:validation:MinLength=1.
authEndpointQueryParams
map<string, string>
extra query parameters to apply to the Ext-Auth service’s authorization request to the identity provider. this can be useful for flows such as PKCE (https://www.oauth.com/oauth2-servers/pkce/authorization-request/) to set the code_challenge and code_challenge_method.
where to redirect after successful auth, if we can’t determine the original url. this should be your publicly available app url. +kubebuilder:validation:Required +kubebuilder:validation:MinLength=1.
callbackPath
string
a callback path relative to app url that will be used for OIDC callbacks. should not be used by the application. +kubebuilder:validation:Required +kubebuilder:validation:MinLength=1.
logoutPath
string
a path relative to app url that will be used for logging out from an OIDC session. should not be used by the application. If not provided, logout functionality will be disabled.
afterLogoutUrl
string
url to redirect to after logout. This should be a publicly available URL. If not provided, will default to the app_url.
OIDC configuration is discovered at /.well-known/openid-configuration The discovery override defines any properties that should override this discovery configuration For example, the following AuthConfig CRD could be defined as: yaml apiVersion: enterprise.gloo.solo.io/v1 kind: AuthConfig metadata: name: google-oidc namespace: gloo-system spec: configs: - oauth: app_url: http://localhost:8080 callback_path: /callback client_id: $CLIENT_ID client_secret_ref: name: google namespace: gloo-system issuer_url: https://accounts.google.com discovery_override: token_endpoint: "https://token.url/gettoken" And this will ensure that regardless of what value is discovered at /.well-known/openid-configuration, “https://token.url/gettoken" will be used as the token endpoint.
If a user executes a request with a key that is not found in the JWKS, it could be that the keys have rotated on the remote source, and not yet in the local cache. This policy lets you define the behavior for how to refresh the local cache during a request where an invalid key is provided.
sessionIdHeaderName
string
DEPRECATED: Prefer the RedisSession.HeaderName field If set, the randomly generated session id will be sent to the token endpoint as part of the code exchange The session id is used as the key for sessions in Redis.
parseCallbackPathAsRegex
bool
If set, CallbackPath will be evaluated as a regular expression.
If specified, authEndpointQueryParams and tokenEndpointQueryParams will be populated using dynamic metadata values. By default parameters will be extracted from the solo_authconfig_oidc namespace this behavior can be overridden by explicitly specifying a namespace.
If specified, these are properties defined for the end session endpoint specifications. Noted here in the OIDC documentation.
dynamicMetadataFromClaims
map<string, string>
Map of metadata key to claim. Ie: dynamic_metadata_from_claims: issuer: iss email: email When specified, the matching claims from the ID token will be emitted as dynamic metadata. Note that metadata keys must be unique, and the claim names must be alphanumeric and use - or _ as separators. The metadata will live in a namespace specified by the canonical name of the ext auth filter (in our case envoy.filters.http.ext_authz), and the structure of the claim value will be preserved in the metadata struct.
If true, do not check for or use the client secret. Generally the client secret is required and AuthConfigs will be rejected if it isn’t set. However certain implementations of the PKCE flow do not use a client secret (including Okta) so this setting allows configuring Oidc without a client secret. This field has been deprecated and can be set in the client_secret option of client_authentication.
Configuration for front channel logout. This is used to log out the user from multiple apps/clients associated with one OpenId Provider (OP). The path is registered with the OP and is called for each app/client that the user is logged into when the logout endpoint is called.
AccessToken
Optional: Map a single claim from an OAuth2 access token to a header in the request to the upstream destination.
Gloo Mesh products only: Note that if you want to clear the route cache to force the proxy to recalculate the
routing destination after adding the claims, you must create an additional JwtPolicy or TransformationPolicy,
and configure the clearRouteCache or recalculateRoutingDestination options.
If true, do not check for or use the client secret. Generally the client secret is required and AuthConfigs will be rejected if it isn’t set. However certain implementations of the PKCE flow do not use a client secret (including Okta) so this setting allows configuring Oidc without a client secret.
PrivateKeyJwt
Private Key JWT Authentication requires a signing key for the JWT and an duration for the JWT to be valid.
Amount of time for which the JWT is valid. No maximum is enforced, but different IDPs may impose limits on how far in the future the expiration time is allowed to be. If omitted, default is 5s.
Default
No-op, represents default OIDC behavior
Field
Type
Description
FrontChannelLogout
For the moment this is just path, but we may want to configure things like iss/sid validation
"path": string
Field
Type
Description
path
string
Path to use for front channel logout. Should not be the same as logout or callback paths.
Your client secret as registered with the issuer. This is required unless disable_client_secret is set.
authEndpointQueryParams
map<string, string>
Extra query parameters to apply to the Ext-Auth service’s authorization request to the identity provider. These parameters can be useful for flows such as PKCE to set the code_challenge and code_challenge_method.
appUrl
string
Where to redirect after successful auth, if Gloo can’t determine the original URL. Set this field to your publicly available app URL. +kubebuilder:validation:Required +kubebuilder:validation:MinLength=1.
callbackPath
string
A callback path relative to the app URL to be used for OAuth2 callbacks. Do not use this path in the application itself. +kubebuilder:validation:Required +kubebuilder:validation:MinLength=1.
A path relative to the app URL to use for logging out from an OAuth2 session. Do not use this path in the application itself. If not provided, logout functionality is disabled.
tokenEndpointQueryParams
map<string, string>
Extra query parameters to apply to the Ext-Auth service’s token request to the identity provider. These parameters can be useful for flows such as PKCE to set the code_verifier.
afterLogoutUrl
string
URL to redirect to after logout. Set this field to a publicly available URL. If not provided, this value defaults to the app_url value.
authEndpoint
string
The URL of the provider authorization endpoint. +kubebuilder:validation:Required +kubebuilder:validation:MinLength=1.
tokenEndpoint
string
The URL of the provider token endpoint. +kubebuilder:validation:Required +kubebuilder:validation:MinLength=1.
If true, do not check for or use the client secret. Generally the client secret is required and AuthConfigs will be rejected if it isn’t set. However certain implementations of the PKCE flow do not use a client secret (including Okta) so this setting allows configuring Oauth2 without a client secret.
JwtValidation
Defines how JSON Web Token (JWT) access tokens are validated.
Tokens are validated using a JSON Web Key Set (as defined in
Section 5 of RFC7517),
which can be either inlined in the configuration or fetched from a remote location via HTTP.
Any keys in the JWKS that are not intended for signature verification (i.e. whose
“use” parameter is not “sig”)
will be ignored by the system, as will keys that do not specify a
“kid” (Key ID) parameter.
The JWT to be validated must define non-empty “kid” and “alg” headers. The “kid” header
determines which key in the JWKS will be used to verify the signature of the token;
if no matching key is found, the token will be rejected.
If present, the server will verify the “exp”, “iat”, and “nbf” standard JWT claims.
Validation of the “iss” claim and of token scopes can be configured as well.
If the JWT has been successfully validated, its set of claims will be added to the
AuthorizationRequest state under the “jwtAccessToken” key.
The frequency at which the JWKS should be refreshed. If not specified, the default value is 5 minutes.
LocalJwks
Represents a locally available JWKS.
"inlineString": string
Field
Type
Description
inlineString
string
JWKS is embedded as a string. +kubebuilder:validation:Required +kubebuilder:validation:MinLength=1.
IntrospectionValidation
Defines how (opaque) access tokens, received from the oauth authorization endpoint, are validated
OAuth2.0 Token Introspection
If the token introspection url requires client authentication, both the client_id and client_secret
are required. Unless disable_client_secret is set, when only one is provided, the config will be rejected.
These values will be encoded in a basic auth header in order to authenticate the client.
The URL for the OAuth2.0 Token Introspection endpoint. If provided, the (opaque) access token provided or received from the oauth authorization endpoint will be validated against this endpoint, or locally cached responses for this access token. +kubebuilder:validation:Required +kubebuilder:validation:MinLength=1.
clientId
string
Your client id as registered with the issuer. Optional: Use if the token introspection url requires client authentication.
Your client secret as registered with the issuer. Optional: Use if the token introspection url requires client authentication.
userIdAttributeName
string
The name of the introspection response attribute that contains the ID of the resource owner (e.g. sub, username). If specified, the external auth server will use the value of the attribute as the identifier of the authenticated user and add it to the request headers and/or dynamic metadata (depending on how the server is configured); if the field is set and the attribute cannot be found, the request will be denied. This field is optional and by default the server will not try to derive the user ID.
The URL for the OAuth2.0 Token Introspection endpoint. If provided, the (opaque) access token provided or received from the oauth authorization endpoint will be validated against this endpoint, or locally cached responses for this access token. This field is deprecated as it does not support authenticated introspection requests +kubebuilder:validation:MinLength=1. Only one of introspectionUrl, jwt, or introspection can be set.
Defines how (opaque) access tokens, received from the oauth authorization endpoint, are validated OAuth2.0 Token Introspection specification. +kubebuilder:validation:XValidation:rule=“has(self.clientId) && size(self.clientId) > 0 ? has(self.clientSecretRef)
userinfoUrl
string
The URL for the OIDC userinfo endpoint. If provided, the (opaque) access token provided or received from the oauth endpoint will be queried and the userinfo response (or cached response) will be added to the AuthorizationRequest state under the “introspection” key. This can be useful to leverage the userinfo response in, for example, an external auth server plugin.
How long the token introspection and userinfo endpoint response for a specific access token should be kept in the in-memory cache. The result will be invalidated at this timeout, or at “exp” time from the introspection result, whichever comes sooner. If omitted, defaults to 10 minutes. If zero, then no caching will be done.
Require access token to have all of the scopes in the given list. This configuration applies to both opaque and JWT tokens. In the case of opaque tokens, this will check the scopes returned in the “scope” member of introspection response (as described in Section 2.2 of RFC7662. In case of JWTs the scopes to be validated are expected to be contained in the “scope” claim of the token in the form of a space-separated string. Omitting this field means that scope validation will be skipped.
dynamicMetadataFromClaims
map<string, string>
Map of metadata key to claim. Ie: dynamic_metadata_from_claims: issuer: iss email: email When specified, the matching claims from the access token will be emitted as dynamic metadata. Note that metadata keys must be unique, and the claim names must be alphanumeric and use - or _ as separators. Works when the access token is a JWT or when the access token is opaque, in which case the claims will refer to field in the response from the token introspection endpoint. The metadata will live in a namespace specified by the canonical name of the ext auth filter (in our case envoy.filters.http.ext_authz), and the structure of the claim value will be preserved in the metadata struct.
When the provided API key token has been successfully validated, it’s token will be
added to the AuthorizationRequest state under the “api_key_value” key name.
DEPRECATED: use K8sSecretApiKeyStorage to configure secrets storage backend. Values here will be overwritten if values are specified in the storage backend. Identify all valid API key secrets that match the provided label selector. API key secrets must be in one of the watch namespaces for gloo to locate them.
DEPRECATED: use K8sSecretApiKeyStorage to configure secrets storage backend. Values here will be overwritten if values are specified in the storage backend. A way to directly reference API key secrets. This configuration can be useful for testing, but in general the more flexible label selector should be preferred.
headerName
string
When receiving a request, the Gloo Edge Enterprise external auth server will look for an API key in a header with this name. This field is optional; if not provided it defaults to api-key.
API key structures might contain additional data (e.g. the ID of the user that the API key belongs to) in the form of extra fields included in the API key metadata structure. This configuration can be used to add this data to the headers of successfully authenticated requests. Each key in the map represents the name of header to be added; the corresponding value determines the key in the API key metadata structure that will be inspected to determine the value for the header. When the provided API key token has been successfully validated, and this field has been configured, then any extra API key metadata fields that were able to be discovered will be added to the AuthorizationRequest state under the key name that was configured. For example, using the x-user-name string as the header name, and referencing an existing “user-email” API key metadata entry will result in the value of this “user-email” metadata entry being accessable in other auth modules in the AuthorizationRequest.State["x-user-name"] key. This behavior allows other modules (e.g. OPA) to build more powerful rules to further validate the contents of the extra API key metadata than what’s possible using the standalone API key module.
Deprecated: Support for Aerospike is deprecated and will be removed in a future release. Use of this feature is not recommended. Only one of aerospikeApikeyStorage or k8sSecretApikeyStorage can be set.
skipMetadataValidation
bool
API key metadata may contain data is is invalid for a header, such as a newline. By default, this data will be validated in the data plane and mitigated in a way that provides a consistent experience for the user and visibility for the operator. This validation comes with a performance cost, and can be disabled by setting this field to true.
SecretKey
DEPRECATED: use generalized MetadataEntry
"name": string"required": bool
Field
Type
Description
name
string
DEPRECATED (Required) The key of the API key metadata entry to inspect.
required
bool
DEPRECATED If this field is set to true, Gloo will reject an API key structure that does not contain data for the given key. Defaults to false. In this case, if an API key structure does not contain the requested data, no header will be added to the request.
MetadataEntry
For the K8s secret backend, this data is stored as key-value data in the secret itself.
For the Aerospike backend, this data is stored as bins on the key’s record
"name": string"required": bool
Field
Type
Description
name
string
(Required) The key of the API key metadata entry to inspect.
required
bool
If this field is set to true, Gloo will reject an API key structure that does not contain data for the given key. Defaults to false. In this case, if an API key structure does not contain the requested data, no header will be added to the request.
Identify all valid API key secrets that match the provided label selector. API key secrets must be in one of the watch namespaces for gloo to locate them.
A way to directly reference API key secrets. This configuration can be useful for testing, but in general the more flexible label selector should be preferred.
AerospikeApiKeyStorage
Deprecated: Support for Aerospike is deprecated and will be removed in a future release.
Use of this feature is not recommended.
The IP address or hostname of one of the cluster members of your Aerospike database. The address must be reachable from Gloo Edge, such as in a virtual machine with a public IP address or in a pod in the cluster. The client automatically discovers other members of the cluster after establishing a connection.
namespace
string
The Aerospike namespace of the database. Defaults to “solo-namespace”.
set
string
The Aerospike set to use for storage of API keys. Defaults to “apikeys”.
port
int
The port on which to connect to the Aerospike server. Defaults to 3000.
batchSize
int
The size of the batch, which is the number of keys sent in the request. Defaults to 5000.
commitAll
int
“commit_all” indicates that the server waits until successfully committing the master and all replicas. Only one of commitAll or commitMaster can be set.
commitMaster
int
“commit_master” indicates that the server waits until successfully committing the master only. Only one of commitMaster or commitAll can be set.
The read settings for availability (AP). For possible values, see the Aerospike read mode AP. Defaults to “read_mode_ap_one”.
nodeTlsName
string
TLS settings to enable mutual TLS (mTLS) on the server side. These configuration options must match what you configured in your Aerospike setup. For more information, see the Aerospike security and network TLS guides. The subject name of the TLS authority. For more information, see the Aerospike docs.
certPath
string
The path to the TLS certfiicate.
keyPath
string
The path to the key.
allowInsecure
bool
The TLS insecure setting. If set to true, the authority of the certificate on the client’s end is not authenticated. You might use insecure mode in non-production environments when the certificate is not known.
rootCaPath
string
If the root certificate authority (CA) is not set, add the system certs by default.
tlsVersion
string
The TLS version. Versions 1.0, 1.1, 1.2, and 1.3 are supported. Defaults to 1.3.
The TLS identifier for an elliptic curve. For more information, see TLS supported groups.
labelSelector
map<string, string>
Identify the set of required labels (key/value) which an Aerospike secret must contain If a secret contains the provided set of labels, it will be considered valid when authorizing an ApiKey provided in a request.
readModeSc
"readModeScSession": int"readModeScLinearize": int"readModeScReplica": int"readModeScAllowUnavailable": int
Field
Type
Description
readModeScSession
int
The session ensures this client sees only an increasing sequence of record versions. Server reads only from master, which is the default. Only one of readModeScSession, readModeScLinearize, readModeScReplica, or readModeScAllowUnavailable can be set.
readModeScLinearize
int
“linearize” ensures that ALL clients see only an increasing sequence of record versions. “server” reads only from master. Only one of readModeScLinearize, readModeScSession, readModeScReplica, or readModeScAllowUnavailable can be set.
readModeScReplica
int
“replica” indicates that the server can read from master or any full (non-migrating) replica. An increasing sequence of record versions is not guaranteed. Only one of readModeScReplica, readModeScSession, readModeScLinearize, or readModeScAllowUnavailable can be set.
readModeScAllowUnavailable
int
“allow_unavailable” indicates that the server can read from master or any full (non-migrating) replica or from unavailable partitions. An increasing sequence of record versions is not guaranteed. Only one of readModeScAllowUnavailable, readModeScSession, readModeScLinearize, or readModeScReplica can be set.
readModeAp
"readModeApOne": int"readModeApAll": int
Field
Type
Description
readModeApOne
int
“one” indicates that a single node is involved in the read operation. Only one of readModeApOne or readModeApAll can be set.
readModeApAll
int
“all” indicates that all duplicate nodes are consulted in the read operation. Only one of readModeApAll or readModeApOne can be set.
tlsCurveID
"curveP256": int"curveP384": int"curveP521": int"x25519": int
Field
Type
Description
curveP256
int
Only one of curveP256, curveP384, curveP521, or x25519 can be set.
curveP384
int
Only one of curveP384, curveP256, curveP521, or x25519 can be set.
curveP521
int
Only one of curveP521, curveP256, curveP384, or x25519 can be set.
x25519
int
Only one of x25519, curveP256, curveP384, or curveP521 can be set.
ServerDefaultApiKeyStorage
When no storage backend is specified, the default storage backend defined in the extauth server is used.
A list of labels (key=value) for the apikey secret. These labels are used by the storage driver to facilitate lookups by label.
metadata
map<string, bool>
additional data the client needs associated with this API key.
OpaAuth
Enforce Open Policy Agent (OPA) policies through an OPA engine
that is built into the Gloo external auth server.
For larger scale operations and more capabilities like bundling or caching,
you might run the OPA engine as a sidecar or bring your own server
by using the OpaServerAuth setting instead.
An optional resource reference to config maps containing modules to assist in the resolution of query.
query
string
The query that determines the auth decision. The result of this query must be either a boolean or an array with boolean as the first element. A boolean true value means that the request will be authorized. Any other value, or error, means that the request will be denied. +kubebuilder:validation:Required +kubebuilder:validation:MinLength=1.
Decreases OPA latency by speeding up conversion of input to the OPA engine. If this is set to true, only http_request and state fields which are a scalar, map, or string array are included in the request input. All other fields are dropped. Dropped fields will not be evaluated by the OPA engine. By default, this is set to false and all fields are evaluated by OPA.
returnDecisionReason
bool
DEPRECATED: It’s recommended to use the dynamic_metadata field within Rego policies to specify the decision reason. To learn more about this approach, see the OPA Envoy Plugin docs. When returnDecisionReason is set to true, the decision reason is stored in the Envoy Dynamic Metadata and has the following properties:
body - a textual explanation of the decision
allowed - whether the request was allowed or rejected
When using OpaAuth, the body field must be the second parameter of the query. Both the OpaAuth and OpaServerAuth approaches use the allowed and body values from the OPA response in the decision reason. You can find the body and allowed fields in the Envoy Filter Dynamic Metadata under the envoy.filters.http.ext_authz.<authentication_step_name>.reason section. If, however, returnDecisionReason is set to false, OPA’s decision to allow or reject a request is made according to the Rego policy rules, and no explanation is provided. Despite of this, the dynamic_metadata field can still be used to convey any necessary information to the Envoy Dynamic Metadata, including the decision reason.
OpaServerAuth
Enforce Open Policy Agent (OPA) policies through an OPA sidecar
to the the Gloo external auth server, or by bringing your own OPA server.
This way, you can use OPA at scale and with additional capabilities, such as bundling or caching.
For smaller operations or quick tests, you might use the OpaAuth setting instead.
The package from your Rego policy bundle used to query the OPA data API. +kubebuilder:validation:Required +kubebuilder:validation:MinLength=1.
ruleName
string
The rule in your Rego policy bundle used to query the OPA data API. Supports querying subfields with a /. For more information, see the OPA docs for the Data API.
serverAddr
string
The address of the OPA server to query, in the format ADDRESS:PORT. For OPA servers within the cluster, the address is the pod’s service address, such as opa-svc.default.svc.cluster.local:8181. For OPA servers outside the cluster, the server must be accessible to the cluster, such as through an ExternalService. If you do not have your own OPA server instance, omit this field. When the external auth service has the OPA server sidecar enabled, the OPA server sidecar will be used instead, with an address such as http://localhost:8181.
Authenticates and authorizes requests by querying an LDAP server. Gloo makes the following assumptions:
Requests provide credentials via the basic HTTP authentication header. Gloo will BIND to the LDAP server using the
credentials extracted from the header.
Your LDAP server is configured so that each entry you want to authorize has an attribute that indicates its group
memberships. A common way of achieving this is by using the memberof overlay.
Address of the LDAP server to query. Should be in the form ADDRESS:PORT, e.g. ldap.default.svc.cluster.local:389. +kubebuilder:validation:Required +kubebuilder:validation:MinLength=1.
userDnTemplate
string
Template to build user entry distinguished names (DN). This must contains a single occurrence of the “%s” placeholder. When processing a request, Gloo will substitute the name of the user (extracted from the auth header) for the placeholder and issue a search request with the resulting DN as baseDN (and ‘base’ search scope). E.g. “uid=%s,ou=people,dc=solo,dc=io”.
membershipAttributeName
string
Case-insensitive name of the attribute that contains the names of the groups an entry is member of. Gloo will look for attributes with the given name to determine which groups the user entry belongs to. Defaults to ‘memberOf’ if not provided.
allowedGroups
[]string
In order for the request to be authenticated, the membership attribute (e.g. memberOf) on the user entry must contain at least of one of the group DNs specified via this option. E.g. []string{ “cn=managers,ou=groups,dc=solo,dc=io”, “cn=developers,ou=groups,dc=solo,dc=io” }.
Use this property to tune the pool of connections to the LDAP server that Gloo maintains.
searchFilter
string
Use to set a custom filter when searching a member. Defaults to “(uid=*)”.
disableGroupChecking
bool
Disables group checking, regardless of the value for allowedGroups, and disables validation for the membership attribute of the user entry. Group checking is enabled by default.
Settings for using a separate service account for looking up group membership To use this, you also need to configure credentials in a secret.
ConnectionPool
Configuration properties for pooling connections to the LDAP server. If the pool is exhausted when a connection
is requested (meaning that all the pooled connections are in use), the connection will be created on the fly.
Custom config to be passed per request to the passthrough auth service.
failureModeAllow
bool
If set to true, the service will accept client request even if the communication with the authorization service has failed, or if the authorization service has returned a server error. Defaults to false.
BackoffStrategy
Configuration defining an exponential back off strategy.
Specifies parameters that control the backoff strategy. This parameter is optional, in which case the default base interval is 1000 milliseconds. The default maximum interval is 10 times the base interval.
Address of the auth server to query. Should be in the form ADDRESS:PORT, e.g. default.svc.cluster.local:389. +kubebuilder:validation:Required +kubebuilder:validation:MinLength=1.
Indicates the retry policy for re-establishing the gRPC stream. This field is optional and failed calls will not retry unless configured.
PassThroughGrpcTLSConfig
TLS configuration for the extauth grpc passthrough connection
Field
Type
Description
PassThroughHttp
Authorizes requests by making a POST HTTP/1 request to a custom HTTP auth server
Assumes the request is authorized if the server returns a OK (200) status code,
else the request is unauthorized.
Required: URL of the passthrough http service, is a fully qualified domain name. Example: http://ext-auth-service.svc.local:9001. Path provided in the URL will be respected. To use https, provide the cert in the HTTPS_PASSTHROUGH_CA_CERT environment variable to the ext-auth-service pod as a base64-encoded string +kubebuilder:validation:Required +kubebuilder:validation:MinLength=1.
Pass through response information such as the headers and body to downstream clients. For more information, see the PassThrough Http Response description.
Timeout for the auth server to respond. Defaults to 5s.
Request
The passthrough http request can be configured to pass through the incoming request body,
the ext-auth state (which is shared between different auth methods within one ext-auth instance), and
the filterMetadata
The body of the passthrough auth request will be a JSON as follows:
{
“body” : string,
“state”: object (map[string]interface{}),
“filterMetadata”: object (map[string]protobuf.Struct),
“config”: object (protobuf.Struct),
}
config is the struct block specified under the passthrough auth configuration.
If passthrough_body, passthrough_state, passthrough_filter_metadata, and config are all false/nil,
the body of the auth request will remain empty. Setting any of these will increase latency slightly due to
JSON marshalling.
These headers will be copied from the incoming request to the request going to the auth server. By default, no headers are copied from the incoming request. Pseudo-headers such as :Path, and :Method can not be specified here.
headersToAdd
map<string, string>
These headers that will be included to the request to authorization service. Note that client request of the same key will be overridden. Pseudo-headers such as :Path, and :Method can not be specified here.
passThroughState
bool
Whether or not to include the ext-auth state object in the passthrough request body. If this is set to true, it is expected that the state is returned in the HTTP response from the passthrough service. The state received from the response will be the state that is shared with other ext-auth service methods. If pass_through_body, pass_through_filter_metadata and pass_through_state are false, the authorization request body will be empty. A non-empty body will increase latency times slightly, so this is set to false by default, and should only be set to to true if the extauth state is needed in the auth request.
passThroughFilterMetadata
bool
Whether or not to include the filter metadata in the passthrough request body. If pass_through_body, pass_through_filter_metadata and pass_through_state are false, the authorization request body will be empty. A non-empty body will increase latency times slightly, so this is set to false by default, and should only be set to to true if the filter metadata is needed in the auth request.
passThroughBody
bool
Whether or not to include the body in the passthrough request body. In order for this to work, the settings.extauth.requestBody must be set in the Gloo Edge Settings CRD so that the request body is buffered and sent to the ext-auth service. If pass_through_body, pass_through_filter_metadata and pass_through_state are false, the authorization request body will be empty. A non-empty body will increase latency times slightly, so this is set to false by default, and should only be set to to true if the request body is needed in the auth request.
When this is set, authorization response headers that have a header in this list will be added to the original client request and sent to the upstream when the auth request is successful. These will be appended to any request headers that already exist. If this and allowed_upstream_headers_to_overwrite are empty, by default, no authorization response headers will be added to the upstream request. Header names may not be included in both allowed_upstream_headers and allowed_upstream_headers_to_overwrite.
allowedClientHeadersOnDenied
[]string
When this is set, authorization response headers in this list will be added to the response to the downstream client when the auth request is denied. If the response header already exists, it will replace the response header. If this is empty, by default, no authorization response headers will be added to the response to the downstream client.
readStateFromResponse
bool
If this is set to true, the body of the response from the http passthrough auth server is expected to have shape { “state”: object (map[string]interface{}) } The state will be marshalled from the response body and this is the state that will be passed on to other auth configs. Because of the marshalling from JSON to Go map, this will add some latency to the request. If the marshalling fails, the authorization check will fail and the request will be unauthorized after the ext-auth-service pod logs the marshal error.
allowedUpstreamHeadersToOverwrite
[]string
When this is set, authorization response headers that have a header in this list will be added to the original client request and sent to the upstream when the auth request is successful. These will overwrite to any request headers that already exist. If this and allowed_upstream_headers are empty, by default, no authorization response headers will be added to the upstream request. Header names may not be included in both allowed_upstream_headers and allowed_upstream_headers_to_overwrite.
PortalAuth
PortalAuth is used to authorize requests for credentials generated by the portal web server.
This API is only supported for Gloo Gateway Portal.
The portal web server url used to validate credentials generated by the portal for the backing service(s).
apiKeyHeader
string
The api key header name used to find the api key in the request headers. If provided will not authorize requests without the api key in the request headers. If not provided, will authorize requests with a Bearer token but must be chained with an AccessTokenValidation AuthConfig which will validate the token.
