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.
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.
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, or hmacAuth 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.
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
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. Only one of oidcAuthorizationCode, accessTokenValidation, or oauth2 can be set.
provide the access token on the request and let gloo handle authorization. according to https://tools.ietf.org/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. Only one of oauth2, oidcAuthorizationCode, or accessTokenValidation can be set.
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.
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://tools.ietf.org/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).
your client secret as registered with the issuer. This is required unless disable_client_secret is true.
issuerUrl
string
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. 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.
callbackPath
string
a callback path relative to app url that will be used for OIDC callbacks. should not be used by the application.
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.
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.
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.
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.
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.
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.
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. 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. Only one of introspection, introspectionUrl, or jwt can be set.
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.
ScopeList
"scope": []string
Field
Type
Description
scope
[]string
OauthSecret
"clientSecret": string
Field
Type
Description
clientSecret
string
ApiKeyAuth
Defines how API keys are validated.
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.
Only one of aerospikeApikeyStorage or k8sSecretApikeyStorage can be set.
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.
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.
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.
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.
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
Return the reason given from the OPA engine after a decision made on this policy. Reason must be the second parameter of the query. The entry will be in the returned DynamicMetadata in the CheckResponse and the structure will be envoy.filters.http.ext_authz: -> name of the auth step, i.e. spec.configs[i].name -> reason.
Ldap
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.
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.
TLS config for the Grpc passthrough, if not configured the connection will use insecure.
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.
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.
ExtAuthConfig
This is an internal API used to share configuration between gloo-ee and extauth. Although this API is only used in gloo-ee,
rules about breaking changes still apply to ensure we do not get errors during upgrade and downgrade.
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.
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.
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.
the cipher config enables the symmetric key encryption of the cookie values of the user session.
CipherConfig
"key": string
Field
Type
Description
key
string
to enable the cipher encryption, the key has to be present. Note that the key has to be found and 32 bytes in length for the authconfig to not be rejected.
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. 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.
we to redirect after successful auth, if we can’t determine the original url this should be your publicly available app url.
callbackPath
string
a callback path relative to app url that will be used for OIDC callbacks. needs to not be used by the application.
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.
scopes
[]string
scopes to request in addition to the openid scope.
OIDC configuration is discovered at /.well-known/openid-configuration The configuration 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
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.
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. 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. Only one of introspection, introspectionUrl, or jwt can be set.
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.
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.
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. If 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.
clientId
string
Your client id as registered with the issuer. Optional: Use if the token introspection url requires client authentication.
clientSecret
string
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.
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.
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.
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.
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. Only one of oidcAuthorizationCode, accessTokenValidationConfig, or oauth2Config can be set.
provide the access token on the request and let gloo handle authorization. according to https://tools.ietf.org/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 accessTokenValidationConfig, oidcAuthorizationCode, or oauth2Config 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. Only one of oauth2Config, oidcAuthorizationCode, or accessTokenValidationConfig can be set.
ApiKeyAuthConfig
NOTE: This configuration is not user-facing and will be auto generated
A mapping of valid API keys to their associated metadata. This map is automatically populated with the information from the relevant ApiKeys.
headerName
string
(Optional) 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.
headersFromKeyMetadata
map<string, string>
Determines the key metadata that will be included as headers on the upstream request. Each entry represents a header to add: the key is the name of the header, and the value is the key that will be used to look up the data entry in the key metadata.
An optional modules (filename, module content) maps containing modules 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.
Address of the LDAP server to query. Should be in the form ADDRESS:PORT, e.g. ldap.default.svc.cluster.local:389.
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.
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.
Used for LDAP configurations that need service account credentials saved in a secret. Only one of ldapInternal, oauth, oauth2, basicAuth, apiKeyAuth, pluginAuth, opaAuth, ldap, jwt, passThroughAuth, or hmacAuth 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, oauth, oauth2, basicAuth, apiKeyAuth, pluginAuth, opaAuth, ldap, ldapInternal, passThroughAuth, or hmacAuth can be set.
