Last changed in Agentgateway v1.2.0
APIVersion defines the versioned schema of this representation of an object. Servers should convert recognized schemas to the latest internal value, and may reject unrecognized values. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#resources
Kind is a string value representing the REST resource this object represents. Servers may infer this from the endpoint the client submits requests to. Cannot be updated. In CamelCase. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#types-kinds
spec defines the desired state of AgentgatewayBackend.
ai represents a LLM backend.
`groups` specifies a list of groups in priority order where each group defines a set of LLM providers. The priority determines the priority of the backend endpoints chosen. Note: provider names must be unique across all providers in all priority groups. Backend policies may target a specific provider by name using `targetRefs[].sectionName`. Example configuration with two priority groups: groups: - providers: - azureopenai: deploymentName: gpt-4o-mini apiVersion: 2024-02-15-preview endpoint: ai-gateway.openai.azure.com - providers: - azureopenai: deploymentName: gpt-4o-mini-2 apiVersion: 2024-02-15-preview endpoint: ai-gateway-2.openai.azure.com policies: auth: secretRef: name: azure-secret
providers specifies a list of LLM providers within this group. Each provider is treated equally in terms of priority, with automatic weighting based on health.
Anthropic provider
Optional: Override the model name, such as `gpt-4o-mini`. If unset, the model name is taken from the request.
Azure provider with resource-based configuration. Supports both Azure OpenAI and Azure AI Foundry resource types.
The version of the Azure OpenAI API to use. If unset, defaults to `v1`.
Optional: Override the model name, such as `gpt-4o-mini`. If unset, the model name is taken from the request.
The Foundry project name, required when `resourceType` is `Foundry`. Used to construct paths: /api/projects/{projectName}/openai/v1/...
The Azure resource name used to construct the endpoint host. For OpenAI: {resourceName}.openai.azure.com For Foundry: {resourceName}-resource.services.ai.azure.com
The type of Azure endpoint. Determines the host suffix.
Azure OpenAI provider
The version of the Azure OpenAI API to use. For more information, see the [Azure OpenAI API version reference](https://learn.microsoft.com/en-us/azure/foundry/openai/reference). If unset, defaults to `v1`.
The name of the Azure OpenAI model deployment to use. For more information, see the [Azure OpenAI model docs](https://learn.microsoft.com/en-us/azure/foundry/foundry-models/concepts/models-sold-directly-by-azure?view=foundry-classic). This is required if `apiVersion` is not `v1`. For `v1`, the model can be set in the request.
The endpoint for the Azure OpenAI API to use, such as `my-endpoint.openai.azure.com`. If the scheme is included, it is stripped.
Bedrock provider
`guardrail` configures the Guardrail policy to use for the backend. See <https://docs.aws.amazon.com/bedrock/latest/userguide/guardrails.html>. If not specified, the AWS Guardrail policy will not be used.
GuardrailIdentifier is the identifier of the Guardrail policy to use for the backend.
GuardrailVersion is the version of the Guardrail policy to use for the backend.
Optional: Override the model name, such as `gpt-4o-mini`. If unset, the model name is taken from the request.
Region is the AWS region to use for the backend. Defaults to `us-east-1` if not specified.
Gemini provider
Optional: Override the model name, such as `gemini-2.5-pro`. If unset, the model name is taken from the request.
Host specifies the hostname to send the requests to. If not specified, the default hostname for the provider is used.
Name of the provider. Policies can target this provider by name.
OpenAI provider
Optional: Override the model name, such as `gpt-4o-mini`. If unset, the model name is taken from the request.
Path specifies the URL path to use for the LLM provider API requests. This is useful when you need to route requests to a different API endpoint while maintaining compatibility with the original provider's API structure. If not specified, the default path for the provider is used.
PathPrefix overrides the default base path prefix (e.g. "/v1") for upstream requests. Path translation for cross-format requests still applies using this prefix. Only supported for OpenAI and Anthropic providers.
`policies` controls policies for communicating with this backend. Policies may also be set in `AgentgatewayPolicy`, or in the top-level `AgentgatewayBackend`. Policies are merged on a field-level basis, with order: `AgentgatewayPolicy` < `AgentgatewayBackend` < `AgentgatewayBackend` LLM provider (this field).
`ai` specifies settings for AI workloads. This is only applicable when connecting to a `Backend` of type `ai`.
Provide defaults to merge with user input fields. If the field is already set, the field in the request is used.
The name of the field.
The field default value, which can be any JSON Data Type.
ModelAliases maps friendly model names to actual provider model names. Example: `{"fast": "gpt-3.5-turbo", "smart": "gpt-4-turbo"}`. Note: This field is only applicable when using the agentgateway data plane.
Provide overrides to merge with user input fields. If the field is already set, the field will be overwritten.
The name of the field.
The field default value, which can be any JSON Data Type.
Enrich requests sent to the LLM provider by appending and prepending system prompts. This can be configured only for LLM providers that use the `CHAT` or `CHAT_STREAMING` API route type.
A list of messages to be appended to the prompt sent by the client.
String content of the message.
Role of the message. The available roles depend on the backend LLM provider model, such as `SYSTEM` or `USER` in the OpenAI API.
A list of messages to be prepended to the prompt sent by the client.
String content of the message.
Role of the message. The available roles depend on the backend LLM provider model, such as `SYSTEM` or `USER` in the OpenAI API.
`promptCaching` enables automatic prompt caching for supported providers, currently AWS Bedrock. Reduces API costs by caching static content like system prompts and tool definitions. Only applicable for Bedrock Claude 3+ and Nova models.
CacheMessageOffset shifts the message cache point further back in the conversation. 0 (default) places it at the second-to-last message. Higher values move it N additional messages towards the start, clamped to bounds.
CacheMessages enables caching for conversation messages. Caches all messages in the conversation for cost savings.
CacheSystem enables caching for system prompts. Inserts a cache point after all system messages.
CacheTools enables caching for tool definitions. Inserts a cache point after all tool specifications.
MinTokens specifies the minimum estimated token count before caching is enabled. Uses rough heuristic (word count × 1.3) to estimate tokens. Bedrock requires at least 1,024 tokens for caching to be effective.
`promptGuard` enables adding guardrails to LLM requests and responses.
Prompt guards to apply to requests sent by the client.
`bedrockGuardrails` configures AWS Bedrock Guardrails for prompt guarding.
GuardrailIdentifier is the identifier of the Guardrail policy to use for the backend.
policies controls policies for communicating with AWS Bedrock Guardrails.
`auth` defines settings for managing authentication to the backend.
Auth specifies an explicit AWS authentication method for the backend. When omitted, we will try to use the default AWS SDK authentication methods.
`secretRef` references a Kubernetes `Secret` containing the AWS credentials. The `Secret` must have keys `accessKey`, `secretKey`, and optionally `sessionToken`.
Name of the referent. This field is effectively required, but due to backwards compatibility is allowed to be empty. Instances of this type with an empty value here are almost certainly wrong. More info: https://kubernetes.io/docs/concepts/overview/working-with-objects/names/#names
Azure specifies an Azure authentication method for the backend.
Details for managed identity authentication
`secretRef` references a Kubernetes `Secret` containing the Azure credentials. The `Secret` must have keys `clientID`, `tenantID`, and `clientSecret`.
Name of the referent. This field is effectively required, but due to backwards compatibility is allowed to be empty. Instances of this type with an empty value here are almost certainly wrong. More info: https://kubernetes.io/docs/concepts/overview/working-with-objects/names/#names
Auth specifies to use a Google authentication method for the backend. When omitted, we will try to use the default AWS SDK authentication methods.
`audience` allows explicitly configuring the `aud` of the ID token. Only valid with `IdToken` type. If not set, the `aud` is automatically derived from the backend hostname.
`secretRef` references a Kubernetes `Secret` containing ADC-compatible Google credential JSON in the `credentials.json` key. When omitted, ambient credentials are used.
Name of the referent. This field is effectively required, but due to backwards compatibility is allowed to be empty. Instances of this type with an empty value here are almost certainly wrong. More info: https://kubernetes.io/docs/concepts/overview/working-with-objects/names/#names
The type of token to generate. To authenticate to GCP services, generally an `AccessToken` is used. To authenticate to Cloud Run, an `IdToken` is used.
`key` provides an inline key to use as the value of the `Authorization` header. This option is the least secure; usage of a `Secret` is preferred.
`location` controls where backend credentials are inserted. If omitted, credentials are written to the `Authorization` header with the `Bearer ` prefix. This applies to `key`, `secretRef`, and `passthrough`.
HTTPHeaderName is the name of an HTTP header. Valid values include: * "Authorization" * "Set-Cookie" Invalid values include: - ":method" - ":" is an invalid character. This means that HTTP/2 pseudo headers are not currently supported by this type. - "/invalid" - "/ " is an invalid character
`passthrough` passes through an existing token that has been sent by the client and validated. Other policies, like JWT and API key authentication, will strip the original client credentials. Passthrough backend authentication causes the original token to be added back into the request. If there are no client authentication policies on the request, the original token would be unchanged, so this would have no effect.
`secretRef` references a Kubernetes `Secret` storing the key to use as the authorization value. This must be stored in the `Authorization` key.
Name of the referent. This field is effectively required, but due to backwards compatibility is allowed to be empty. Instances of this type with an empty value here are almost certainly wrong. More info: https://kubernetes.io/docs/concepts/overview/working-with-objects/names/#names
http defines settings for managing HTTP requests to the backend.
requestTimeout specifies the deadline for receiving a response from the backend.
`version` specifies the HTTP protocol version to use when connecting to the backend. If not specified, the version is automatically determined: * `Service` types can specify it with `appProtocol` on the `Service` port. * If traffic is identified as gRPC, `HTTP2` is used. * If the incoming traffic was plaintext HTTP, the original protocol will be used. * If the incoming traffic was HTTPS, `HTTP1` will be used. This is because most clients will transparently upgrade HTTPS traffic to `HTTP2`, even if the backend doesn't support it.
tcp defines settings for managing TCP connections to the backend.
`connectTimeout` defines the deadline for establishing a connection to the destination.
`keepAlive` defines settings for enabling TCP keepalives on the connection.
interval specifies the number of seconds between keep-alive probes. If unset, this defaults to 180s.
retries specifies the maximum number of keep-alive probes to send before dropping the connection. If unset, this defaults to 9.
time specifies the number of seconds a connection needs to be idle before keep-alive probes start being sent. If unset, this defaults to 180s.
tls defines settings for managing TLS connections to the backend. If this field is set, TLS will be initiated to the backend; the system trusted CA certificates will be used to validate the server, and the SNI will automatically be set based on the destination.
`alpnProtocols` sets the Application-Layer Protocol Negotiation (`ALPN`) value to use in the TLS handshake. If not present, defaults to `["h2", "http/1.1"]`.
`caCertificateRefs` defines the CA certificate `ConfigMap` to use to verify the server certificate. If unset, the system's trusted certificates are used.
Name of the referent. This field is effectively required, but due to backwards compatibility is allowed to be empty. Instances of this type with an empty value here are almost certainly wrong. More info: https://kubernetes.io/docs/concepts/overview/working-with-objects/names/#names
insecureSkipVerify originates TLS but skips verification of the backend's certificate. WARNING: This is an insecure option that should only be used if the risks are understood. There are two modes: * `All` disables all TLS verification. * `Hostname` verifies the CA certificate is trusted, but ignores any mismatch of hostname or SANs. Note that this method is still insecure; prefer setting `verifySubjectAltNames` to customize the valid hostnames if possible.
keyExchangeGroups configures the ordered list of key exchange groups for a TLS connection. For example: `X25519_MLKEM768,X25519`.
`mtlsCertificateRef` enables mutual TLS to the backend, using the specified key (`tls.key`) and cert (`tls.crt`) from the referenced `Secret`. An optional `ca.cert` field, if present, will be used to verify the server certificate. If `caCertificateRefs` is also specified, the `caCertificateRefs` field takes priority. If unspecified, no client certificate will be used.
Name of the referent. This field is effectively required, but due to backwards compatibility is allowed to be empty. Instances of this type with an empty value here are almost certainly wrong. More info: https://kubernetes.io/docs/concepts/overview/working-with-objects/names/#names
`sni` specifies the Server Name Indicator (`SNI`) to be used in the TLS handshake. If unset, the `SNI` is automatically set based on the destination hostname.
`verifySubjectAltNames` specifies the Subject Alternative Names (`SAN`) to verify in the server certificate. If not present, the destination hostname is automatically used.
`tunnel` defines settings for managing tunnel connections (with behavior like `HTTPS_PROXY`) to the backend.
`backendRef` references the proxy server to reach. Supported types: `Service` and `Backend`.
Group is the group of the referent. For example, "gateway.networking.k8s.io". When unspecified or empty string, core API group is inferred.
Kind is the Kubernetes resource kind of the referent. For example "Service". Defaults to "Service" when not specified. ExternalName services can refer to CNAME DNS records that may live outside of the cluster and as such are difficult to reason about in terms of conformance. They also may not be safe to forward to (see CVE-2021-25740 for more information). Implementations SHOULD NOT support ExternalName Services. Support: Core (Services with a type other than ExternalName) Support: Implementation-specific (Services with type ExternalName)
Name is the name of the referent.
Namespace is the namespace of the backend. When unspecified, the local namespace is inferred. Note that when a namespace different than the local namespace is specified, a ReferenceGrant object is required in the referent namespace to allow that namespace's owner to accept the reference. See the ReferenceGrant documentation for details. Support: Core
Port specifies the destination port number to use for this resource. Port is required when the referent is a Kubernetes Service. In this case, the port number is the service port number, not the target port. For other resources, destination port might be derived from the referent resource or this field.
Region is the AWS region where the guardrail is deployed (for example, `us-west-2`).
GuardrailVersion is the version of the Guardrail policy to use for the backend.
`googleModelArmor` configures Google Model Armor for prompt guarding.
Location is the Google Cloud location (for example, `us-central1`). Defaults to `us-central1` if not specified.
policies controls policies for communicating with Google Model Armor.
`auth` defines settings for managing authentication to the backend.
Auth specifies an explicit AWS authentication method for the backend. When omitted, we will try to use the default AWS SDK authentication methods.
`secretRef` references a Kubernetes `Secret` containing the AWS credentials. The `Secret` must have keys `accessKey`, `secretKey`, and optionally `sessionToken`.
Name of the referent. This field is effectively required, but due to backwards compatibility is allowed to be empty. Instances of this type with an empty value here are almost certainly wrong. More info: https://kubernetes.io/docs/concepts/overview/working-with-objects/names/#names
Azure specifies an Azure authentication method for the backend.
Details for managed identity authentication
`secretRef` references a Kubernetes `Secret` containing the Azure credentials. The `Secret` must have keys `clientID`, `tenantID`, and `clientSecret`.
Name of the referent. This field is effectively required, but due to backwards compatibility is allowed to be empty. Instances of this type with an empty value here are almost certainly wrong. More info: https://kubernetes.io/docs/concepts/overview/working-with-objects/names/#names
Auth specifies to use a Google authentication method for the backend. When omitted, we will try to use the default AWS SDK authentication methods.
`audience` allows explicitly configuring the `aud` of the ID token. Only valid with `IdToken` type. If not set, the `aud` is automatically derived from the backend hostname.
`secretRef` references a Kubernetes `Secret` containing ADC-compatible Google credential JSON in the `credentials.json` key. When omitted, ambient credentials are used.
Name of the referent. This field is effectively required, but due to backwards compatibility is allowed to be empty. Instances of this type with an empty value here are almost certainly wrong. More info: https://kubernetes.io/docs/concepts/overview/working-with-objects/names/#names
The type of token to generate. To authenticate to GCP services, generally an `AccessToken` is used. To authenticate to Cloud Run, an `IdToken` is used.
`key` provides an inline key to use as the value of the `Authorization` header. This option is the least secure; usage of a `Secret` is preferred.
`location` controls where backend credentials are inserted. If omitted, credentials are written to the `Authorization` header with the `Bearer ` prefix. This applies to `key`, `secretRef`, and `passthrough`.
HTTPHeaderName is the name of an HTTP header. Valid values include: * "Authorization" * "Set-Cookie" Invalid values include: - ":method" - ":" is an invalid character. This means that HTTP/2 pseudo headers are not currently supported by this type. - "/invalid" - "/ " is an invalid character
`passthrough` passes through an existing token that has been sent by the client and validated. Other policies, like JWT and API key authentication, will strip the original client credentials. Passthrough backend authentication causes the original token to be added back into the request. If there are no client authentication policies on the request, the original token would be unchanged, so this would have no effect.
`secretRef` references a Kubernetes `Secret` storing the key to use as the authorization value. This must be stored in the `Authorization` key.
Name of the referent. This field is effectively required, but due to backwards compatibility is allowed to be empty. Instances of this type with an empty value here are almost certainly wrong. More info: https://kubernetes.io/docs/concepts/overview/working-with-objects/names/#names
http defines settings for managing HTTP requests to the backend.
requestTimeout specifies the deadline for receiving a response from the backend.
`version` specifies the HTTP protocol version to use when connecting to the backend. If not specified, the version is automatically determined: * `Service` types can specify it with `appProtocol` on the `Service` port. * If traffic is identified as gRPC, `HTTP2` is used. * If the incoming traffic was plaintext HTTP, the original protocol will be used. * If the incoming traffic was HTTPS, `HTTP1` will be used. This is because most clients will transparently upgrade HTTPS traffic to `HTTP2`, even if the backend doesn't support it.
tcp defines settings for managing TCP connections to the backend.
`connectTimeout` defines the deadline for establishing a connection to the destination.
`keepAlive` defines settings for enabling TCP keepalives on the connection.
interval specifies the number of seconds between keep-alive probes. If unset, this defaults to 180s.
retries specifies the maximum number of keep-alive probes to send before dropping the connection. If unset, this defaults to 9.
time specifies the number of seconds a connection needs to be idle before keep-alive probes start being sent. If unset, this defaults to 180s.
tls defines settings for managing TLS connections to the backend. If this field is set, TLS will be initiated to the backend; the system trusted CA certificates will be used to validate the server, and the SNI will automatically be set based on the destination.
`alpnProtocols` sets the Application-Layer Protocol Negotiation (`ALPN`) value to use in the TLS handshake. If not present, defaults to `["h2", "http/1.1"]`.
`caCertificateRefs` defines the CA certificate `ConfigMap` to use to verify the server certificate. If unset, the system's trusted certificates are used.
Name of the referent. This field is effectively required, but due to backwards compatibility is allowed to be empty. Instances of this type with an empty value here are almost certainly wrong. More info: https://kubernetes.io/docs/concepts/overview/working-with-objects/names/#names
insecureSkipVerify originates TLS but skips verification of the backend's certificate. WARNING: This is an insecure option that should only be used if the risks are understood. There are two modes: * `All` disables all TLS verification. * `Hostname` verifies the CA certificate is trusted, but ignores any mismatch of hostname or SANs. Note that this method is still insecure; prefer setting `verifySubjectAltNames` to customize the valid hostnames if possible.
keyExchangeGroups configures the ordered list of key exchange groups for a TLS connection. For example: `X25519_MLKEM768,X25519`.
`mtlsCertificateRef` enables mutual TLS to the backend, using the specified key (`tls.key`) and cert (`tls.crt`) from the referenced `Secret`. An optional `ca.cert` field, if present, will be used to verify the server certificate. If `caCertificateRefs` is also specified, the `caCertificateRefs` field takes priority. If unspecified, no client certificate will be used.
Name of the referent. This field is effectively required, but due to backwards compatibility is allowed to be empty. Instances of this type with an empty value here are almost certainly wrong. More info: https://kubernetes.io/docs/concepts/overview/working-with-objects/names/#names
`sni` specifies the Server Name Indicator (`SNI`) to be used in the TLS handshake. If unset, the `SNI` is automatically set based on the destination hostname.
`verifySubjectAltNames` specifies the Subject Alternative Names (`SAN`) to verify in the server certificate. If not present, the destination hostname is automatically used.
`tunnel` defines settings for managing tunnel connections (with behavior like `HTTPS_PROXY`) to the backend.
`backendRef` references the proxy server to reach. Supported types: `Service` and `Backend`.
Group is the group of the referent. For example, "gateway.networking.k8s.io". When unspecified or empty string, core API group is inferred.
Kind is the Kubernetes resource kind of the referent. For example "Service". Defaults to "Service" when not specified. ExternalName services can refer to CNAME DNS records that may live outside of the cluster and as such are difficult to reason about in terms of conformance. They also may not be safe to forward to (see CVE-2021-25740 for more information). Implementations SHOULD NOT support ExternalName Services. Support: Core (Services with a type other than ExternalName) Support: Implementation-specific (Services with type ExternalName)
Name is the name of the referent.
Namespace is the namespace of the backend. When unspecified, the local namespace is inferred. Note that when a namespace different than the local namespace is specified, a ReferenceGrant object is required in the referent namespace to allow that namespace's owner to accept the reference. See the ReferenceGrant documentation for details. Support: Core
Port specifies the destination port number to use for this resource. Port is required when the referent is a Kubernetes Service. In this case, the port number is the service port number, not the target port. For other resources, destination port might be derived from the referent resource or this field.
ProjectID is the Google Cloud project ID.
TemplateID is the template ID for Google Model Armor.
`openAIModeration` passes prompt data through the OpenAI Moderations endpoint. See https://developers.openai.com/api/reference/resources/moderations for more information.
`model` specifies the moderation model to use. For example, `omni-moderation`.
policies controls policies for communicating with OpenAI.
`auth` defines settings for managing authentication to the backend.
Auth specifies an explicit AWS authentication method for the backend. When omitted, we will try to use the default AWS SDK authentication methods.
`secretRef` references a Kubernetes `Secret` containing the AWS credentials. The `Secret` must have keys `accessKey`, `secretKey`, and optionally `sessionToken`.
Name of the referent. This field is effectively required, but due to backwards compatibility is allowed to be empty. Instances of this type with an empty value here are almost certainly wrong. More info: https://kubernetes.io/docs/concepts/overview/working-with-objects/names/#names
Azure specifies an Azure authentication method for the backend.
Details for managed identity authentication
`secretRef` references a Kubernetes `Secret` containing the Azure credentials. The `Secret` must have keys `clientID`, `tenantID`, and `clientSecret`.
Name of the referent. This field is effectively required, but due to backwards compatibility is allowed to be empty. Instances of this type with an empty value here are almost certainly wrong. More info: https://kubernetes.io/docs/concepts/overview/working-with-objects/names/#names
Auth specifies to use a Google authentication method for the backend. When omitted, we will try to use the default AWS SDK authentication methods.
`audience` allows explicitly configuring the `aud` of the ID token. Only valid with `IdToken` type. If not set, the `aud` is automatically derived from the backend hostname.
`secretRef` references a Kubernetes `Secret` containing ADC-compatible Google credential JSON in the `credentials.json` key. When omitted, ambient credentials are used.
Name of the referent. This field is effectively required, but due to backwards compatibility is allowed to be empty. Instances of this type with an empty value here are almost certainly wrong. More info: https://kubernetes.io/docs/concepts/overview/working-with-objects/names/#names
The type of token to generate. To authenticate to GCP services, generally an `AccessToken` is used. To authenticate to Cloud Run, an `IdToken` is used.
`key` provides an inline key to use as the value of the `Authorization` header. This option is the least secure; usage of a `Secret` is preferred.
`location` controls where backend credentials are inserted. If omitted, credentials are written to the `Authorization` header with the `Bearer ` prefix. This applies to `key`, `secretRef`, and `passthrough`.
HTTPHeaderName is the name of an HTTP header. Valid values include: * "Authorization" * "Set-Cookie" Invalid values include: - ":method" - ":" is an invalid character. This means that HTTP/2 pseudo headers are not currently supported by this type. - "/invalid" - "/ " is an invalid character
`passthrough` passes through an existing token that has been sent by the client and validated. Other policies, like JWT and API key authentication, will strip the original client credentials. Passthrough backend authentication causes the original token to be added back into the request. If there are no client authentication policies on the request, the original token would be unchanged, so this would have no effect.
`secretRef` references a Kubernetes `Secret` storing the key to use as the authorization value. This must be stored in the `Authorization` key.
Name of the referent. This field is effectively required, but due to backwards compatibility is allowed to be empty. Instances of this type with an empty value here are almost certainly wrong. More info: https://kubernetes.io/docs/concepts/overview/working-with-objects/names/#names
http defines settings for managing HTTP requests to the backend.
requestTimeout specifies the deadline for receiving a response from the backend.
`version` specifies the HTTP protocol version to use when connecting to the backend. If not specified, the version is automatically determined: * `Service` types can specify it with `appProtocol` on the `Service` port. * If traffic is identified as gRPC, `HTTP2` is used. * If the incoming traffic was plaintext HTTP, the original protocol will be used. * If the incoming traffic was HTTPS, `HTTP1` will be used. This is because most clients will transparently upgrade HTTPS traffic to `HTTP2`, even if the backend doesn't support it.
tcp defines settings for managing TCP connections to the backend.
`connectTimeout` defines the deadline for establishing a connection to the destination.
`keepAlive` defines settings for enabling TCP keepalives on the connection.
interval specifies the number of seconds between keep-alive probes. If unset, this defaults to 180s.
retries specifies the maximum number of keep-alive probes to send before dropping the connection. If unset, this defaults to 9.
time specifies the number of seconds a connection needs to be idle before keep-alive probes start being sent. If unset, this defaults to 180s.
tls defines settings for managing TLS connections to the backend. If this field is set, TLS will be initiated to the backend; the system trusted CA certificates will be used to validate the server, and the SNI will automatically be set based on the destination.
`alpnProtocols` sets the Application-Layer Protocol Negotiation (`ALPN`) value to use in the TLS handshake. If not present, defaults to `["h2", "http/1.1"]`.
`caCertificateRefs` defines the CA certificate `ConfigMap` to use to verify the server certificate. If unset, the system's trusted certificates are used.
Name of the referent. This field is effectively required, but due to backwards compatibility is allowed to be empty. Instances of this type with an empty value here are almost certainly wrong. More info: https://kubernetes.io/docs/concepts/overview/working-with-objects/names/#names
insecureSkipVerify originates TLS but skips verification of the backend's certificate. WARNING: This is an insecure option that should only be used if the risks are understood. There are two modes: * `All` disables all TLS verification. * `Hostname` verifies the CA certificate is trusted, but ignores any mismatch of hostname or SANs. Note that this method is still insecure; prefer setting `verifySubjectAltNames` to customize the valid hostnames if possible.
keyExchangeGroups configures the ordered list of key exchange groups for a TLS connection. For example: `X25519_MLKEM768,X25519`.
`mtlsCertificateRef` enables mutual TLS to the backend, using the specified key (`tls.key`) and cert (`tls.crt`) from the referenced `Secret`. An optional `ca.cert` field, if present, will be used to verify the server certificate. If `caCertificateRefs` is also specified, the `caCertificateRefs` field takes priority. If unspecified, no client certificate will be used.
Name of the referent. This field is effectively required, but due to backwards compatibility is allowed to be empty. Instances of this type with an empty value here are almost certainly wrong. More info: https://kubernetes.io/docs/concepts/overview/working-with-objects/names/#names
`sni` specifies the Server Name Indicator (`SNI`) to be used in the TLS handshake. If unset, the `SNI` is automatically set based on the destination hostname.
`verifySubjectAltNames` specifies the Subject Alternative Names (`SAN`) to verify in the server certificate. If not present, the destination hostname is automatically used.
`tunnel` defines settings for managing tunnel connections (with behavior like `HTTPS_PROXY`) to the backend.
`backendRef` references the proxy server to reach. Supported types: `Service` and `Backend`.
Group is the group of the referent. For example, "gateway.networking.k8s.io". When unspecified or empty string, core API group is inferred.
Kind is the Kubernetes resource kind of the referent. For example "Service". Defaults to "Service" when not specified. ExternalName services can refer to CNAME DNS records that may live outside of the cluster and as such are difficult to reason about in terms of conformance. They also may not be safe to forward to (see CVE-2021-25740 for more information). Implementations SHOULD NOT support ExternalName Services. Support: Core (Services with a type other than ExternalName) Support: Implementation-specific (Services with type ExternalName)
Name is the name of the referent.
Namespace is the namespace of the backend. When unspecified, the local namespace is inferred. Note that when a namespace different than the local namespace is specified, a ReferenceGrant object is required in the referent namespace to allow that namespace's owner to accept the reference. See the ReferenceGrant documentation for details. Support: Core
Port specifies the destination port number to use for this resource. Port is required when the referent is a Kubernetes Service. In this case, the port number is the service port number, not the target port. For other resources, destination port might be derived from the referent resource or this field.
Regular expression (regex) matching for prompt guards and data masking.
The action to take if a regex pattern is matched in a request or response. This setting applies only to request matches. `PromptguardResponse` matches are always masked by default. Defaults to `Mask`.
A list of built-in regex patterns to match against the request or response. Matches and built-ins are additive.
A list of regex patterns to match against the request or response. Matches and built-ins are additive.
A custom response message to return to the client. If not specified, defaults to `The request was rejected due to inappropriate content`.
A custom response message to return to the client. If not specified, defaults to `The request was rejected due to inappropriate content`.
The status code to return to the client. Defaults to 403.
Configure a webhook to forward requests to for prompt guarding.
backendRef references the webhook server to reach. Supported types: Service and Backend.
Group is the group of the referent. For example, "gateway.networking.k8s.io". When unspecified or empty string, core API group is inferred.
Kind is the Kubernetes resource kind of the referent. For example "Service". Defaults to "Service" when not specified. ExternalName services can refer to CNAME DNS records that may live outside of the cluster and as such are difficult to reason about in terms of conformance. They also may not be safe to forward to (see CVE-2021-25740 for more information). Implementations SHOULD NOT support ExternalName Services. Support: Core (Services with a type other than ExternalName) Support: Implementation-specific (Services with type ExternalName)
Name is the name of the referent.
Namespace is the namespace of the backend. When unspecified, the local namespace is inferred. Note that when a namespace different than the local namespace is specified, a ReferenceGrant object is required in the referent namespace to allow that namespace's owner to accept the reference. See the ReferenceGrant documentation for details. Support: Core
Port specifies the destination port number to use for this resource. Port is required when the referent is a Kubernetes Service. In this case, the port number is the service port number, not the target port. For other resources, destination port might be derived from the referent resource or this field.
ForwardHeaderMatches defines a list of HTTP header matches that will be used to select the headers to forward to the webhook. Request headers are used when forwarding requests and response headers are used when forwarding responses. By default, no headers are forwarded.
Name is the name of the HTTP Header to be matched. Name matching MUST be case-insensitive. (See https://tools.ietf.org/html/rfc7230#section-3.2). If multiple entries specify equivalent header names, only the first entry with an equivalent name MUST be considered for a match. Subsequent entries with an equivalent header name MUST be ignored. Due to the case-insensitivity of header names, "foo" and "Foo" are considered equivalent. When a header is repeated in an HTTP request, it is implementation-specific behavior as to how this is represented. Generally, proxies should follow the guidance from the RFC: https://www.rfc-editor.org/rfc/rfc7230.html#section-3.2.2 regarding processing a repeated header, with special handling for "Set-Cookie".
Type specifies how to match against the value of the header. Support: Core (Exact) Support: Implementation-specific (RegularExpression) Since RegularExpression HeaderMatchType has implementation-specific conformance, implementations can support POSIX, PCRE or any other dialects of regular expressions. Please read the implementation's documentation to determine the supported dialect.
Value is the value of HTTP Header to be matched. <gateway:experimental:description> Must consist of printable US-ASCII characters, optionally separated by single tabs or spaces. See: https://tools.ietf.org/html/rfc7230#section-3.2 </gateway:experimental:description> <gateway:experimental:validation:Pattern=`^[!-~]+([\t ]?[!-~]+)*$`>
Prompt guards to apply to responses returned by the LLM provider.
`bedrockGuardrails` configures AWS Bedrock Guardrails for prompt guarding.
GuardrailIdentifier is the identifier of the Guardrail policy to use for the backend.
policies controls policies for communicating with AWS Bedrock Guardrails.
`auth` defines settings for managing authentication to the backend.
Auth specifies an explicit AWS authentication method for the backend. When omitted, we will try to use the default AWS SDK authentication methods.
`secretRef` references a Kubernetes `Secret` containing the AWS credentials. The `Secret` must have keys `accessKey`, `secretKey`, and optionally `sessionToken`.
Name of the referent. This field is effectively required, but due to backwards compatibility is allowed to be empty. Instances of this type with an empty value here are almost certainly wrong. More info: https://kubernetes.io/docs/concepts/overview/working-with-objects/names/#names
Azure specifies an Azure authentication method for the backend.
Details for managed identity authentication
`secretRef` references a Kubernetes `Secret` containing the Azure credentials. The `Secret` must have keys `clientID`, `tenantID`, and `clientSecret`.
Name of the referent. This field is effectively required, but due to backwards compatibility is allowed to be empty. Instances of this type with an empty value here are almost certainly wrong. More info: https://kubernetes.io/docs/concepts/overview/working-with-objects/names/#names
Auth specifies to use a Google authentication method for the backend. When omitted, we will try to use the default AWS SDK authentication methods.
`audience` allows explicitly configuring the `aud` of the ID token. Only valid with `IdToken` type. If not set, the `aud` is automatically derived from the backend hostname.
`secretRef` references a Kubernetes `Secret` containing ADC-compatible Google credential JSON in the `credentials.json` key. When omitted, ambient credentials are used.
Name of the referent. This field is effectively required, but due to backwards compatibility is allowed to be empty. Instances of this type with an empty value here are almost certainly wrong. More info: https://kubernetes.io/docs/concepts/overview/working-with-objects/names/#names
The type of token to generate. To authenticate to GCP services, generally an `AccessToken` is used. To authenticate to Cloud Run, an `IdToken` is used.
`key` provides an inline key to use as the value of the `Authorization` header. This option is the least secure; usage of a `Secret` is preferred.
`location` controls where backend credentials are inserted. If omitted, credentials are written to the `Authorization` header with the `Bearer ` prefix. This applies to `key`, `secretRef`, and `passthrough`.
HTTPHeaderName is the name of an HTTP header. Valid values include: * "Authorization" * "Set-Cookie" Invalid values include: - ":method" - ":" is an invalid character. This means that HTTP/2 pseudo headers are not currently supported by this type. - "/invalid" - "/ " is an invalid character
`passthrough` passes through an existing token that has been sent by the client and validated. Other policies, like JWT and API key authentication, will strip the original client credentials. Passthrough backend authentication causes the original token to be added back into the request. If there are no client authentication policies on the request, the original token would be unchanged, so this would have no effect.
`secretRef` references a Kubernetes `Secret` storing the key to use as the authorization value. This must be stored in the `Authorization` key.
Name of the referent. This field is effectively required, but due to backwards compatibility is allowed to be empty. Instances of this type with an empty value here are almost certainly wrong. More info: https://kubernetes.io/docs/concepts/overview/working-with-objects/names/#names
http defines settings for managing HTTP requests to the backend.
requestTimeout specifies the deadline for receiving a response from the backend.
`version` specifies the HTTP protocol version to use when connecting to the backend. If not specified, the version is automatically determined: * `Service` types can specify it with `appProtocol` on the `Service` port. * If traffic is identified as gRPC, `HTTP2` is used. * If the incoming traffic was plaintext HTTP, the original protocol will be used. * If the incoming traffic was HTTPS, `HTTP1` will be used. This is because most clients will transparently upgrade HTTPS traffic to `HTTP2`, even if the backend doesn't support it.
tcp defines settings for managing TCP connections to the backend.
`connectTimeout` defines the deadline for establishing a connection to the destination.
`keepAlive` defines settings for enabling TCP keepalives on the connection.
interval specifies the number of seconds between keep-alive probes. If unset, this defaults to 180s.
retries specifies the maximum number of keep-alive probes to send before dropping the connection. If unset, this defaults to 9.
time specifies the number of seconds a connection needs to be idle before keep-alive probes start being sent. If unset, this defaults to 180s.
tls defines settings for managing TLS connections to the backend. If this field is set, TLS will be initiated to the backend; the system trusted CA certificates will be used to validate the server, and the SNI will automatically be set based on the destination.
`alpnProtocols` sets the Application-Layer Protocol Negotiation (`ALPN`) value to use in the TLS handshake. If not present, defaults to `["h2", "http/1.1"]`.
`caCertificateRefs` defines the CA certificate `ConfigMap` to use to verify the server certificate. If unset, the system's trusted certificates are used.
Name of the referent. This field is effectively required, but due to backwards compatibility is allowed to be empty. Instances of this type with an empty value here are almost certainly wrong. More info: https://kubernetes.io/docs/concepts/overview/working-with-objects/names/#names
insecureSkipVerify originates TLS but skips verification of the backend's certificate. WARNING: This is an insecure option that should only be used if the risks are understood. There are two modes: * `All` disables all TLS verification. * `Hostname` verifies the CA certificate is trusted, but ignores any mismatch of hostname or SANs. Note that this method is still insecure; prefer setting `verifySubjectAltNames` to customize the valid hostnames if possible.
keyExchangeGroups configures the ordered list of key exchange groups for a TLS connection. For example: `X25519_MLKEM768,X25519`.
`mtlsCertificateRef` enables mutual TLS to the backend, using the specified key (`tls.key`) and cert (`tls.crt`) from the referenced `Secret`. An optional `ca.cert` field, if present, will be used to verify the server certificate. If `caCertificateRefs` is also specified, the `caCertificateRefs` field takes priority. If unspecified, no client certificate will be used.
Name of the referent. This field is effectively required, but due to backwards compatibility is allowed to be empty. Instances of this type with an empty value here are almost certainly wrong. More info: https://kubernetes.io/docs/concepts/overview/working-with-objects/names/#names
`sni` specifies the Server Name Indicator (`SNI`) to be used in the TLS handshake. If unset, the `SNI` is automatically set based on the destination hostname.
`verifySubjectAltNames` specifies the Subject Alternative Names (`SAN`) to verify in the server certificate. If not present, the destination hostname is automatically used.
`tunnel` defines settings for managing tunnel connections (with behavior like `HTTPS_PROXY`) to the backend.
`backendRef` references the proxy server to reach. Supported types: `Service` and `Backend`.
Group is the group of the referent. For example, "gateway.networking.k8s.io". When unspecified or empty string, core API group is inferred.
Kind is the Kubernetes resource kind of the referent. For example "Service". Defaults to "Service" when not specified. ExternalName services can refer to CNAME DNS records that may live outside of the cluster and as such are difficult to reason about in terms of conformance. They also may not be safe to forward to (see CVE-2021-25740 for more information). Implementations SHOULD NOT support ExternalName Services. Support: Core (Services with a type other than ExternalName) Support: Implementation-specific (Services with type ExternalName)
Name is the name of the referent.
Namespace is the namespace of the backend. When unspecified, the local namespace is inferred. Note that when a namespace different than the local namespace is specified, a ReferenceGrant object is required in the referent namespace to allow that namespace's owner to accept the reference. See the ReferenceGrant documentation for details. Support: Core
Port specifies the destination port number to use for this resource. Port is required when the referent is a Kubernetes Service. In this case, the port number is the service port number, not the target port. For other resources, destination port might be derived from the referent resource or this field.
Region is the AWS region where the guardrail is deployed (for example, `us-west-2`).
GuardrailVersion is the version of the Guardrail policy to use for the backend.
`googleModelArmor` configures Google Model Armor for prompt guarding.
Location is the Google Cloud location (for example, `us-central1`). Defaults to `us-central1` if not specified.
policies controls policies for communicating with Google Model Armor.
`auth` defines settings for managing authentication to the backend.
Auth specifies an explicit AWS authentication method for the backend. When omitted, we will try to use the default AWS SDK authentication methods.
`secretRef` references a Kubernetes `Secret` containing the AWS credentials. The `Secret` must have keys `accessKey`, `secretKey`, and optionally `sessionToken`.
Name of the referent. This field is effectively required, but due to backwards compatibility is allowed to be empty. Instances of this type with an empty value here are almost certainly wrong. More info: https://kubernetes.io/docs/concepts/overview/working-with-objects/names/#names
Azure specifies an Azure authentication method for the backend.
Details for managed identity authentication
`secretRef` references a Kubernetes `Secret` containing the Azure credentials. The `Secret` must have keys `clientID`, `tenantID`, and `clientSecret`.
Name of the referent. This field is effectively required, but due to backwards compatibility is allowed to be empty. Instances of this type with an empty value here are almost certainly wrong. More info: https://kubernetes.io/docs/concepts/overview/working-with-objects/names/#names
Auth specifies to use a Google authentication method for the backend. When omitted, we will try to use the default AWS SDK authentication methods.
`audience` allows explicitly configuring the `aud` of the ID token. Only valid with `IdToken` type. If not set, the `aud` is automatically derived from the backend hostname.
`secretRef` references a Kubernetes `Secret` containing ADC-compatible Google credential JSON in the `credentials.json` key. When omitted, ambient credentials are used.
Name of the referent. This field is effectively required, but due to backwards compatibility is allowed to be empty. Instances of this type with an empty value here are almost certainly wrong. More info: https://kubernetes.io/docs/concepts/overview/working-with-objects/names/#names
The type of token to generate. To authenticate to GCP services, generally an `AccessToken` is used. To authenticate to Cloud Run, an `IdToken` is used.
`key` provides an inline key to use as the value of the `Authorization` header. This option is the least secure; usage of a `Secret` is preferred.
`location` controls where backend credentials are inserted. If omitted, credentials are written to the `Authorization` header with the `Bearer ` prefix. This applies to `key`, `secretRef`, and `passthrough`.
HTTPHeaderName is the name of an HTTP header. Valid values include: * "Authorization" * "Set-Cookie" Invalid values include: - ":method" - ":" is an invalid character. This means that HTTP/2 pseudo headers are not currently supported by this type. - "/invalid" - "/ " is an invalid character
`passthrough` passes through an existing token that has been sent by the client and validated. Other policies, like JWT and API key authentication, will strip the original client credentials. Passthrough backend authentication causes the original token to be added back into the request. If there are no client authentication policies on the request, the original token would be unchanged, so this would have no effect.
`secretRef` references a Kubernetes `Secret` storing the key to use as the authorization value. This must be stored in the `Authorization` key.
Name of the referent. This field is effectively required, but due to backwards compatibility is allowed to be empty. Instances of this type with an empty value here are almost certainly wrong. More info: https://kubernetes.io/docs/concepts/overview/working-with-objects/names/#names
http defines settings for managing HTTP requests to the backend.
requestTimeout specifies the deadline for receiving a response from the backend.
`version` specifies the HTTP protocol version to use when connecting to the backend. If not specified, the version is automatically determined: * `Service` types can specify it with `appProtocol` on the `Service` port. * If traffic is identified as gRPC, `HTTP2` is used. * If the incoming traffic was plaintext HTTP, the original protocol will be used. * If the incoming traffic was HTTPS, `HTTP1` will be used. This is because most clients will transparently upgrade HTTPS traffic to `HTTP2`, even if the backend doesn't support it.
tcp defines settings for managing TCP connections to the backend.
`connectTimeout` defines the deadline for establishing a connection to the destination.
`keepAlive` defines settings for enabling TCP keepalives on the connection.
interval specifies the number of seconds between keep-alive probes. If unset, this defaults to 180s.
retries specifies the maximum number of keep-alive probes to send before dropping the connection. If unset, this defaults to 9.
time specifies the number of seconds a connection needs to be idle before keep-alive probes start being sent. If unset, this defaults to 180s.
tls defines settings for managing TLS connections to the backend. If this field is set, TLS will be initiated to the backend; the system trusted CA certificates will be used to validate the server, and the SNI will automatically be set based on the destination.
`alpnProtocols` sets the Application-Layer Protocol Negotiation (`ALPN`) value to use in the TLS handshake. If not present, defaults to `["h2", "http/1.1"]`.
`caCertificateRefs` defines the CA certificate `ConfigMap` to use to verify the server certificate. If unset, the system's trusted certificates are used.
Name of the referent. This field is effectively required, but due to backwards compatibility is allowed to be empty. Instances of this type with an empty value here are almost certainly wrong. More info: https://kubernetes.io/docs/concepts/overview/working-with-objects/names/#names
insecureSkipVerify originates TLS but skips verification of the backend's certificate. WARNING: This is an insecure option that should only be used if the risks are understood. There are two modes: * `All` disables all TLS verification. * `Hostname` verifies the CA certificate is trusted, but ignores any mismatch of hostname or SANs. Note that this method is still insecure; prefer setting `verifySubjectAltNames` to customize the valid hostnames if possible.
keyExchangeGroups configures the ordered list of key exchange groups for a TLS connection. For example: `X25519_MLKEM768,X25519`.
`mtlsCertificateRef` enables mutual TLS to the backend, using the specified key (`tls.key`) and cert (`tls.crt`) from the referenced `Secret`. An optional `ca.cert` field, if present, will be used to verify the server certificate. If `caCertificateRefs` is also specified, the `caCertificateRefs` field takes priority. If unspecified, no client certificate will be used.
Name of the referent. This field is effectively required, but due to backwards compatibility is allowed to be empty. Instances of this type with an empty value here are almost certainly wrong. More info: https://kubernetes.io/docs/concepts/overview/working-with-objects/names/#names
`sni` specifies the Server Name Indicator (`SNI`) to be used in the TLS handshake. If unset, the `SNI` is automatically set based on the destination hostname.
`verifySubjectAltNames` specifies the Subject Alternative Names (`SAN`) to verify in the server certificate. If not present, the destination hostname is automatically used.
`tunnel` defines settings for managing tunnel connections (with behavior like `HTTPS_PROXY`) to the backend.
`backendRef` references the proxy server to reach. Supported types: `Service` and `Backend`.
Group is the group of the referent. For example, "gateway.networking.k8s.io". When unspecified or empty string, core API group is inferred.
Kind is the Kubernetes resource kind of the referent. For example "Service". Defaults to "Service" when not specified. ExternalName services can refer to CNAME DNS records that may live outside of the cluster and as such are difficult to reason about in terms of conformance. They also may not be safe to forward to (see CVE-2021-25740 for more information). Implementations SHOULD NOT support ExternalName Services. Support: Core (Services with a type other than ExternalName) Support: Implementation-specific (Services with type ExternalName)
Name is the name of the referent.
Namespace is the namespace of the backend. When unspecified, the local namespace is inferred. Note that when a namespace different than the local namespace is specified, a ReferenceGrant object is required in the referent namespace to allow that namespace's owner to accept the reference. See the ReferenceGrant documentation for details. Support: Core
Port specifies the destination port number to use for this resource. Port is required when the referent is a Kubernetes Service. In this case, the port number is the service port number, not the target port. For other resources, destination port might be derived from the referent resource or this field.
ProjectID is the Google Cloud project ID.
TemplateID is the template ID for Google Model Armor.
Regular expression (regex) matching for prompt guards and data masking.
The action to take if a regex pattern is matched in a request or response. This setting applies only to request matches. `PromptguardResponse` matches are always masked by default. Defaults to `Mask`.
A list of built-in regex patterns to match against the request or response. Matches and built-ins are additive.
A list of regex patterns to match against the request or response. Matches and built-ins are additive.
A custom response message to return to the client. If not specified, defaults to `The response was rejected due to inappropriate content`.
A custom response message to return to the client. If not specified, defaults to `The request was rejected due to inappropriate content`.
The status code to return to the client. Defaults to 403.
Configure a webhook to forward responses to for prompt guarding.
backendRef references the webhook server to reach. Supported types: Service and Backend.
Group is the group of the referent. For example, "gateway.networking.k8s.io". When unspecified or empty string, core API group is inferred.
Kind is the Kubernetes resource kind of the referent. For example "Service". Defaults to "Service" when not specified. ExternalName services can refer to CNAME DNS records that may live outside of the cluster and as such are difficult to reason about in terms of conformance. They also may not be safe to forward to (see CVE-2021-25740 for more information). Implementations SHOULD NOT support ExternalName Services. Support: Core (Services with a type other than ExternalName) Support: Implementation-specific (Services with type ExternalName)
Name is the name of the referent.
Namespace is the namespace of the backend. When unspecified, the local namespace is inferred. Note that when a namespace different than the local namespace is specified, a ReferenceGrant object is required in the referent namespace to allow that namespace's owner to accept the reference. See the ReferenceGrant documentation for details. Support: Core
Port specifies the destination port number to use for this resource. Port is required when the referent is a Kubernetes Service. In this case, the port number is the service port number, not the target port. For other resources, destination port might be derived from the referent resource or this field.
ForwardHeaderMatches defines a list of HTTP header matches that will be used to select the headers to forward to the webhook. Request headers are used when forwarding requests and response headers are used when forwarding responses. By default, no headers are forwarded.
Name is the name of the HTTP Header to be matched. Name matching MUST be case-insensitive. (See https://tools.ietf.org/html/rfc7230#section-3.2). If multiple entries specify equivalent header names, only the first entry with an equivalent name MUST be considered for a match. Subsequent entries with an equivalent header name MUST be ignored. Due to the case-insensitivity of header names, "foo" and "Foo" are considered equivalent. When a header is repeated in an HTTP request, it is implementation-specific behavior as to how this is represented. Generally, proxies should follow the guidance from the RFC: https://www.rfc-editor.org/rfc/rfc7230.html#section-3.2.2 regarding processing a repeated header, with special handling for "Set-Cookie".
Type specifies how to match against the value of the header. Support: Core (Exact) Support: Implementation-specific (RegularExpression) Since RegularExpression HeaderMatchType has implementation-specific conformance, implementations can support POSIX, PCRE or any other dialects of regular expressions. Please read the implementation's documentation to determine the supported dialect.
Value is the value of HTTP Header to be matched. <gateway:experimental:description> Must consist of printable US-ASCII characters, optionally separated by single tabs or spaces. See: https://tools.ietf.org/html/rfc7230#section-3.2 </gateway:experimental:description> <gateway:experimental:validation:Pattern=`^[!-~]+([\t ]?[!-~]+)*$`>
`routes` defines how to identify the type of traffic to handle. The keys are URL path suffixes matched using ends-with comparison, for example `"/v1/chat/completions"`. The special `*` wildcard matches any path. If not specified, all traffic defaults to `completions` type.
Provide CEL transformations to compute and set fields in the request body. The expression result overwrites any existing value for that field. This has a higher priority than `overrides` if both are set for the same key.
CEL expression used to compute the field value.
The name of the field to set.
`auth` defines settings for managing authentication to the backend.
Auth specifies an explicit AWS authentication method for the backend. When omitted, we will try to use the default AWS SDK authentication methods.
`secretRef` references a Kubernetes `Secret` containing the AWS credentials. The `Secret` must have keys `accessKey`, `secretKey`, and optionally `sessionToken`.
Name of the referent. This field is effectively required, but due to backwards compatibility is allowed to be empty. Instances of this type with an empty value here are almost certainly wrong. More info: https://kubernetes.io/docs/concepts/overview/working-with-objects/names/#names
Azure specifies an Azure authentication method for the backend.
Details for managed identity authentication
`secretRef` references a Kubernetes `Secret` containing the Azure credentials. The `Secret` must have keys `clientID`, `tenantID`, and `clientSecret`.
Name of the referent. This field is effectively required, but due to backwards compatibility is allowed to be empty. Instances of this type with an empty value here are almost certainly wrong. More info: https://kubernetes.io/docs/concepts/overview/working-with-objects/names/#names
Auth specifies to use a Google authentication method for the backend. When omitted, we will try to use the default AWS SDK authentication methods.
`audience` allows explicitly configuring the `aud` of the ID token. Only valid with `IdToken` type. If not set, the `aud` is automatically derived from the backend hostname.
`secretRef` references a Kubernetes `Secret` containing ADC-compatible Google credential JSON in the `credentials.json` key. When omitted, ambient credentials are used.
Name of the referent. This field is effectively required, but due to backwards compatibility is allowed to be empty. Instances of this type with an empty value here are almost certainly wrong. More info: https://kubernetes.io/docs/concepts/overview/working-with-objects/names/#names
The type of token to generate. To authenticate to GCP services, generally an `AccessToken` is used. To authenticate to Cloud Run, an `IdToken` is used.
`key` provides an inline key to use as the value of the `Authorization` header. This option is the least secure; usage of a `Secret` is preferred.
`location` controls where backend credentials are inserted. If omitted, credentials are written to the `Authorization` header with the `Bearer ` prefix. This applies to `key`, `secretRef`, and `passthrough`.
HTTPHeaderName is the name of an HTTP header. Valid values include: * "Authorization" * "Set-Cookie" Invalid values include: - ":method" - ":" is an invalid character. This means that HTTP/2 pseudo headers are not currently supported by this type. - "/invalid" - "/ " is an invalid character
`passthrough` passes through an existing token that has been sent by the client and validated. Other policies, like JWT and API key authentication, will strip the original client credentials. Passthrough backend authentication causes the original token to be added back into the request. If there are no client authentication policies on the request, the original token would be unchanged, so this would have no effect.
`secretRef` references a Kubernetes `Secret` storing the key to use as the authorization value. This must be stored in the `Authorization` key.
Name of the referent. This field is effectively required, but due to backwards compatibility is allowed to be empty. Instances of this type with an empty value here are almost certainly wrong. More info: https://kubernetes.io/docs/concepts/overview/working-with-objects/names/#names
health defines settings for passive and active health checking.
Eviction defines settings for evicting unhealthy backends.
ConsecutiveFailures is the number of consecutive unhealthy responses required before the backend is evicted. For example, a value of 5 means the backend must receive 5 unhealthy responses in a row before being evicted. When both consecutiveFailures and healthThreshold are set, the backend is evicted when either condition is met. When neither is set, a single unhealthy response can trigger eviction.
Duration specifies the base time a backend should be evicted after being marked unhealthy. Subsequent evictions use multiplicative backoff (duration * times_evicted). If all endpoints are evicted, the load balancer falls back to returning evicted endpoints rather than failing entirely. If unset, defaults to `3s`.
HealthThreshold is the EWMA (exponentially-weighted moving average) health score threshold, expressed as 0–100. When set, a backend is only evicted if its computed health drops below this value after an unhealthy response. For example, 50 means the backend is evicted when its EWMA health falls below 50% following failures. Unlike consecutiveFailures (which counts consecutive failures), this uses a sliding-window average so a single success in a stream of failures can delay eviction. When both consecutiveFailures and healthThreshold are set, the backend is evicted when either condition is met. When neither is set, a single unhealthy response triggers eviction.
RestoreHealth is the health score (0–100) assigned to a backend when it returns from eviction. For gradual recovery, set below 100; for full recovery immediately, set 100. If unset, the backend resumes with the health it had when evicted.
UnhealthyCondition is a CEL expression that determines whether a response indicates an unhealthy backend. When the expression evaluates to true, the backend is considered unhealthy and may be evicted. For example, to evict on 5xx responses: `response.code >= 500`. When unset, any 5xx response, or a connection failure, is treated as unhealthy. This default lowers the backend's health score but does not trigger eviction on its own.
http defines settings for managing HTTP requests to the backend.
requestTimeout specifies the deadline for receiving a response from the backend.
`version` specifies the HTTP protocol version to use when connecting to the backend. If not specified, the version is automatically determined: * `Service` types can specify it with `appProtocol` on the `Service` port. * If traffic is identified as gRPC, `HTTP2` is used. * If the incoming traffic was plaintext HTTP, the original protocol will be used. * If the incoming traffic was HTTPS, `HTTP1` will be used. This is because most clients will transparently upgrade HTTPS traffic to `HTTP2`, even if the backend doesn't support it.
tcp defines settings for managing TCP connections to the backend.
`connectTimeout` defines the deadline for establishing a connection to the destination.
`keepAlive` defines settings for enabling TCP keepalives on the connection.
interval specifies the number of seconds between keep-alive probes. If unset, this defaults to 180s.
retries specifies the maximum number of keep-alive probes to send before dropping the connection. If unset, this defaults to 9.
time specifies the number of seconds a connection needs to be idle before keep-alive probes start being sent. If unset, this defaults to 180s.
tls defines settings for managing TLS connections to the backend. If this field is set, TLS will be initiated to the backend; the system trusted CA certificates will be used to validate the server, and the SNI will automatically be set based on the destination.
`alpnProtocols` sets the Application-Layer Protocol Negotiation (`ALPN`) value to use in the TLS handshake. If not present, defaults to `["h2", "http/1.1"]`.
`caCertificateRefs` defines the CA certificate `ConfigMap` to use to verify the server certificate. If unset, the system's trusted certificates are used.
Name of the referent. This field is effectively required, but due to backwards compatibility is allowed to be empty. Instances of this type with an empty value here are almost certainly wrong. More info: https://kubernetes.io/docs/concepts/overview/working-with-objects/names/#names
insecureSkipVerify originates TLS but skips verification of the backend's certificate. WARNING: This is an insecure option that should only be used if the risks are understood. There are two modes: * `All` disables all TLS verification. * `Hostname` verifies the CA certificate is trusted, but ignores any mismatch of hostname or SANs. Note that this method is still insecure; prefer setting `verifySubjectAltNames` to customize the valid hostnames if possible.
keyExchangeGroups configures the ordered list of key exchange groups for a TLS connection. For example: `X25519_MLKEM768,X25519`.
`mtlsCertificateRef` enables mutual TLS to the backend, using the specified key (`tls.key`) and cert (`tls.crt`) from the referenced `Secret`. An optional `ca.cert` field, if present, will be used to verify the server certificate. If `caCertificateRefs` is also specified, the `caCertificateRefs` field takes priority. If unspecified, no client certificate will be used.
Name of the referent. This field is effectively required, but due to backwards compatibility is allowed to be empty. Instances of this type with an empty value here are almost certainly wrong. More info: https://kubernetes.io/docs/concepts/overview/working-with-objects/names/#names
`sni` specifies the Server Name Indicator (`SNI`) to be used in the TLS handshake. If unset, the `SNI` is automatically set based on the destination hostname.
`verifySubjectAltNames` specifies the Subject Alternative Names (`SAN`) to verify in the server certificate. If not present, the destination hostname is automatically used.
transformation is used to mutate and transform requests and responses sent to and from the backend.
`request` is used to modify the request path.
`add` is a list of headers to add to the request and what that value should be set to. If there is already a header with these values then append the value as an extra entry.
The name of the header to add.
`value` is the CEL expression to apply to generate the output value for the header.
`body` controls manipulation of the HTTP body.
`metadata` stores CEL-evaluated values under the `metadata` CEL variable for subsequent policy evaluations. `metadata` is evaluated before header or body transformations.
`remove` is a list of header names to remove from the request or response.
`set` is a list of headers and the value they should be set to.
The name of the header to add.
`value` is the CEL expression to apply to generate the output value for the header.
`response` is used to modify the response path.
`add` is a list of headers to add to the request and what that value should be set to. If there is already a header with these values then append the value as an extra entry.
The name of the header to add.
`value` is the CEL expression to apply to generate the output value for the header.
`body` controls manipulation of the HTTP body.
`metadata` stores CEL-evaluated values under the `metadata` CEL variable for subsequent policy evaluations. `metadata` is evaluated before header or body transformations.
`remove` is a list of header names to remove from the request or response.
`set` is a list of headers and the value they should be set to.
The name of the header to add.
`value` is the CEL expression to apply to generate the output value for the header.
`tunnel` defines settings for managing tunnel connections (with behavior like `HTTPS_PROXY`) to the backend.
`backendRef` references the proxy server to reach. Supported types: `Service` and `Backend`.
Group is the group of the referent. For example, "gateway.networking.k8s.io". When unspecified or empty string, core API group is inferred.
Kind is the Kubernetes resource kind of the referent. For example "Service". Defaults to "Service" when not specified. ExternalName services can refer to CNAME DNS records that may live outside of the cluster and as such are difficult to reason about in terms of conformance. They also may not be safe to forward to (see CVE-2021-25740 for more information). Implementations SHOULD NOT support ExternalName Services. Support: Core (Services with a type other than ExternalName) Support: Implementation-specific (Services with type ExternalName)
Name is the name of the referent.
Namespace is the namespace of the backend. When unspecified, the local namespace is inferred. Note that when a namespace different than the local namespace is specified, a ReferenceGrant object is required in the referent namespace to allow that namespace's owner to accept the reference. See the ReferenceGrant documentation for details. Support: Core
Port specifies the destination port number to use for this resource. Port is required when the referent is a Kubernetes Service. In this case, the port number is the service port number, not the target port. For other resources, destination port might be derived from the referent resource or this field.
Port specifies the port to send the requests to.
Vertex AI provider
Optional: Override the model name, such as `gpt-4o-mini`. If unset, the model name is taken from the request.
The ID of the Google Cloud Project that you use for the Vertex AI.
The location of the Google Cloud Project that you use for the Vertex AI. Defaults to `global` if not specified.
`provider` specifies configuration for how to reach the configured LLM provider.
Anthropic provider
Optional: Override the model name, such as `gpt-4o-mini`. If unset, the model name is taken from the request.
Azure provider with resource-based configuration. Supports both Azure OpenAI and Azure AI Foundry resource types.
The version of the Azure OpenAI API to use. If unset, defaults to `v1`.
Optional: Override the model name, such as `gpt-4o-mini`. If unset, the model name is taken from the request.
The Foundry project name, required when `resourceType` is `Foundry`. Used to construct paths: /api/projects/{projectName}/openai/v1/...
The Azure resource name used to construct the endpoint host. For OpenAI: {resourceName}.openai.azure.com For Foundry: {resourceName}-resource.services.ai.azure.com
The type of Azure endpoint. Determines the host suffix.
Azure OpenAI provider
The version of the Azure OpenAI API to use. For more information, see the [Azure OpenAI API version reference](https://learn.microsoft.com/en-us/azure/foundry/openai/reference). If unset, defaults to `v1`.
The name of the Azure OpenAI model deployment to use. For more information, see the [Azure OpenAI model docs](https://learn.microsoft.com/en-us/azure/foundry/foundry-models/concepts/models-sold-directly-by-azure?view=foundry-classic). This is required if `apiVersion` is not `v1`. For `v1`, the model can be set in the request.
The endpoint for the Azure OpenAI API to use, such as `my-endpoint.openai.azure.com`. If the scheme is included, it is stripped.
Bedrock provider
`guardrail` configures the Guardrail policy to use for the backend. See <https://docs.aws.amazon.com/bedrock/latest/userguide/guardrails.html>. If not specified, the AWS Guardrail policy will not be used.
GuardrailIdentifier is the identifier of the Guardrail policy to use for the backend.
GuardrailVersion is the version of the Guardrail policy to use for the backend.
Optional: Override the model name, such as `gpt-4o-mini`. If unset, the model name is taken from the request.
Region is the AWS region to use for the backend. Defaults to `us-east-1` if not specified.
Gemini provider
Optional: Override the model name, such as `gemini-2.5-pro`. If unset, the model name is taken from the request.
Host specifies the hostname to send the requests to. If not specified, the default hostname for the provider is used.
OpenAI provider
Optional: Override the model name, such as `gpt-4o-mini`. If unset, the model name is taken from the request.
Path specifies the URL path to use for the LLM provider API requests. This is useful when you need to route requests to a different API endpoint while maintaining compatibility with the original provider's API structure. If not specified, the default path for the provider is used.
PathPrefix overrides the default base path prefix (e.g. "/v1") for upstream requests. Path translation for cross-format requests still applies using this prefix. Only supported for OpenAI and Anthropic providers.
Port specifies the port to send the requests to.
Vertex AI provider
Optional: Override the model name, such as `gpt-4o-mini`. If unset, the model name is taken from the request.
The ID of the Google Cloud Project that you use for the Vertex AI.
The location of the Google Cloud Project that you use for the Vertex AI. Defaults to `global` if not specified.
aws represents an AWS service backend (AgentCore, etc.).
agentCore configures Amazon Bedrock AgentCore as a backend.
agentRuntimeArn is the ARN of the AgentCore runtime.
qualifier optionally specifies the alias or version qualifier.
dynamicForwardProxy configures the proxy to dynamically send requests to the destination based on the incoming request HTTP host header, or TLS SNI for TLS traffic. Note: this Backend type enables users to send trigger the proxy to send requests to arbitrary destinations. Proper access controls must be put in place when using this backend type.
mcp represents an MCP backend
`failureMode` controls behavior when MCP targets fail to initialize or become unavailable at runtime. `FailOpen` skips failed targets and continues serving from healthy ones. `FailClosed` (default) fails the entire session if any target fails.
`sessionRouting` configures MCP session behavior for requests. Defaults to `Stateful` if not set.
`targets` is a list of MCP targets to use for this backend. Policies targeting MCP targets must use `targetRefs[].sectionName` to select the target by name.
Name of the MCP target.
`selector` is the label selector used to select `Service` resources. If policies are needed on a per-service basis, `AgentgatewayPolicy` can target the desired `Service`.
`namespace` is the label selector for namespaces that `Service` resources should be selected from. If unset, only the namespace of the `AgentgatewayBackend` is searched.
matchExpressions is a list of label selector requirements. The requirements are ANDed.
key is the label key that the selector applies to.
operator represents a key's relationship to a set of values. Valid operators are In, NotIn, Exists and DoesNotExist.
values is an array of string values. If the operator is In or NotIn, the values array must be non-empty. If the operator is Exists or DoesNotExist, the values array must be empty. This array is replaced during a strategic merge patch.
matchLabels is a map of {key,value} pairs. A single {key,value} in the matchLabels map is equivalent to an element of matchExpressions, whose key field is "key", the operator is "In", and the values array contains only "value". The requirements are ANDed.
`services` is the label selector for which `Service` resources should be selected.
matchExpressions is a list of label selector requirements. The requirements are ANDed.
key is the label key that the selector applies to.
operator represents a key's relationship to a set of values. Valid operators are In, NotIn, Exists and DoesNotExist.
values is an array of string values. If the operator is In or NotIn, the values array must be non-empty. If the operator is Exists or DoesNotExist, the values array must be empty. This array is replaced during a strategic merge patch.
matchLabels is a map of {key,value} pairs. A single {key,value} in the matchLabels map is equivalent to an element of matchExpressions, whose key field is "key", the operator is "In", and the values array contains only "value". The requirements are ANDed.
`static` configures a static MCP destination. When connecting to in-cluster `Service` resources, it is recommended to use `selector` instead.
`backendRef` references a namespace-local `Service` resource by name. When set, this replaces `host` only; `port`, `path`, and `protocol` remain configured on this target.
Name of the referent. This field is effectively required, but due to backwards compatibility is allowed to be empty. Instances of this type with an empty value here are almost certainly wrong. More info: https://kubernetes.io/docs/concepts/overview/working-with-objects/names/#names
Host is the hostname or IP address of the MCP target.
Path is the URL path of the MCP target endpoint. Defaults to `"/sse"` for the `SSE` protocol or `"/mcp"` for the `StreamableHTTP` protocol if not specified.
`policies` controls policies for communicating with this backend. Policies may also be set in `AgentgatewayPolicy`, or in the top-level `AgentgatewayBackend`. Policies are merged on a field-level basis, with order: `AgentgatewayPolicy` < `AgentgatewayBackend` < `AgentgatewayBackend` MCP (this field). This field may only be used with host-based static targets, not `backendRef`.
`auth` defines settings for managing authentication to the backend.
Auth specifies an explicit AWS authentication method for the backend. When omitted, we will try to use the default AWS SDK authentication methods.
`secretRef` references a Kubernetes `Secret` containing the AWS credentials. The `Secret` must have keys `accessKey`, `secretKey`, and optionally `sessionToken`.
Name of the referent. This field is effectively required, but due to backwards compatibility is allowed to be empty. Instances of this type with an empty value here are almost certainly wrong. More info: https://kubernetes.io/docs/concepts/overview/working-with-objects/names/#names
Azure specifies an Azure authentication method for the backend.
Details for managed identity authentication
`secretRef` references a Kubernetes `Secret` containing the Azure credentials. The `Secret` must have keys `clientID`, `tenantID`, and `clientSecret`.
Name of the referent. This field is effectively required, but due to backwards compatibility is allowed to be empty. Instances of this type with an empty value here are almost certainly wrong. More info: https://kubernetes.io/docs/concepts/overview/working-with-objects/names/#names
Auth specifies to use a Google authentication method for the backend. When omitted, we will try to use the default AWS SDK authentication methods.
`audience` allows explicitly configuring the `aud` of the ID token. Only valid with `IdToken` type. If not set, the `aud` is automatically derived from the backend hostname.
`secretRef` references a Kubernetes `Secret` containing ADC-compatible Google credential JSON in the `credentials.json` key. When omitted, ambient credentials are used.
Name of the referent. This field is effectively required, but due to backwards compatibility is allowed to be empty. Instances of this type with an empty value here are almost certainly wrong. More info: https://kubernetes.io/docs/concepts/overview/working-with-objects/names/#names
The type of token to generate. To authenticate to GCP services, generally an `AccessToken` is used. To authenticate to Cloud Run, an `IdToken` is used.
`key` provides an inline key to use as the value of the `Authorization` header. This option is the least secure; usage of a `Secret` is preferred.
`location` controls where backend credentials are inserted. If omitted, credentials are written to the `Authorization` header with the `Bearer ` prefix. This applies to `key`, `secretRef`, and `passthrough`.
HTTPHeaderName is the name of an HTTP header. Valid values include: * "Authorization" * "Set-Cookie" Invalid values include: - ":method" - ":" is an invalid character. This means that HTTP/2 pseudo headers are not currently supported by this type. - "/invalid" - "/ " is an invalid character
`passthrough` passes through an existing token that has been sent by the client and validated. Other policies, like JWT and API key authentication, will strip the original client credentials. Passthrough backend authentication causes the original token to be added back into the request. If there are no client authentication policies on the request, the original token would be unchanged, so this would have no effect.
`secretRef` references a Kubernetes `Secret` storing the key to use as the authorization value. This must be stored in the `Authorization` key.
Name of the referent. This field is effectively required, but due to backwards compatibility is allowed to be empty. Instances of this type with an empty value here are almost certainly wrong. More info: https://kubernetes.io/docs/concepts/overview/working-with-objects/names/#names
http defines settings for managing HTTP requests to the backend.
requestTimeout specifies the deadline for receiving a response from the backend.
`version` specifies the HTTP protocol version to use when connecting to the backend. If not specified, the version is automatically determined: * `Service` types can specify it with `appProtocol` on the `Service` port. * If traffic is identified as gRPC, `HTTP2` is used. * If the incoming traffic was plaintext HTTP, the original protocol will be used. * If the incoming traffic was HTTPS, `HTTP1` will be used. This is because most clients will transparently upgrade HTTPS traffic to `HTTP2`, even if the backend doesn't support it.
tcp defines settings for managing TCP connections to the backend.
`connectTimeout` defines the deadline for establishing a connection to the destination.
`keepAlive` defines settings for enabling TCP keepalives on the connection.
interval specifies the number of seconds between keep-alive probes. If unset, this defaults to 180s.
retries specifies the maximum number of keep-alive probes to send before dropping the connection. If unset, this defaults to 9.
time specifies the number of seconds a connection needs to be idle before keep-alive probes start being sent. If unset, this defaults to 180s.
tls defines settings for managing TLS connections to the backend. If this field is set, TLS will be initiated to the backend; the system trusted CA certificates will be used to validate the server, and the SNI will automatically be set based on the destination.
`alpnProtocols` sets the Application-Layer Protocol Negotiation (`ALPN`) value to use in the TLS handshake. If not present, defaults to `["h2", "http/1.1"]`.
`caCertificateRefs` defines the CA certificate `ConfigMap` to use to verify the server certificate. If unset, the system's trusted certificates are used.
Name of the referent. This field is effectively required, but due to backwards compatibility is allowed to be empty. Instances of this type with an empty value here are almost certainly wrong. More info: https://kubernetes.io/docs/concepts/overview/working-with-objects/names/#names
insecureSkipVerify originates TLS but skips verification of the backend's certificate. WARNING: This is an insecure option that should only be used if the risks are understood. There are two modes: * `All` disables all TLS verification. * `Hostname` verifies the CA certificate is trusted, but ignores any mismatch of hostname or SANs. Note that this method is still insecure; prefer setting `verifySubjectAltNames` to customize the valid hostnames if possible.
keyExchangeGroups configures the ordered list of key exchange groups for a TLS connection. For example: `X25519_MLKEM768,X25519`.
`mtlsCertificateRef` enables mutual TLS to the backend, using the specified key (`tls.key`) and cert (`tls.crt`) from the referenced `Secret`. An optional `ca.cert` field, if present, will be used to verify the server certificate. If `caCertificateRefs` is also specified, the `caCertificateRefs` field takes priority. If unspecified, no client certificate will be used.
Name of the referent. This field is effectively required, but due to backwards compatibility is allowed to be empty. Instances of this type with an empty value here are almost certainly wrong. More info: https://kubernetes.io/docs/concepts/overview/working-with-objects/names/#names
`sni` specifies the Server Name Indicator (`SNI`) to be used in the TLS handshake. If unset, the `SNI` is automatically set based on the destination hostname.
`verifySubjectAltNames` specifies the Subject Alternative Names (`SAN`) to verify in the server certificate. If not present, the destination hostname is automatically used.
`tunnel` defines settings for managing tunnel connections (with behavior like `HTTPS_PROXY`) to the backend.
`backendRef` references the proxy server to reach. Supported types: `Service` and `Backend`.
Group is the group of the referent. For example, "gateway.networking.k8s.io". When unspecified or empty string, core API group is inferred.
Kind is the Kubernetes resource kind of the referent. For example "Service". Defaults to "Service" when not specified. ExternalName services can refer to CNAME DNS records that may live outside of the cluster and as such are difficult to reason about in terms of conformance. They also may not be safe to forward to (see CVE-2021-25740 for more information). Implementations SHOULD NOT support ExternalName Services. Support: Core (Services with a type other than ExternalName) Support: Implementation-specific (Services with type ExternalName)
Name is the name of the referent.
Namespace is the namespace of the backend. When unspecified, the local namespace is inferred. Note that when a namespace different than the local namespace is specified, a ReferenceGrant object is required in the referent namespace to allow that namespace's owner to accept the reference. See the ReferenceGrant documentation for details. Support: Core
Port specifies the destination port number to use for this resource. Port is required when the referent is a Kubernetes Service. In this case, the port number is the service port number, not the target port. For other resources, destination port might be derived from the referent resource or this field.
Port is the port number of the MCP target.
Protocol is the protocol to use for the connection to the MCP target.
policies controls policies for communicating with this backend. Policies may also be set in AgentgatewayPolicy; policies are merged on a field-level basis, with policies on the Backend (this field) taking precedence.
`ai` specifies settings for AI workloads. This is only applicable when connecting to a `Backend` of type `ai`.
Provide defaults to merge with user input fields. If the field is already set, the field in the request is used.
The name of the field.
The field default value, which can be any JSON Data Type.
ModelAliases maps friendly model names to actual provider model names. Example: `{"fast": "gpt-3.5-turbo", "smart": "gpt-4-turbo"}`. Note: This field is only applicable when using the agentgateway data plane.
Provide overrides to merge with user input fields. If the field is already set, the field will be overwritten.
The name of the field.
The field default value, which can be any JSON Data Type.
Enrich requests sent to the LLM provider by appending and prepending system prompts. This can be configured only for LLM providers that use the `CHAT` or `CHAT_STREAMING` API route type.
A list of messages to be appended to the prompt sent by the client.
String content of the message.
Role of the message. The available roles depend on the backend LLM provider model, such as `SYSTEM` or `USER` in the OpenAI API.
A list of messages to be prepended to the prompt sent by the client.
String content of the message.
Role of the message. The available roles depend on the backend LLM provider model, such as `SYSTEM` or `USER` in the OpenAI API.
`promptCaching` enables automatic prompt caching for supported providers, currently AWS Bedrock. Reduces API costs by caching static content like system prompts and tool definitions. Only applicable for Bedrock Claude 3+ and Nova models.
CacheMessageOffset shifts the message cache point further back in the conversation. 0 (default) places it at the second-to-last message. Higher values move it N additional messages towards the start, clamped to bounds.
CacheMessages enables caching for conversation messages. Caches all messages in the conversation for cost savings.
CacheSystem enables caching for system prompts. Inserts a cache point after all system messages.
CacheTools enables caching for tool definitions. Inserts a cache point after all tool specifications.
MinTokens specifies the minimum estimated token count before caching is enabled. Uses rough heuristic (word count × 1.3) to estimate tokens. Bedrock requires at least 1,024 tokens for caching to be effective.
`promptGuard` enables adding guardrails to LLM requests and responses.
Prompt guards to apply to requests sent by the client.
`bedrockGuardrails` configures AWS Bedrock Guardrails for prompt guarding.
GuardrailIdentifier is the identifier of the Guardrail policy to use for the backend.
policies controls policies for communicating with AWS Bedrock Guardrails.
`auth` defines settings for managing authentication to the backend.
Auth specifies an explicit AWS authentication method for the backend. When omitted, we will try to use the default AWS SDK authentication methods.
`secretRef` references a Kubernetes `Secret` containing the AWS credentials. The `Secret` must have keys `accessKey`, `secretKey`, and optionally `sessionToken`.
Name of the referent. This field is effectively required, but due to backwards compatibility is allowed to be empty. Instances of this type with an empty value here are almost certainly wrong. More info: https://kubernetes.io/docs/concepts/overview/working-with-objects/names/#names
Azure specifies an Azure authentication method for the backend.
Details for managed identity authentication
`secretRef` references a Kubernetes `Secret` containing the Azure credentials. The `Secret` must have keys `clientID`, `tenantID`, and `clientSecret`.
Name of the referent. This field is effectively required, but due to backwards compatibility is allowed to be empty. Instances of this type with an empty value here are almost certainly wrong. More info: https://kubernetes.io/docs/concepts/overview/working-with-objects/names/#names
Auth specifies to use a Google authentication method for the backend. When omitted, we will try to use the default AWS SDK authentication methods.
`audience` allows explicitly configuring the `aud` of the ID token. Only valid with `IdToken` type. If not set, the `aud` is automatically derived from the backend hostname.
`secretRef` references a Kubernetes `Secret` containing ADC-compatible Google credential JSON in the `credentials.json` key. When omitted, ambient credentials are used.
Name of the referent. This field is effectively required, but due to backwards compatibility is allowed to be empty. Instances of this type with an empty value here are almost certainly wrong. More info: https://kubernetes.io/docs/concepts/overview/working-with-objects/names/#names
The type of token to generate. To authenticate to GCP services, generally an `AccessToken` is used. To authenticate to Cloud Run, an `IdToken` is used.
`key` provides an inline key to use as the value of the `Authorization` header. This option is the least secure; usage of a `Secret` is preferred.
`location` controls where backend credentials are inserted. If omitted, credentials are written to the `Authorization` header with the `Bearer ` prefix. This applies to `key`, `secretRef`, and `passthrough`.
HTTPHeaderName is the name of an HTTP header. Valid values include: * "Authorization" * "Set-Cookie" Invalid values include: - ":method" - ":" is an invalid character. This means that HTTP/2 pseudo headers are not currently supported by this type. - "/invalid" - "/ " is an invalid character
`passthrough` passes through an existing token that has been sent by the client and validated. Other policies, like JWT and API key authentication, will strip the original client credentials. Passthrough backend authentication causes the original token to be added back into the request. If there are no client authentication policies on the request, the original token would be unchanged, so this would have no effect.
`secretRef` references a Kubernetes `Secret` storing the key to use as the authorization value. This must be stored in the `Authorization` key.
Name of the referent. This field is effectively required, but due to backwards compatibility is allowed to be empty. Instances of this type with an empty value here are almost certainly wrong. More info: https://kubernetes.io/docs/concepts/overview/working-with-objects/names/#names
http defines settings for managing HTTP requests to the backend.
requestTimeout specifies the deadline for receiving a response from the backend.
`version` specifies the HTTP protocol version to use when connecting to the backend. If not specified, the version is automatically determined: * `Service` types can specify it with `appProtocol` on the `Service` port. * If traffic is identified as gRPC, `HTTP2` is used. * If the incoming traffic was plaintext HTTP, the original protocol will be used. * If the incoming traffic was HTTPS, `HTTP1` will be used. This is because most clients will transparently upgrade HTTPS traffic to `HTTP2`, even if the backend doesn't support it.
tcp defines settings for managing TCP connections to the backend.
`connectTimeout` defines the deadline for establishing a connection to the destination.
`keepAlive` defines settings for enabling TCP keepalives on the connection.
interval specifies the number of seconds between keep-alive probes. If unset, this defaults to 180s.
retries specifies the maximum number of keep-alive probes to send before dropping the connection. If unset, this defaults to 9.
time specifies the number of seconds a connection needs to be idle before keep-alive probes start being sent. If unset, this defaults to 180s.
tls defines settings for managing TLS connections to the backend. If this field is set, TLS will be initiated to the backend; the system trusted CA certificates will be used to validate the server, and the SNI will automatically be set based on the destination.
`alpnProtocols` sets the Application-Layer Protocol Negotiation (`ALPN`) value to use in the TLS handshake. If not present, defaults to `["h2", "http/1.1"]`.
`caCertificateRefs` defines the CA certificate `ConfigMap` to use to verify the server certificate. If unset, the system's trusted certificates are used.
Name of the referent. This field is effectively required, but due to backwards compatibility is allowed to be empty. Instances of this type with an empty value here are almost certainly wrong. More info: https://kubernetes.io/docs/concepts/overview/working-with-objects/names/#names
insecureSkipVerify originates TLS but skips verification of the backend's certificate. WARNING: This is an insecure option that should only be used if the risks are understood. There are two modes: * `All` disables all TLS verification. * `Hostname` verifies the CA certificate is trusted, but ignores any mismatch of hostname or SANs. Note that this method is still insecure; prefer setting `verifySubjectAltNames` to customize the valid hostnames if possible.
keyExchangeGroups configures the ordered list of key exchange groups for a TLS connection. For example: `X25519_MLKEM768,X25519`.
`mtlsCertificateRef` enables mutual TLS to the backend, using the specified key (`tls.key`) and cert (`tls.crt`) from the referenced `Secret`. An optional `ca.cert` field, if present, will be used to verify the server certificate. If `caCertificateRefs` is also specified, the `caCertificateRefs` field takes priority. If unspecified, no client certificate will be used.
Name of the referent. This field is effectively required, but due to backwards compatibility is allowed to be empty. Instances of this type with an empty value here are almost certainly wrong. More info: https://kubernetes.io/docs/concepts/overview/working-with-objects/names/#names
`sni` specifies the Server Name Indicator (`SNI`) to be used in the TLS handshake. If unset, the `SNI` is automatically set based on the destination hostname.
`verifySubjectAltNames` specifies the Subject Alternative Names (`SAN`) to verify in the server certificate. If not present, the destination hostname is automatically used.
`tunnel` defines settings for managing tunnel connections (with behavior like `HTTPS_PROXY`) to the backend.
`backendRef` references the proxy server to reach. Supported types: `Service` and `Backend`.
Group is the group of the referent. For example, "gateway.networking.k8s.io". When unspecified or empty string, core API group is inferred.
Kind is the Kubernetes resource kind of the referent. For example "Service". Defaults to "Service" when not specified. ExternalName services can refer to CNAME DNS records that may live outside of the cluster and as such are difficult to reason about in terms of conformance. They also may not be safe to forward to (see CVE-2021-25740 for more information). Implementations SHOULD NOT support ExternalName Services. Support: Core (Services with a type other than ExternalName) Support: Implementation-specific (Services with type ExternalName)
Name is the name of the referent.
Namespace is the namespace of the backend. When unspecified, the local namespace is inferred. Note that when a namespace different than the local namespace is specified, a ReferenceGrant object is required in the referent namespace to allow that namespace's owner to accept the reference. See the ReferenceGrant documentation for details. Support: Core
Port specifies the destination port number to use for this resource. Port is required when the referent is a Kubernetes Service. In this case, the port number is the service port number, not the target port. For other resources, destination port might be derived from the referent resource or this field.
Region is the AWS region where the guardrail is deployed (for example, `us-west-2`).
GuardrailVersion is the version of the Guardrail policy to use for the backend.
`googleModelArmor` configures Google Model Armor for prompt guarding.
Location is the Google Cloud location (for example, `us-central1`). Defaults to `us-central1` if not specified.
policies controls policies for communicating with Google Model Armor.
`auth` defines settings for managing authentication to the backend.
Auth specifies an explicit AWS authentication method for the backend. When omitted, we will try to use the default AWS SDK authentication methods.
`secretRef` references a Kubernetes `Secret` containing the AWS credentials. The `Secret` must have keys `accessKey`, `secretKey`, and optionally `sessionToken`.
Name of the referent. This field is effectively required, but due to backwards compatibility is allowed to be empty. Instances of this type with an empty value here are almost certainly wrong. More info: https://kubernetes.io/docs/concepts/overview/working-with-objects/names/#names
Azure specifies an Azure authentication method for the backend.
Details for managed identity authentication
`secretRef` references a Kubernetes `Secret` containing the Azure credentials. The `Secret` must have keys `clientID`, `tenantID`, and `clientSecret`.
Name of the referent. This field is effectively required, but due to backwards compatibility is allowed to be empty. Instances of this type with an empty value here are almost certainly wrong. More info: https://kubernetes.io/docs/concepts/overview/working-with-objects/names/#names
Auth specifies to use a Google authentication method for the backend. When omitted, we will try to use the default AWS SDK authentication methods.
`audience` allows explicitly configuring the `aud` of the ID token. Only valid with `IdToken` type. If not set, the `aud` is automatically derived from the backend hostname.
`secretRef` references a Kubernetes `Secret` containing ADC-compatible Google credential JSON in the `credentials.json` key. When omitted, ambient credentials are used.
Name of the referent. This field is effectively required, but due to backwards compatibility is allowed to be empty. Instances of this type with an empty value here are almost certainly wrong. More info: https://kubernetes.io/docs/concepts/overview/working-with-objects/names/#names
The type of token to generate. To authenticate to GCP services, generally an `AccessToken` is used. To authenticate to Cloud Run, an `IdToken` is used.
`key` provides an inline key to use as the value of the `Authorization` header. This option is the least secure; usage of a `Secret` is preferred.
`location` controls where backend credentials are inserted. If omitted, credentials are written to the `Authorization` header with the `Bearer ` prefix. This applies to `key`, `secretRef`, and `passthrough`.
HTTPHeaderName is the name of an HTTP header. Valid values include: * "Authorization" * "Set-Cookie" Invalid values include: - ":method" - ":" is an invalid character. This means that HTTP/2 pseudo headers are not currently supported by this type. - "/invalid" - "/ " is an invalid character
`passthrough` passes through an existing token that has been sent by the client and validated. Other policies, like JWT and API key authentication, will strip the original client credentials. Passthrough backend authentication causes the original token to be added back into the request. If there are no client authentication policies on the request, the original token would be unchanged, so this would have no effect.
`secretRef` references a Kubernetes `Secret` storing the key to use as the authorization value. This must be stored in the `Authorization` key.
Name of the referent. This field is effectively required, but due to backwards compatibility is allowed to be empty. Instances of this type with an empty value here are almost certainly wrong. More info: https://kubernetes.io/docs/concepts/overview/working-with-objects/names/#names
http defines settings for managing HTTP requests to the backend.
requestTimeout specifies the deadline for receiving a response from the backend.
`version` specifies the HTTP protocol version to use when connecting to the backend. If not specified, the version is automatically determined: * `Service` types can specify it with `appProtocol` on the `Service` port. * If traffic is identified as gRPC, `HTTP2` is used. * If the incoming traffic was plaintext HTTP, the original protocol will be used. * If the incoming traffic was HTTPS, `HTTP1` will be used. This is because most clients will transparently upgrade HTTPS traffic to `HTTP2`, even if the backend doesn't support it.
tcp defines settings for managing TCP connections to the backend.
`connectTimeout` defines the deadline for establishing a connection to the destination.
`keepAlive` defines settings for enabling TCP keepalives on the connection.
interval specifies the number of seconds between keep-alive probes. If unset, this defaults to 180s.
retries specifies the maximum number of keep-alive probes to send before dropping the connection. If unset, this defaults to 9.
time specifies the number of seconds a connection needs to be idle before keep-alive probes start being sent. If unset, this defaults to 180s.
tls defines settings for managing TLS connections to the backend. If this field is set, TLS will be initiated to the backend; the system trusted CA certificates will be used to validate the server, and the SNI will automatically be set based on the destination.
`alpnProtocols` sets the Application-Layer Protocol Negotiation (`ALPN`) value to use in the TLS handshake. If not present, defaults to `["h2", "http/1.1"]`.
`caCertificateRefs` defines the CA certificate `ConfigMap` to use to verify the server certificate. If unset, the system's trusted certificates are used.
Name of the referent. This field is effectively required, but due to backwards compatibility is allowed to be empty. Instances of this type with an empty value here are almost certainly wrong. More info: https://kubernetes.io/docs/concepts/overview/working-with-objects/names/#names
insecureSkipVerify originates TLS but skips verification of the backend's certificate. WARNING: This is an insecure option that should only be used if the risks are understood. There are two modes: * `All` disables all TLS verification. * `Hostname` verifies the CA certificate is trusted, but ignores any mismatch of hostname or SANs. Note that this method is still insecure; prefer setting `verifySubjectAltNames` to customize the valid hostnames if possible.
keyExchangeGroups configures the ordered list of key exchange groups for a TLS connection. For example: `X25519_MLKEM768,X25519`.
`mtlsCertificateRef` enables mutual TLS to the backend, using the specified key (`tls.key`) and cert (`tls.crt`) from the referenced `Secret`. An optional `ca.cert` field, if present, will be used to verify the server certificate. If `caCertificateRefs` is also specified, the `caCertificateRefs` field takes priority. If unspecified, no client certificate will be used.
Name of the referent. This field is effectively required, but due to backwards compatibility is allowed to be empty. Instances of this type with an empty value here are almost certainly wrong. More info: https://kubernetes.io/docs/concepts/overview/working-with-objects/names/#names
`sni` specifies the Server Name Indicator (`SNI`) to be used in the TLS handshake. If unset, the `SNI` is automatically set based on the destination hostname.
`verifySubjectAltNames` specifies the Subject Alternative Names (`SAN`) to verify in the server certificate. If not present, the destination hostname is automatically used.
`tunnel` defines settings for managing tunnel connections (with behavior like `HTTPS_PROXY`) to the backend.
`backendRef` references the proxy server to reach. Supported types: `Service` and `Backend`.
Group is the group of the referent. For example, "gateway.networking.k8s.io". When unspecified or empty string, core API group is inferred.
Kind is the Kubernetes resource kind of the referent. For example "Service". Defaults to "Service" when not specified. ExternalName services can refer to CNAME DNS records that may live outside of the cluster and as such are difficult to reason about in terms of conformance. They also may not be safe to forward to (see CVE-2021-25740 for more information). Implementations SHOULD NOT support ExternalName Services. Support: Core (Services with a type other than ExternalName) Support: Implementation-specific (Services with type ExternalName)
Name is the name of the referent.
Namespace is the namespace of the backend. When unspecified, the local namespace is inferred. Note that when a namespace different than the local namespace is specified, a ReferenceGrant object is required in the referent namespace to allow that namespace's owner to accept the reference. See the ReferenceGrant documentation for details. Support: Core
Port specifies the destination port number to use for this resource. Port is required when the referent is a Kubernetes Service. In this case, the port number is the service port number, not the target port. For other resources, destination port might be derived from the referent resource or this field.
ProjectID is the Google Cloud project ID.
TemplateID is the template ID for Google Model Armor.
`openAIModeration` passes prompt data through the OpenAI Moderations endpoint. See https://developers.openai.com/api/reference/resources/moderations for more information.
`model` specifies the moderation model to use. For example, `omni-moderation`.
policies controls policies for communicating with OpenAI.
`auth` defines settings for managing authentication to the backend.
Auth specifies an explicit AWS authentication method for the backend. When omitted, we will try to use the default AWS SDK authentication methods.
`secretRef` references a Kubernetes `Secret` containing the AWS credentials. The `Secret` must have keys `accessKey`, `secretKey`, and optionally `sessionToken`.
Name of the referent. This field is effectively required, but due to backwards compatibility is allowed to be empty. Instances of this type with an empty value here are almost certainly wrong. More info: https://kubernetes.io/docs/concepts/overview/working-with-objects/names/#names
Azure specifies an Azure authentication method for the backend.
Details for managed identity authentication
`secretRef` references a Kubernetes `Secret` containing the Azure credentials. The `Secret` must have keys `clientID`, `tenantID`, and `clientSecret`.
Name of the referent. This field is effectively required, but due to backwards compatibility is allowed to be empty. Instances of this type with an empty value here are almost certainly wrong. More info: https://kubernetes.io/docs/concepts/overview/working-with-objects/names/#names
Auth specifies to use a Google authentication method for the backend. When omitted, we will try to use the default AWS SDK authentication methods.
`audience` allows explicitly configuring the `aud` of the ID token. Only valid with `IdToken` type. If not set, the `aud` is automatically derived from the backend hostname.
`secretRef` references a Kubernetes `Secret` containing ADC-compatible Google credential JSON in the `credentials.json` key. When omitted, ambient credentials are used.
Name of the referent. This field is effectively required, but due to backwards compatibility is allowed to be empty. Instances of this type with an empty value here are almost certainly wrong. More info: https://kubernetes.io/docs/concepts/overview/working-with-objects/names/#names
The type of token to generate. To authenticate to GCP services, generally an `AccessToken` is used. To authenticate to Cloud Run, an `IdToken` is used.
`key` provides an inline key to use as the value of the `Authorization` header. This option is the least secure; usage of a `Secret` is preferred.
`location` controls where backend credentials are inserted. If omitted, credentials are written to the `Authorization` header with the `Bearer ` prefix. This applies to `key`, `secretRef`, and `passthrough`.
HTTPHeaderName is the name of an HTTP header. Valid values include: * "Authorization" * "Set-Cookie" Invalid values include: - ":method" - ":" is an invalid character. This means that HTTP/2 pseudo headers are not currently supported by this type. - "/invalid" - "/ " is an invalid character
`passthrough` passes through an existing token that has been sent by the client and validated. Other policies, like JWT and API key authentication, will strip the original client credentials. Passthrough backend authentication causes the original token to be added back into the request. If there are no client authentication policies on the request, the original token would be unchanged, so this would have no effect.
`secretRef` references a Kubernetes `Secret` storing the key to use as the authorization value. This must be stored in the `Authorization` key.
Name of the referent. This field is effectively required, but due to backwards compatibility is allowed to be empty. Instances of this type with an empty value here are almost certainly wrong. More info: https://kubernetes.io/docs/concepts/overview/working-with-objects/names/#names
http defines settings for managing HTTP requests to the backend.
requestTimeout specifies the deadline for receiving a response from the backend.
`version` specifies the HTTP protocol version to use when connecting to the backend. If not specified, the version is automatically determined: * `Service` types can specify it with `appProtocol` on the `Service` port. * If traffic is identified as gRPC, `HTTP2` is used. * If the incoming traffic was plaintext HTTP, the original protocol will be used. * If the incoming traffic was HTTPS, `HTTP1` will be used. This is because most clients will transparently upgrade HTTPS traffic to `HTTP2`, even if the backend doesn't support it.
tcp defines settings for managing TCP connections to the backend.
`connectTimeout` defines the deadline for establishing a connection to the destination.
`keepAlive` defines settings for enabling TCP keepalives on the connection.
interval specifies the number of seconds between keep-alive probes. If unset, this defaults to 180s.
retries specifies the maximum number of keep-alive probes to send before dropping the connection. If unset, this defaults to 9.
time specifies the number of seconds a connection needs to be idle before keep-alive probes start being sent. If unset, this defaults to 180s.
tls defines settings for managing TLS connections to the backend. If this field is set, TLS will be initiated to the backend; the system trusted CA certificates will be used to validate the server, and the SNI will automatically be set based on the destination.
`alpnProtocols` sets the Application-Layer Protocol Negotiation (`ALPN`) value to use in the TLS handshake. If not present, defaults to `["h2", "http/1.1"]`.
`caCertificateRefs` defines the CA certificate `ConfigMap` to use to verify the server certificate. If unset, the system's trusted certificates are used.
Name of the referent. This field is effectively required, but due to backwards compatibility is allowed to be empty. Instances of this type with an empty value here are almost certainly wrong. More info: https://kubernetes.io/docs/concepts/overview/working-with-objects/names/#names
insecureSkipVerify originates TLS but skips verification of the backend's certificate. WARNING: This is an insecure option that should only be used if the risks are understood. There are two modes: * `All` disables all TLS verification. * `Hostname` verifies the CA certificate is trusted, but ignores any mismatch of hostname or SANs. Note that this method is still insecure; prefer setting `verifySubjectAltNames` to customize the valid hostnames if possible.
keyExchangeGroups configures the ordered list of key exchange groups for a TLS connection. For example: `X25519_MLKEM768,X25519`.
`mtlsCertificateRef` enables mutual TLS to the backend, using the specified key (`tls.key`) and cert (`tls.crt`) from the referenced `Secret`. An optional `ca.cert` field, if present, will be used to verify the server certificate. If `caCertificateRefs` is also specified, the `caCertificateRefs` field takes priority. If unspecified, no client certificate will be used.
Name of the referent. This field is effectively required, but due to backwards compatibility is allowed to be empty. Instances of this type with an empty value here are almost certainly wrong. More info: https://kubernetes.io/docs/concepts/overview/working-with-objects/names/#names
`sni` specifies the Server Name Indicator (`SNI`) to be used in the TLS handshake. If unset, the `SNI` is automatically set based on the destination hostname.
`verifySubjectAltNames` specifies the Subject Alternative Names (`SAN`) to verify in the server certificate. If not present, the destination hostname is automatically used.
`tunnel` defines settings for managing tunnel connections (with behavior like `HTTPS_PROXY`) to the backend.
`backendRef` references the proxy server to reach. Supported types: `Service` and `Backend`.
Group is the group of the referent. For example, "gateway.networking.k8s.io". When unspecified or empty string, core API group is inferred.
Kind is the Kubernetes resource kind of the referent. For example "Service". Defaults to "Service" when not specified. ExternalName services can refer to CNAME DNS records that may live outside of the cluster and as such are difficult to reason about in terms of conformance. They also may not be safe to forward to (see CVE-2021-25740 for more information). Implementations SHOULD NOT support ExternalName Services. Support: Core (Services with a type other than ExternalName) Support: Implementation-specific (Services with type ExternalName)
Name is the name of the referent.
Namespace is the namespace of the backend. When unspecified, the local namespace is inferred. Note that when a namespace different than the local namespace is specified, a ReferenceGrant object is required in the referent namespace to allow that namespace's owner to accept the reference. See the ReferenceGrant documentation for details. Support: Core
Port specifies the destination port number to use for this resource. Port is required when the referent is a Kubernetes Service. In this case, the port number is the service port number, not the target port. For other resources, destination port might be derived from the referent resource or this field.
Regular expression (regex) matching for prompt guards and data masking.
The action to take if a regex pattern is matched in a request or response. This setting applies only to request matches. `PromptguardResponse` matches are always masked by default. Defaults to `Mask`.
A list of built-in regex patterns to match against the request or response. Matches and built-ins are additive.
A list of regex patterns to match against the request or response. Matches and built-ins are additive.
A custom response message to return to the client. If not specified, defaults to `The request was rejected due to inappropriate content`.
A custom response message to return to the client. If not specified, defaults to `The request was rejected due to inappropriate content`.
The status code to return to the client. Defaults to 403.
Configure a webhook to forward requests to for prompt guarding.
backendRef references the webhook server to reach. Supported types: Service and Backend.
Group is the group of the referent. For example, "gateway.networking.k8s.io". When unspecified or empty string, core API group is inferred.
Kind is the Kubernetes resource kind of the referent. For example "Service". Defaults to "Service" when not specified. ExternalName services can refer to CNAME DNS records that may live outside of the cluster and as such are difficult to reason about in terms of conformance. They also may not be safe to forward to (see CVE-2021-25740 for more information). Implementations SHOULD NOT support ExternalName Services. Support: Core (Services with a type other than ExternalName) Support: Implementation-specific (Services with type ExternalName)
Name is the name of the referent.
Namespace is the namespace of the backend. When unspecified, the local namespace is inferred. Note that when a namespace different than the local namespace is specified, a ReferenceGrant object is required in the referent namespace to allow that namespace's owner to accept the reference. See the ReferenceGrant documentation for details. Support: Core
Port specifies the destination port number to use for this resource. Port is required when the referent is a Kubernetes Service. In this case, the port number is the service port number, not the target port. For other resources, destination port might be derived from the referent resource or this field.
ForwardHeaderMatches defines a list of HTTP header matches that will be used to select the headers to forward to the webhook. Request headers are used when forwarding requests and response headers are used when forwarding responses. By default, no headers are forwarded.
Name is the name of the HTTP Header to be matched. Name matching MUST be case-insensitive. (See https://tools.ietf.org/html/rfc7230#section-3.2). If multiple entries specify equivalent header names, only the first entry with an equivalent name MUST be considered for a match. Subsequent entries with an equivalent header name MUST be ignored. Due to the case-insensitivity of header names, "foo" and "Foo" are considered equivalent. When a header is repeated in an HTTP request, it is implementation-specific behavior as to how this is represented. Generally, proxies should follow the guidance from the RFC: https://www.rfc-editor.org/rfc/rfc7230.html#section-3.2.2 regarding processing a repeated header, with special handling for "Set-Cookie".
Type specifies how to match against the value of the header. Support: Core (Exact) Support: Implementation-specific (RegularExpression) Since RegularExpression HeaderMatchType has implementation-specific conformance, implementations can support POSIX, PCRE or any other dialects of regular expressions. Please read the implementation's documentation to determine the supported dialect.
Value is the value of HTTP Header to be matched. <gateway:experimental:description> Must consist of printable US-ASCII characters, optionally separated by single tabs or spaces. See: https://tools.ietf.org/html/rfc7230#section-3.2 </gateway:experimental:description> <gateway:experimental:validation:Pattern=`^[!-~]+([\t ]?[!-~]+)*$`>
Prompt guards to apply to responses returned by the LLM provider.
`bedrockGuardrails` configures AWS Bedrock Guardrails for prompt guarding.
GuardrailIdentifier is the identifier of the Guardrail policy to use for the backend.
policies controls policies for communicating with AWS Bedrock Guardrails.
`auth` defines settings for managing authentication to the backend.
Auth specifies an explicit AWS authentication method for the backend. When omitted, we will try to use the default AWS SDK authentication methods.
`secretRef` references a Kubernetes `Secret` containing the AWS credentials. The `Secret` must have keys `accessKey`, `secretKey`, and optionally `sessionToken`.
Name of the referent. This field is effectively required, but due to backwards compatibility is allowed to be empty. Instances of this type with an empty value here are almost certainly wrong. More info: https://kubernetes.io/docs/concepts/overview/working-with-objects/names/#names
Azure specifies an Azure authentication method for the backend.
Details for managed identity authentication
`secretRef` references a Kubernetes `Secret` containing the Azure credentials. The `Secret` must have keys `clientID`, `tenantID`, and `clientSecret`.
Name of the referent. This field is effectively required, but due to backwards compatibility is allowed to be empty. Instances of this type with an empty value here are almost certainly wrong. More info: https://kubernetes.io/docs/concepts/overview/working-with-objects/names/#names
Auth specifies to use a Google authentication method for the backend. When omitted, we will try to use the default AWS SDK authentication methods.
`audience` allows explicitly configuring the `aud` of the ID token. Only valid with `IdToken` type. If not set, the `aud` is automatically derived from the backend hostname.
`secretRef` references a Kubernetes `Secret` containing ADC-compatible Google credential JSON in the `credentials.json` key. When omitted, ambient credentials are used.
Name of the referent. This field is effectively required, but due to backwards compatibility is allowed to be empty. Instances of this type with an empty value here are almost certainly wrong. More info: https://kubernetes.io/docs/concepts/overview/working-with-objects/names/#names
The type of token to generate. To authenticate to GCP services, generally an `AccessToken` is used. To authenticate to Cloud Run, an `IdToken` is used.
`key` provides an inline key to use as the value of the `Authorization` header. This option is the least secure; usage of a `Secret` is preferred.
`location` controls where backend credentials are inserted. If omitted, credentials are written to the `Authorization` header with the `Bearer ` prefix. This applies to `key`, `secretRef`, and `passthrough`.
HTTPHeaderName is the name of an HTTP header. Valid values include: * "Authorization" * "Set-Cookie" Invalid values include: - ":method" - ":" is an invalid character. This means that HTTP/2 pseudo headers are not currently supported by this type. - "/invalid" - "/ " is an invalid character
`passthrough` passes through an existing token that has been sent by the client and validated. Other policies, like JWT and API key authentication, will strip the original client credentials. Passthrough backend authentication causes the original token to be added back into the request. If there are no client authentication policies on the request, the original token would be unchanged, so this would have no effect.
`secretRef` references a Kubernetes `Secret` storing the key to use as the authorization value. This must be stored in the `Authorization` key.
Name of the referent. This field is effectively required, but due to backwards compatibility is allowed to be empty. Instances of this type with an empty value here are almost certainly wrong. More info: https://kubernetes.io/docs/concepts/overview/working-with-objects/names/#names
http defines settings for managing HTTP requests to the backend.
requestTimeout specifies the deadline for receiving a response from the backend.
`version` specifies the HTTP protocol version to use when connecting to the backend. If not specified, the version is automatically determined: * `Service` types can specify it with `appProtocol` on the `Service` port. * If traffic is identified as gRPC, `HTTP2` is used. * If the incoming traffic was plaintext HTTP, the original protocol will be used. * If the incoming traffic was HTTPS, `HTTP1` will be used. This is because most clients will transparently upgrade HTTPS traffic to `HTTP2`, even if the backend doesn't support it.
tcp defines settings for managing TCP connections to the backend.
`connectTimeout` defines the deadline for establishing a connection to the destination.
`keepAlive` defines settings for enabling TCP keepalives on the connection.
interval specifies the number of seconds between keep-alive probes. If unset, this defaults to 180s.
retries specifies the maximum number of keep-alive probes to send before dropping the connection. If unset, this defaults to 9.
time specifies the number of seconds a connection needs to be idle before keep-alive probes start being sent. If unset, this defaults to 180s.
tls defines settings for managing TLS connections to the backend. If this field is set, TLS will be initiated to the backend; the system trusted CA certificates will be used to validate the server, and the SNI will automatically be set based on the destination.
`alpnProtocols` sets the Application-Layer Protocol Negotiation (`ALPN`) value to use in the TLS handshake. If not present, defaults to `["h2", "http/1.1"]`.
`caCertificateRefs` defines the CA certificate `ConfigMap` to use to verify the server certificate. If unset, the system's trusted certificates are used.
Name of the referent. This field is effectively required, but due to backwards compatibility is allowed to be empty. Instances of this type with an empty value here are almost certainly wrong. More info: https://kubernetes.io/docs/concepts/overview/working-with-objects/names/#names
insecureSkipVerify originates TLS but skips verification of the backend's certificate. WARNING: This is an insecure option that should only be used if the risks are understood. There are two modes: * `All` disables all TLS verification. * `Hostname` verifies the CA certificate is trusted, but ignores any mismatch of hostname or SANs. Note that this method is still insecure; prefer setting `verifySubjectAltNames` to customize the valid hostnames if possible.
keyExchangeGroups configures the ordered list of key exchange groups for a TLS connection. For example: `X25519_MLKEM768,X25519`.
`mtlsCertificateRef` enables mutual TLS to the backend, using the specified key (`tls.key`) and cert (`tls.crt`) from the referenced `Secret`. An optional `ca.cert` field, if present, will be used to verify the server certificate. If `caCertificateRefs` is also specified, the `caCertificateRefs` field takes priority. If unspecified, no client certificate will be used.
Name of the referent. This field is effectively required, but due to backwards compatibility is allowed to be empty. Instances of this type with an empty value here are almost certainly wrong. More info: https://kubernetes.io/docs/concepts/overview/working-with-objects/names/#names
`sni` specifies the Server Name Indicator (`SNI`) to be used in the TLS handshake. If unset, the `SNI` is automatically set based on the destination hostname.
`verifySubjectAltNames` specifies the Subject Alternative Names (`SAN`) to verify in the server certificate. If not present, the destination hostname is automatically used.
`tunnel` defines settings for managing tunnel connections (with behavior like `HTTPS_PROXY`) to the backend.
`backendRef` references the proxy server to reach. Supported types: `Service` and `Backend`.
Group is the group of the referent. For example, "gateway.networking.k8s.io". When unspecified or empty string, core API group is inferred.
Kind is the Kubernetes resource kind of the referent. For example "Service". Defaults to "Service" when not specified. ExternalName services can refer to CNAME DNS records that may live outside of the cluster and as such are difficult to reason about in terms of conformance. They also may not be safe to forward to (see CVE-2021-25740 for more information). Implementations SHOULD NOT support ExternalName Services. Support: Core (Services with a type other than ExternalName) Support: Implementation-specific (Services with type ExternalName)
Name is the name of the referent.
Namespace is the namespace of the backend. When unspecified, the local namespace is inferred. Note that when a namespace different than the local namespace is specified, a ReferenceGrant object is required in the referent namespace to allow that namespace's owner to accept the reference. See the ReferenceGrant documentation for details. Support: Core
Port specifies the destination port number to use for this resource. Port is required when the referent is a Kubernetes Service. In this case, the port number is the service port number, not the target port. For other resources, destination port might be derived from the referent resource or this field.
Region is the AWS region where the guardrail is deployed (for example, `us-west-2`).
GuardrailVersion is the version of the Guardrail policy to use for the backend.
`googleModelArmor` configures Google Model Armor for prompt guarding.
Location is the Google Cloud location (for example, `us-central1`). Defaults to `us-central1` if not specified.
policies controls policies for communicating with Google Model Armor.
`auth` defines settings for managing authentication to the backend.
Auth specifies an explicit AWS authentication method for the backend. When omitted, we will try to use the default AWS SDK authentication methods.
`secretRef` references a Kubernetes `Secret` containing the AWS credentials. The `Secret` must have keys `accessKey`, `secretKey`, and optionally `sessionToken`.
Name of the referent. This field is effectively required, but due to backwards compatibility is allowed to be empty. Instances of this type with an empty value here are almost certainly wrong. More info: https://kubernetes.io/docs/concepts/overview/working-with-objects/names/#names
Azure specifies an Azure authentication method for the backend.
Details for managed identity authentication
`secretRef` references a Kubernetes `Secret` containing the Azure credentials. The `Secret` must have keys `clientID`, `tenantID`, and `clientSecret`.
Name of the referent. This field is effectively required, but due to backwards compatibility is allowed to be empty. Instances of this type with an empty value here are almost certainly wrong. More info: https://kubernetes.io/docs/concepts/overview/working-with-objects/names/#names
Auth specifies to use a Google authentication method for the backend. When omitted, we will try to use the default AWS SDK authentication methods.
`audience` allows explicitly configuring the `aud` of the ID token. Only valid with `IdToken` type. If not set, the `aud` is automatically derived from the backend hostname.
`secretRef` references a Kubernetes `Secret` containing ADC-compatible Google credential JSON in the `credentials.json` key. When omitted, ambient credentials are used.
Name of the referent. This field is effectively required, but due to backwards compatibility is allowed to be empty. Instances of this type with an empty value here are almost certainly wrong. More info: https://kubernetes.io/docs/concepts/overview/working-with-objects/names/#names
The type of token to generate. To authenticate to GCP services, generally an `AccessToken` is used. To authenticate to Cloud Run, an `IdToken` is used.
`key` provides an inline key to use as the value of the `Authorization` header. This option is the least secure; usage of a `Secret` is preferred.
`location` controls where backend credentials are inserted. If omitted, credentials are written to the `Authorization` header with the `Bearer ` prefix. This applies to `key`, `secretRef`, and `passthrough`.
HTTPHeaderName is the name of an HTTP header. Valid values include: * "Authorization" * "Set-Cookie" Invalid values include: - ":method" - ":" is an invalid character. This means that HTTP/2 pseudo headers are not currently supported by this type. - "/invalid" - "/ " is an invalid character
`passthrough` passes through an existing token that has been sent by the client and validated. Other policies, like JWT and API key authentication, will strip the original client credentials. Passthrough backend authentication causes the original token to be added back into the request. If there are no client authentication policies on the request, the original token would be unchanged, so this would have no effect.
`secretRef` references a Kubernetes `Secret` storing the key to use as the authorization value. This must be stored in the `Authorization` key.
Name of the referent. This field is effectively required, but due to backwards compatibility is allowed to be empty. Instances of this type with an empty value here are almost certainly wrong. More info: https://kubernetes.io/docs/concepts/overview/working-with-objects/names/#names
http defines settings for managing HTTP requests to the backend.
requestTimeout specifies the deadline for receiving a response from the backend.
`version` specifies the HTTP protocol version to use when connecting to the backend. If not specified, the version is automatically determined: * `Service` types can specify it with `appProtocol` on the `Service` port. * If traffic is identified as gRPC, `HTTP2` is used. * If the incoming traffic was plaintext HTTP, the original protocol will be used. * If the incoming traffic was HTTPS, `HTTP1` will be used. This is because most clients will transparently upgrade HTTPS traffic to `HTTP2`, even if the backend doesn't support it.
tcp defines settings for managing TCP connections to the backend.
`connectTimeout` defines the deadline for establishing a connection to the destination.
`keepAlive` defines settings for enabling TCP keepalives on the connection.
interval specifies the number of seconds between keep-alive probes. If unset, this defaults to 180s.
retries specifies the maximum number of keep-alive probes to send before dropping the connection. If unset, this defaults to 9.
time specifies the number of seconds a connection needs to be idle before keep-alive probes start being sent. If unset, this defaults to 180s.
tls defines settings for managing TLS connections to the backend. If this field is set, TLS will be initiated to the backend; the system trusted CA certificates will be used to validate the server, and the SNI will automatically be set based on the destination.
`alpnProtocols` sets the Application-Layer Protocol Negotiation (`ALPN`) value to use in the TLS handshake. If not present, defaults to `["h2", "http/1.1"]`.
`caCertificateRefs` defines the CA certificate `ConfigMap` to use to verify the server certificate. If unset, the system's trusted certificates are used.
Name of the referent. This field is effectively required, but due to backwards compatibility is allowed to be empty. Instances of this type with an empty value here are almost certainly wrong. More info: https://kubernetes.io/docs/concepts/overview/working-with-objects/names/#names
insecureSkipVerify originates TLS but skips verification of the backend's certificate. WARNING: This is an insecure option that should only be used if the risks are understood. There are two modes: * `All` disables all TLS verification. * `Hostname` verifies the CA certificate is trusted, but ignores any mismatch of hostname or SANs. Note that this method is still insecure; prefer setting `verifySubjectAltNames` to customize the valid hostnames if possible.
keyExchangeGroups configures the ordered list of key exchange groups for a TLS connection. For example: `X25519_MLKEM768,X25519`.
`mtlsCertificateRef` enables mutual TLS to the backend, using the specified key (`tls.key`) and cert (`tls.crt`) from the referenced `Secret`. An optional `ca.cert` field, if present, will be used to verify the server certificate. If `caCertificateRefs` is also specified, the `caCertificateRefs` field takes priority. If unspecified, no client certificate will be used.
Name of the referent. This field is effectively required, but due to backwards compatibility is allowed to be empty. Instances of this type with an empty value here are almost certainly wrong. More info: https://kubernetes.io/docs/concepts/overview/working-with-objects/names/#names
`sni` specifies the Server Name Indicator (`SNI`) to be used in the TLS handshake. If unset, the `SNI` is automatically set based on the destination hostname.
`verifySubjectAltNames` specifies the Subject Alternative Names (`SAN`) to verify in the server certificate. If not present, the destination hostname is automatically used.
`tunnel` defines settings for managing tunnel connections (with behavior like `HTTPS_PROXY`) to the backend.
`backendRef` references the proxy server to reach. Supported types: `Service` and `Backend`.
Group is the group of the referent. For example, "gateway.networking.k8s.io". When unspecified or empty string, core API group is inferred.
Kind is the Kubernetes resource kind of the referent. For example "Service". Defaults to "Service" when not specified. ExternalName services can refer to CNAME DNS records that may live outside of the cluster and as such are difficult to reason about in terms of conformance. They also may not be safe to forward to (see CVE-2021-25740 for more information). Implementations SHOULD NOT support ExternalName Services. Support: Core (Services with a type other than ExternalName) Support: Implementation-specific (Services with type ExternalName)
Name is the name of the referent.
Namespace is the namespace of the backend. When unspecified, the local namespace is inferred. Note that when a namespace different than the local namespace is specified, a ReferenceGrant object is required in the referent namespace to allow that namespace's owner to accept the reference. See the ReferenceGrant documentation for details. Support: Core
Port specifies the destination port number to use for this resource. Port is required when the referent is a Kubernetes Service. In this case, the port number is the service port number, not the target port. For other resources, destination port might be derived from the referent resource or this field.
ProjectID is the Google Cloud project ID.
TemplateID is the template ID for Google Model Armor.
Regular expression (regex) matching for prompt guards and data masking.
The action to take if a regex pattern is matched in a request or response. This setting applies only to request matches. `PromptguardResponse` matches are always masked by default. Defaults to `Mask`.
A list of built-in regex patterns to match against the request or response. Matches and built-ins are additive.
A list of regex patterns to match against the request or response. Matches and built-ins are additive.
A custom response message to return to the client. If not specified, defaults to `The response was rejected due to inappropriate content`.
A custom response message to return to the client. If not specified, defaults to `The request was rejected due to inappropriate content`.
The status code to return to the client. Defaults to 403.
Configure a webhook to forward responses to for prompt guarding.
backendRef references the webhook server to reach. Supported types: Service and Backend.
Group is the group of the referent. For example, "gateway.networking.k8s.io". When unspecified or empty string, core API group is inferred.
Kind is the Kubernetes resource kind of the referent. For example "Service". Defaults to "Service" when not specified. ExternalName services can refer to CNAME DNS records that may live outside of the cluster and as such are difficult to reason about in terms of conformance. They also may not be safe to forward to (see CVE-2021-25740 for more information). Implementations SHOULD NOT support ExternalName Services. Support: Core (Services with a type other than ExternalName) Support: Implementation-specific (Services with type ExternalName)
Name is the name of the referent.
Namespace is the namespace of the backend. When unspecified, the local namespace is inferred. Note that when a namespace different than the local namespace is specified, a ReferenceGrant object is required in the referent namespace to allow that namespace's owner to accept the reference. See the ReferenceGrant documentation for details. Support: Core
Port specifies the destination port number to use for this resource. Port is required when the referent is a Kubernetes Service. In this case, the port number is the service port number, not the target port. For other resources, destination port might be derived from the referent resource or this field.
ForwardHeaderMatches defines a list of HTTP header matches that will be used to select the headers to forward to the webhook. Request headers are used when forwarding requests and response headers are used when forwarding responses. By default, no headers are forwarded.
Name is the name of the HTTP Header to be matched. Name matching MUST be case-insensitive. (See https://tools.ietf.org/html/rfc7230#section-3.2). If multiple entries specify equivalent header names, only the first entry with an equivalent name MUST be considered for a match. Subsequent entries with an equivalent header name MUST be ignored. Due to the case-insensitivity of header names, "foo" and "Foo" are considered equivalent. When a header is repeated in an HTTP request, it is implementation-specific behavior as to how this is represented. Generally, proxies should follow the guidance from the RFC: https://www.rfc-editor.org/rfc/rfc7230.html#section-3.2.2 regarding processing a repeated header, with special handling for "Set-Cookie".
Type specifies how to match against the value of the header. Support: Core (Exact) Support: Implementation-specific (RegularExpression) Since RegularExpression HeaderMatchType has implementation-specific conformance, implementations can support POSIX, PCRE or any other dialects of regular expressions. Please read the implementation's documentation to determine the supported dialect.
Value is the value of HTTP Header to be matched. <gateway:experimental:description> Must consist of printable US-ASCII characters, optionally separated by single tabs or spaces. See: https://tools.ietf.org/html/rfc7230#section-3.2 </gateway:experimental:description> <gateway:experimental:validation:Pattern=`^[!-~]+([\t ]?[!-~]+)*$`>
`routes` defines how to identify the type of traffic to handle. The keys are URL path suffixes matched using ends-with comparison, for example `"/v1/chat/completions"`. The special `*` wildcard matches any path. If not specified, all traffic defaults to `completions` type.
Provide CEL transformations to compute and set fields in the request body. The expression result overwrites any existing value for that field. This has a higher priority than `overrides` if both are set for the same key.
CEL expression used to compute the field value.
The name of the field to set.
`auth` defines settings for managing authentication to the backend.
Auth specifies an explicit AWS authentication method for the backend. When omitted, we will try to use the default AWS SDK authentication methods.
`secretRef` references a Kubernetes `Secret` containing the AWS credentials. The `Secret` must have keys `accessKey`, `secretKey`, and optionally `sessionToken`.
Name of the referent. This field is effectively required, but due to backwards compatibility is allowed to be empty. Instances of this type with an empty value here are almost certainly wrong. More info: https://kubernetes.io/docs/concepts/overview/working-with-objects/names/#names
Azure specifies an Azure authentication method for the backend.
Details for managed identity authentication
`secretRef` references a Kubernetes `Secret` containing the Azure credentials. The `Secret` must have keys `clientID`, `tenantID`, and `clientSecret`.
Name of the referent. This field is effectively required, but due to backwards compatibility is allowed to be empty. Instances of this type with an empty value here are almost certainly wrong. More info: https://kubernetes.io/docs/concepts/overview/working-with-objects/names/#names
Auth specifies to use a Google authentication method for the backend. When omitted, we will try to use the default AWS SDK authentication methods.
`audience` allows explicitly configuring the `aud` of the ID token. Only valid with `IdToken` type. If not set, the `aud` is automatically derived from the backend hostname.
`secretRef` references a Kubernetes `Secret` containing ADC-compatible Google credential JSON in the `credentials.json` key. When omitted, ambient credentials are used.
Name of the referent. This field is effectively required, but due to backwards compatibility is allowed to be empty. Instances of this type with an empty value here are almost certainly wrong. More info: https://kubernetes.io/docs/concepts/overview/working-with-objects/names/#names
The type of token to generate. To authenticate to GCP services, generally an `AccessToken` is used. To authenticate to Cloud Run, an `IdToken` is used.
`key` provides an inline key to use as the value of the `Authorization` header. This option is the least secure; usage of a `Secret` is preferred.
`location` controls where backend credentials are inserted. If omitted, credentials are written to the `Authorization` header with the `Bearer ` prefix. This applies to `key`, `secretRef`, and `passthrough`.
HTTPHeaderName is the name of an HTTP header. Valid values include: * "Authorization" * "Set-Cookie" Invalid values include: - ":method" - ":" is an invalid character. This means that HTTP/2 pseudo headers are not currently supported by this type. - "/invalid" - "/ " is an invalid character
`passthrough` passes through an existing token that has been sent by the client and validated. Other policies, like JWT and API key authentication, will strip the original client credentials. Passthrough backend authentication causes the original token to be added back into the request. If there are no client authentication policies on the request, the original token would be unchanged, so this would have no effect.
`secretRef` references a Kubernetes `Secret` storing the key to use as the authorization value. This must be stored in the `Authorization` key.
Name of the referent. This field is effectively required, but due to backwards compatibility is allowed to be empty. Instances of this type with an empty value here are almost certainly wrong. More info: https://kubernetes.io/docs/concepts/overview/working-with-objects/names/#names
extAuth specifies the external authentication configuration for requests sent to this backend.
`backendRef` references the External Authorization server to reach. Supported types: `Service` and `Backend`.
Group is the group of the referent. For example, "gateway.networking.k8s.io". When unspecified or empty string, core API group is inferred.
Kind is the Kubernetes resource kind of the referent. For example "Service". Defaults to "Service" when not specified. ExternalName services can refer to CNAME DNS records that may live outside of the cluster and as such are difficult to reason about in terms of conformance. They also may not be safe to forward to (see CVE-2021-25740 for more information). Implementations SHOULD NOT support ExternalName Services. Support: Core (Services with a type other than ExternalName) Support: Implementation-specific (Services with type ExternalName)
Name is the name of the referent.
Namespace is the namespace of the backend. When unspecified, the local namespace is inferred. Note that when a namespace different than the local namespace is specified, a ReferenceGrant object is required in the referent namespace to allow that namespace's owner to accept the reference. See the ReferenceGrant documentation for details. Support: Core
Port specifies the destination port number to use for this resource. Port is required when the referent is a Kubernetes Service. In this case, the port number is the service port number, not the target port. For other resources, destination port might be derived from the referent resource or this field.
FailureMode controls behavior when the external authorization service is unavailable or returns an error. "FailOpen" allows the request to continue. "FailClosed" (default) denies the request.
`forwardBody` configures whether to include the HTTP body in the request. If enabled, the request body will be buffered.
`maxSize` specifies, in bytes, the largest body that will be buffered and sent to the authorization server. If the body size is larger than `maxSize`, then the request will be rejected with a response.
grpc specifies that the gRPC External Authorization [protocol](https://www.envoyproxy.io/docs/envoy/latest/api-v3/service/auth/v3/external_auth.proto) should be used.
`contextExtensions` specifies additional arbitrary key-value pairs to send to the authorization server in the `context_extensions` field.
`requestMetadata` specifies metadata to be sent to the authorization server. This maps to the `metadata_context.filter_metadata` field of the request, and allows dynamic CEL expressions. If unset, by default the `envoy.filters.http.jwt_authn` key is set if the JWT policy is used as well, for compatibility.
`http` specifies that the HTTP protocol should be used for connecting to the authorization server. The authorization server must return a `200` status code, otherwise the request is considered an authorization failure.
`addRequestHeaders` specifies what additional headers to add to the request to the authorization server. While `allowedRequestHeaders` just passes the original headers through, `addRequestHeaders` allows defining custom headers based on CEL expressions.
`allowedRequestHeaders` specifies what additional headers from the client request will be sent to the authorization server. If unset, the following headers are sent by default: `Authorization`.
`allowedResponseHeaders` specifies what headers from the authorization response will be copied into the request to the backend.
`path` specifies the path to send to the authorization server. If unset, this defaults to the original request path. This is a CEL expression, which allows customizing the path based on the incoming request. For example, to add a prefix, use `"/prefix/" + request.path`.
`redirect` defines an optional expression to determine a path to redirect to on authorization failure. This is useful to redirect to a sign-in page.
`responseMetadata` specifies what metadata fields should be constructed from the authorization response. These will be included under the `extauthz` variable in future CEL expressions. Setting this is useful for things like logging usernames, without needing to include them as headers to the backend, as `allowedResponseHeaders` would.
health defines settings for passive and active health checking.
Eviction defines settings for evicting unhealthy backends.
ConsecutiveFailures is the number of consecutive unhealthy responses required before the backend is evicted. For example, a value of 5 means the backend must receive 5 unhealthy responses in a row before being evicted. When both consecutiveFailures and healthThreshold are set, the backend is evicted when either condition is met. When neither is set, a single unhealthy response can trigger eviction.
Duration specifies the base time a backend should be evicted after being marked unhealthy. Subsequent evictions use multiplicative backoff (duration * times_evicted). If all endpoints are evicted, the load balancer falls back to returning evicted endpoints rather than failing entirely. If unset, defaults to `3s`.
HealthThreshold is the EWMA (exponentially-weighted moving average) health score threshold, expressed as 0–100. When set, a backend is only evicted if its computed health drops below this value after an unhealthy response. For example, 50 means the backend is evicted when its EWMA health falls below 50% following failures. Unlike consecutiveFailures (which counts consecutive failures), this uses a sliding-window average so a single success in a stream of failures can delay eviction. When both consecutiveFailures and healthThreshold are set, the backend is evicted when either condition is met. When neither is set, a single unhealthy response triggers eviction.
RestoreHealth is the health score (0–100) assigned to a backend when it returns from eviction. For gradual recovery, set below 100; for full recovery immediately, set 100. If unset, the backend resumes with the health it had when evicted.
UnhealthyCondition is a CEL expression that determines whether a response indicates an unhealthy backend. When the expression evaluates to true, the backend is considered unhealthy and may be evicted. For example, to evict on 5xx responses: `response.code >= 500`. When unset, any 5xx response, or a connection failure, is treated as unhealthy. This default lowers the backend's health score but does not trigger eviction on its own.
http defines settings for managing HTTP requests to the backend.
requestTimeout specifies the deadline for receiving a response from the backend.
`version` specifies the HTTP protocol version to use when connecting to the backend. If not specified, the version is automatically determined: * `Service` types can specify it with `appProtocol` on the `Service` port. * If traffic is identified as gRPC, `HTTP2` is used. * If the incoming traffic was plaintext HTTP, the original protocol will be used. * If the incoming traffic was HTTPS, `HTTP1` will be used. This is because most clients will transparently upgrade HTTPS traffic to `HTTP2`, even if the backend doesn't support it.
`mcp` specifies settings for MCP workloads. This is only applicable when connecting to a `Backend` of type `mcp`.
`authentication` defines `MCPBackend`-specific authentication rules. This field is deprecated; prefer to use traffic policy `jwtAuthentication.mcp`, which ensures authentication runs before other policies such as transformation and rate limiting.
`audiences` specifies the list of allowed audiences that are allowed access. This corresponds to the `aud` claim ([RFC 7519 §4.1.3](https://datatracker.ietf.org/doc/html/rfc7519#section-4.1.3)). If unset, any audience is allowed.
`issuer` identifies the IdP that issued the JWT. This corresponds to the `iss` claim ([RFC 7519 §4.1.1](https://tools.ietf.org/html/rfc7519#section-4.1.1)).
`jwks` defines the remote JSON Web Key used to validate the signature of the JWT.
`backendRef` references the remote JWKS server to reach. Supported types are `Service` and static `Backend`. An `AgentgatewayPolicy` containing backend TLS config can then be attached to the `Service` or `Backend` in order to set TLS options for a connection to the remote `jwks` source.
Group is the group of the referent. For example, "gateway.networking.k8s.io". When unspecified or empty string, core API group is inferred.
Kind is the Kubernetes resource kind of the referent. For example "Service". Defaults to "Service" when not specified. ExternalName services can refer to CNAME DNS records that may live outside of the cluster and as such are difficult to reason about in terms of conformance. They also may not be safe to forward to (see CVE-2021-25740 for more information). Implementations SHOULD NOT support ExternalName Services. Support: Core (Services with a type other than ExternalName) Support: Implementation-specific (Services with type ExternalName)
Name is the name of the referent.
Namespace is the namespace of the backend. When unspecified, the local namespace is inferred. Note that when a namespace different than the local namespace is specified, a ReferenceGrant object is required in the referent namespace to allow that namespace's owner to accept the reference. See the ReferenceGrant documentation for details. Support: Core
Port specifies the destination port number to use for this resource. Port is required when the referent is a Kubernetes Service. In this case, the port number is the service port number, not the target port. For other resources, destination port might be derived from the referent resource or this field.
Path to the IdP `jwks` endpoint, relative to the root, commonly `".well-known/jwks.json"`.
`mode` is the validation mode for JWT authentication.
`provider` specifies the identity provider to use for authentication.
ResourceMetadata defines the metadata to use for MCP resources.
authorization defines MCPBackend level authorization. Unlike authorization at the HTTP level, which will reject unauthorized requests with a `403` error, this policy works at the `MCPBackend` level. List operations, such as `list_tools`, will have each item evaluated. Items that do not meet the rule will be filtered. Get or call operations, such as `call_tool`, will evaluate the specific item and reject requests that do not meet the rule.
`action` defines whether the rule allows, denies, or requires the request if matched. If unspecified, the default is `Allow`. Require policies are conjunctive across merged policies: all require policies must match.
`policy` specifies the authorization rule to evaluate. * For `Allow` rules: any policy allows the request. * For `Require` rules: all policies must match for the request to be allowed. * For `Deny` rules: any matching policy denies the request. Note: a CEL expression that fails to evaluate is not considered to match, making this a risky policy; prefer to use `Require`. The presence of at least one `Allow` rule triggers a deny-by-default policy, requiring at least 1 match to allow. With no rules, all requires are allowed.
MatchExpressions defines a set of conditions that must be satisfied for the rule to match. These expressions should be in the form of a Common Expression Language (`CEL`) expression.
tcp defines settings for managing TCP connections to the backend.
`connectTimeout` defines the deadline for establishing a connection to the destination.
`keepAlive` defines settings for enabling TCP keepalives on the connection.
interval specifies the number of seconds between keep-alive probes. If unset, this defaults to 180s.
retries specifies the maximum number of keep-alive probes to send before dropping the connection. If unset, this defaults to 9.
time specifies the number of seconds a connection needs to be idle before keep-alive probes start being sent. If unset, this defaults to 180s.
tls defines settings for managing TLS connections to the backend. If this field is set, TLS will be initiated to the backend; the system trusted CA certificates will be used to validate the server, and the SNI will automatically be set based on the destination.
`alpnProtocols` sets the Application-Layer Protocol Negotiation (`ALPN`) value to use in the TLS handshake. If not present, defaults to `["h2", "http/1.1"]`.
`caCertificateRefs` defines the CA certificate `ConfigMap` to use to verify the server certificate. If unset, the system's trusted certificates are used.
Name of the referent. This field is effectively required, but due to backwards compatibility is allowed to be empty. Instances of this type with an empty value here are almost certainly wrong. More info: https://kubernetes.io/docs/concepts/overview/working-with-objects/names/#names
insecureSkipVerify originates TLS but skips verification of the backend's certificate. WARNING: This is an insecure option that should only be used if the risks are understood. There are two modes: * `All` disables all TLS verification. * `Hostname` verifies the CA certificate is trusted, but ignores any mismatch of hostname or SANs. Note that this method is still insecure; prefer setting `verifySubjectAltNames` to customize the valid hostnames if possible.
keyExchangeGroups configures the ordered list of key exchange groups for a TLS connection. For example: `X25519_MLKEM768,X25519`.
`mtlsCertificateRef` enables mutual TLS to the backend, using the specified key (`tls.key`) and cert (`tls.crt`) from the referenced `Secret`. An optional `ca.cert` field, if present, will be used to verify the server certificate. If `caCertificateRefs` is also specified, the `caCertificateRefs` field takes priority. If unspecified, no client certificate will be used.
Name of the referent. This field is effectively required, but due to backwards compatibility is allowed to be empty. Instances of this type with an empty value here are almost certainly wrong. More info: https://kubernetes.io/docs/concepts/overview/working-with-objects/names/#names
`sni` specifies the Server Name Indicator (`SNI`) to be used in the TLS handshake. If unset, the `SNI` is automatically set based on the destination hostname.
`verifySubjectAltNames` specifies the Subject Alternative Names (`SAN`) to verify in the server certificate. If not present, the destination hostname is automatically used.
transformation is used to mutate and transform requests and responses sent to and from the backend.
`request` is used to modify the request path.
`add` is a list of headers to add to the request and what that value should be set to. If there is already a header with these values then append the value as an extra entry.
The name of the header to add.
`value` is the CEL expression to apply to generate the output value for the header.
`body` controls manipulation of the HTTP body.
`metadata` stores CEL-evaluated values under the `metadata` CEL variable for subsequent policy evaluations. `metadata` is evaluated before header or body transformations.
`remove` is a list of header names to remove from the request or response.
`set` is a list of headers and the value they should be set to.
The name of the header to add.
`value` is the CEL expression to apply to generate the output value for the header.
`response` is used to modify the response path.
`add` is a list of headers to add to the request and what that value should be set to. If there is already a header with these values then append the value as an extra entry.
The name of the header to add.
`value` is the CEL expression to apply to generate the output value for the header.
`body` controls manipulation of the HTTP body.
`metadata` stores CEL-evaluated values under the `metadata` CEL variable for subsequent policy evaluations. `metadata` is evaluated before header or body transformations.
`remove` is a list of header names to remove from the request or response.
`set` is a list of headers and the value they should be set to.
The name of the header to add.
`value` is the CEL expression to apply to generate the output value for the header.
`tunnel` defines settings for managing tunnel connections (with behavior like `HTTPS_PROXY`) to the backend.
`backendRef` references the proxy server to reach. Supported types: `Service` and `Backend`.
Group is the group of the referent. For example, "gateway.networking.k8s.io". When unspecified or empty string, core API group is inferred.
Kind is the Kubernetes resource kind of the referent. For example "Service". Defaults to "Service" when not specified. ExternalName services can refer to CNAME DNS records that may live outside of the cluster and as such are difficult to reason about in terms of conformance. They also may not be safe to forward to (see CVE-2021-25740 for more information). Implementations SHOULD NOT support ExternalName Services. Support: Core (Services with a type other than ExternalName) Support: Implementation-specific (Services with type ExternalName)
Name is the name of the referent.
Namespace is the namespace of the backend. When unspecified, the local namespace is inferred. Note that when a namespace different than the local namespace is specified, a ReferenceGrant object is required in the referent namespace to allow that namespace's owner to accept the reference. See the ReferenceGrant documentation for details. Support: Core
Port specifies the destination port number to use for this resource. Port is required when the referent is a Kubernetes Service. In this case, the port number is the service port number, not the target port. For other resources, destination port might be derived from the referent resource or this field.
static represents a static hostname.
host to connect to (for TCP backends).
port to connect to (for TCP backends).
unixPath is the filesystem path to a Unix Domain Socket. The gateway pod must share a volume with the target (e.g., via emptyDir sidecar pattern). Mutually exclusive with host/port.
status defines the current state of AgentgatewayBackend.
Conditions is the list of conditions for the backend.
lastTransitionTime is the last time the condition transitioned from one status to another. This should be when the underlying condition changed. If that is not known, then using the time when the API field changed is acceptable.
message is a human readable message indicating details about the transition. This may be an empty string.
observedGeneration represents the .metadata.generation that the condition was set based upon. For instance, if .metadata.generation is currently 12, but the .status.conditions[x].observedGeneration is 9, the condition is out of date with respect to the current state of the instance.
reason contains a programmatic identifier indicating the reason for the condition's last transition. Producers of specific condition types may define expected values and meanings for this field, and whether the values are considered a guaranteed API. The value should be a CamelCase string. This field may not be empty.
status of the condition, one of True, False, Unknown.
type of condition in CamelCase or in foo.example.com/CamelCase.
Source: agentgateway.dev_agentgatewaybackends.yaml
Changes to AgentgatewayBackend (agentgateway.dev/v1alpha1) in each Agentgateway version, compared to the version before it.
45 properties have been added
22 properties have been removed
2 properties are no longer required
23 properties have changed the description
Released · View AgentgatewayBackend in v1.2.0
3 properties have been added
1 property has been removed
3 properties are no longer required
603 properties have changed the description
Released · View AgentgatewayBackend in v1.1.0
1 property has been added
Released · View AgentgatewayBackend in v1.0.1
AgentgatewayBackend was already present in this version of Agentgateway, the oldest one on kubespec.dev
Released · View AgentgatewayBackend in v1.0.0
No examples of AgentgatewayBackend yet. Contribute one on GitHub.
kubespec.dev