Gateway
gateway.networking.k8s.io / v1
apiVersion: gateway.networking.k8s.io/v1
kind: Gateway
metadata:
name: example
apiVersion
string
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
string
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
metadata
object
spec object required
Spec defines the desired state of Gateway.
addresses []object
Addresses requested for this Gateway. This is optional and behavior can
depend on the implementation. If a value is set in the spec and the
requested address is invalid or unavailable, the implementation MUST
indicate this in an associated entry in GatewayStatus.Conditions.
The Addresses field represents a request for the address(es) on the
"outside of the Gateway", that traffic bound for this Gateway will use.
This could be the IP address or hostname of an external load balancer or
other networking infrastructure, or some other address that traffic will
be sent to.
If no Addresses are specified, the implementation MAY schedule the
Gateway in an implementation-specific manner, assigning an appropriate
set of Addresses.
The implementation MUST bind all Listeners to every GatewayAddress that
it assigns to the Gateway and add a corresponding entry in
GatewayStatus.Addresses.
Support: Extended
maxItems:
16
type
string
Type of the address.
pattern:
^Hostname|IPAddress|NamedAddress|[a-z0-9]([-a-z0-9]*[a-z0-9])?(\.[a-z0-9]([-a-z0-9]*[a-z0-9])?)*\/[A-Za-z0-9\/\-._~%!$&'()*+,;=:]+$minLength:
1maxLength:
253
value
string
When a value is unspecified, an implementation SHOULD automatically
assign an address matching the requested type if possible.
If an implementation does not support an empty value, they MUST set the
"Programmed" condition in status to False with a reason of "AddressNotAssigned".
Examples: `1.2.3.4`, `128::1`, `my-ip-address`.
maxLength:
253allowedListeners object
AllowedListeners defines which ListenerSets can be attached to this Gateway.
The default value is to allow no ListenerSets.
namespaces object
Namespaces defines which namespaces ListenerSets can be attached to this Gateway.
The default value is to allow no ListenerSets.
from
string
From indicates where ListenerSets can attach to this Gateway. Possible
values are:
* Same: Only ListenerSets in the same namespace may be attached to this Gateway.
* Selector: ListenerSets in namespaces selected by the selector may be attached to this Gateway.
* All: ListenerSets in all namespaces may be attached to this Gateway.
* None: Only listeners defined in the Gateway's spec are allowed
The default value None
enum:
All, Selector, Same, Noneselector object
Selector must be specified when From is set to "Selector". In that case,
only ListenerSets in Namespaces matching this Selector will be selected by this
Gateway. This field is ignored for other values of "From".
matchExpressions []object
matchExpressions is a list of label selector requirements. The requirements are ANDed.
key
string required
key is the label key that the selector applies to.
operator
string required
operator represents a key's relationship to a set of values.
Valid operators are In, NotIn, Exists and DoesNotExist.
values
[]string
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
object
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.
defaultScope
string
DefaultScope, when set, configures the Gateway as a default Gateway,
meaning it will dynamically and implicitly have Routes (e.g. HTTPRoute)
attached to it, according to the scope configured here.
If unset (the default) or set to None, the Gateway will not act as a
default Gateway; if set, the Gateway will claim any Route with a
matching scope set in its UseDefaultGateway field, subject to the usual
rules about which routes the Gateway can attach to.
Think carefully before using this functionality! While the normal rules
about which Route can apply are still enforced, it is simply easier for
the wrong Route to be accidentally attached to this Gateway in this
configuration. If the Gateway operator is not also the operator in
control of the scope (e.g. namespace) with tight controls and checks on
what kind of workloads and Routes get added in that scope, we strongly
recommend not using this just because it seems convenient, and instead
stick to direct Route attachment.
enum:
All, None
gatewayClassName
string required
GatewayClassName used for this Gateway. This is the name of a
GatewayClass resource.
minLength:
1maxLength:
253infrastructure object
Infrastructure defines infrastructure level attributes about this Gateway instance.
Support: Extended
annotations
object
Annotations that SHOULD be applied to any resources created in response to this Gateway.
For implementations creating other Kubernetes objects, this should be the `metadata.annotations` field on resources.
For other implementations, this refers to any relevant (implementation specific) "annotations" concepts.
An implementation may chose to add additional implementation-specific annotations as they see fit.
Support: Extended
labels
object
Labels that SHOULD be applied to any resources created in response to this Gateway.
For implementations creating other Kubernetes objects, this should be the `metadata.labels` field on resources.
For other implementations, this refers to any relevant (implementation specific) "labels" concepts.
An implementation may chose to add additional implementation-specific labels as they see fit.
If an implementation maps these labels to Pods, or any other resource that would need to be recreated when labels
change, it SHOULD clearly warn about this behavior in documentation.
Support: Extended
parametersRef object
ParametersRef is a reference to a resource that contains the configuration
parameters corresponding to the Gateway. This is optional if the
controller does not require any additional configuration.
This follows the same semantics as GatewayClass's `parametersRef`, but on a per-Gateway basis
The Gateway's GatewayClass may provide its own `parametersRef`. When both are specified,
the merging behavior is implementation specific.
It is generally recommended that GatewayClass provides defaults that can be overridden by a Gateway.
If the referent cannot be found, refers to an unsupported kind, or when
the data within that resource is malformed, the Gateway SHOULD be
rejected with the "Accepted" status condition set to "False" and an
"InvalidParameters" reason.
Support: Implementation-specific
group
string required
Group is the group of the referent.
pattern:
^$|^[a-z0-9]([-a-z0-9]*[a-z0-9])?(\.[a-z0-9]([-a-z0-9]*[a-z0-9])?)*$maxLength:
253
kind
string required
Kind is kind of the referent.
pattern:
^[a-zA-Z]([-a-zA-Z0-9]*[a-zA-Z0-9])?$minLength:
1maxLength:
63
name
string required
Name is the name of the referent.
minLength:
1maxLength:
253listeners []object required
Listeners associated with this Gateway. Listeners define
logical endpoints that are bound on this Gateway's addresses.
At least one Listener MUST be specified.
## Distinct Listeners
Each Listener in a set of Listeners (for example, in a single Gateway)
MUST be _distinct_, in that a traffic flow MUST be able to be assigned to
exactly one listener. (This section uses "set of Listeners" rather than
"Listeners in a single Gateway" because implementations MAY merge configuration
from multiple Gateways onto a single data plane, and these rules _also_
apply in that case).
Practically, this means that each listener in a set MUST have a unique
combination of Port, Protocol, and, if supported by the protocol, Hostname.
Some combinations of port, protocol, and TLS settings are considered
Core support and MUST be supported by implementations based on the objects
they support:
HTTPRoute
1. HTTPRoute, Port: 80, Protocol: HTTP
2. HTTPRoute, Port: 443, Protocol: HTTPS, TLS Mode: Terminate, TLS keypair provided
TLSRoute
1. TLSRoute, Port: 443, Protocol: TLS, TLS Mode: Passthrough
"Distinct" Listeners have the following property:
**The implementation can match inbound requests to a single distinct
Listener**.
When multiple Listeners share values for fields (for
example, two Listeners with the same Port value), the implementation
can match requests to only one of the Listeners using other
Listener fields.
When multiple listeners have the same value for the Protocol field, then
each of the Listeners with matching Protocol values MUST have different
values for other fields.
The set of fields that MUST be different for a Listener differs per protocol.
The following rules define the rules for what fields MUST be considered for
Listeners to be distinct with each protocol currently defined in the
Gateway API spec.
The set of listeners that all share a protocol value MUST have _different_
values for _at least one_ of these fields to be distinct:
* **HTTP, HTTPS, TLS**: Port, Hostname
* **TCP, UDP**: Port
One **very** important rule to call out involves what happens when an
implementation:
* Supports TCP protocol Listeners, as well as HTTP, HTTPS, or TLS protocol
Listeners, and
* sees HTTP, HTTPS, or TLS protocols with the same `port` as one with TCP
Protocol.
In this case all the Listeners that share a port with the
TCP Listener are not distinct and so MUST NOT be accepted.
If an implementation does not support TCP Protocol Listeners, then the
previous rule does not apply, and the TCP Listeners SHOULD NOT be
accepted.
Note that the `tls` field is not used for determining if a listener is distinct, because
Listeners that _only_ differ on TLS config will still conflict in all cases.
### Listeners that are distinct only by Hostname
When the Listeners are distinct based only on Hostname, inbound request
hostnames MUST match from the most specific to least specific Hostname
values to choose the correct Listener and its associated set of Routes.
Exact matches MUST be processed before wildcard matches, and wildcard
matches MUST be processed before fallback (empty Hostname value)
matches. For example, `"foo.example.com"` takes precedence over
`"*.example.com"`, and `"*.example.com"` takes precedence over `""`.
Additionally, if there are multiple wildcard entries, more specific
wildcard entries must be processed before less specific wildcard entries.
For example, `"*.foo.example.com"` takes precedence over `"*.example.com"`.
The precise definition here is that the higher the number of dots in the
hostname to the right of the wildcard character, the higher the precedence.
The wildcard character will match any number of characters _and dots_ to
the left, however, so `"*.example.com"` will match both
`"foo.bar.example.com"` _and_ `"bar.example.com"`.
## Handling indistinct Listeners
If a set of Listeners contains Listeners that are not distinct, then those
Listeners are _Conflicted_, and the implementation MUST set the "Conflicted"
condition in the Listener Status to "True".
The words "indistinct" and "conflicted" are considered equivalent for the
purpose of this documentation.
Implementations MAY choose to accept a Gateway with some Conflicted
Listeners only if they only accept the partial Listener set that contains
no Conflicted Listeners.
Specifically, an implementation MAY accept a partial Listener set subject to
the following rules:
* The implementation MUST NOT pick one conflicting Listener as the winner.
ALL indistinct Listeners must not be accepted for processing.
* At least one distinct Listener MUST be present, or else the Gateway effectively
contains _no_ Listeners, and must be rejected from processing as a whole.
The implementation MUST set a "ListenersNotValid" condition on the
Gateway Status when the Gateway contains Conflicted Listeners whether or
not they accept the Gateway. That Condition SHOULD clearly
indicate in the Message which Listeners are conflicted, and which are
Accepted. Additionally, the Listener status for those listeners SHOULD
indicate which Listeners are conflicted and not Accepted.
## General Listener behavior
Note that, for all distinct Listeners, requests SHOULD match at most one Listener.
For example, if Listeners are defined for "foo.example.com" and "*.example.com", a
request to "foo.example.com" SHOULD only be routed using routes attached
to the "foo.example.com" Listener (and not the "*.example.com" Listener).
This concept is known as "Listener Isolation", and it is an Extended feature
of Gateway API. Implementations that do not support Listener Isolation MUST
clearly document this, and MUST NOT claim support for the
`GatewayHTTPListenerIsolation` feature.
Implementations that _do_ support Listener Isolation SHOULD claim support
for the Extended `GatewayHTTPListenerIsolation` feature and pass the associated
conformance tests.
## Compatible Listeners
A Gateway's Listeners are considered _compatible_ if:
1. They are distinct.
2. The implementation can serve them in compliance with the Addresses
requirement that all Listeners are available on all assigned
addresses.
Compatible combinations in Extended support are expected to vary across
implementations. A combination that is compatible for one implementation
may not be compatible for another.
For example, an implementation that cannot serve both TCP and UDP listeners
on the same address, or cannot mix HTTPS and generic TLS listens on the same port
would not consider those cases compatible, even though they are distinct.
Implementations MAY merge separate Gateways onto a single set of
Addresses if all Listeners across all Gateways are compatible.
In a future release the MinItems=1 requirement MAY be dropped.
Support: Core
minItems:
1maxItems:
64allowedRoutes object
AllowedRoutes defines the types of routes that MAY be attached to a
Listener and the trusted namespaces where those Route resources MAY be
present.
Although a client request may match multiple route rules, only one rule
may ultimately receive the request. Matching precedence MUST be
determined in order of the following criteria:
* The most specific match as defined by the Route type.
* The oldest Route based on creation timestamp. For example, a Route with
a creation timestamp of "2020-09-08 01:02:03" is given precedence over
a Route with a creation timestamp of "2020-09-08 01:02:04".
* If everything else is equivalent, the Route appearing first in
alphabetical order (namespace/name) should be given precedence. For
example, foo/bar is given precedence over foo/baz.
All valid rules within a Route attached to this Listener should be
implemented. Invalid Route rules can be ignored (sometimes that will mean
the full Route). If a Route rule transitions from valid to invalid,
support for that Route rule should be dropped to ensure consistency. For
example, even if a filter specified by a Route rule is invalid, the rest
of the rules within that Route should still be supported.
Support: Core
kinds []object
Kinds specifies the groups and kinds of Routes that are allowed to bind
to this Gateway Listener. When unspecified or empty, the kinds of Routes
selected are determined using the Listener protocol.
A RouteGroupKind MUST correspond to kinds of Routes that are compatible
with the application protocol specified in the Listener's Protocol field.
If an implementation does not support or recognize this resource type, it
MUST set the "ResolvedRefs" condition to False for this Listener with the
"InvalidRouteKinds" reason.
Support: Core
maxItems:
8
group
string
Group is the group of the Route.
pattern:
^$|^[a-z0-9]([-a-z0-9]*[a-z0-9])?(\.[a-z0-9]([-a-z0-9]*[a-z0-9])?)*$maxLength:
253
kind
string required
Kind is the kind of the Route.
pattern:
^[a-zA-Z]([-a-zA-Z0-9]*[a-zA-Z0-9])?$minLength:
1maxLength:
63namespaces object
Namespaces indicates namespaces from which Routes may be attached to this
Listener. This is restricted to the namespace of this Gateway by default.
Support: Core
from
string
From indicates where Routes will be selected for this Gateway. Possible
values are:
* All: Routes in all namespaces may be used by this Gateway.
* Selector: Routes in namespaces selected by the selector may be used by
this Gateway.
* Same: Only Routes in the same namespace may be used by this Gateway.
Support: Core
enum:
All, Selector, Sameselector object
Selector must be specified when From is set to "Selector". In that case,
only Routes in Namespaces matching this Selector will be selected by this
Gateway. This field is ignored for other values of "From".
Support: Core
matchExpressions []object
matchExpressions is a list of label selector requirements. The requirements are ANDed.
key
string required
key is the label key that the selector applies to.
operator
string required
operator represents a key's relationship to a set of values.
Valid operators are In, NotIn, Exists and DoesNotExist.
values
[]string
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
object
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.
hostname
string
Hostname specifies the virtual hostname to match for protocol types that
define this concept. When unspecified, all hostnames are matched. This
field is ignored for protocols that don't require hostname based
matching.
Implementations MUST apply Hostname matching appropriately for each of
the following protocols:
* TLS: The Listener Hostname MUST match the SNI.
* HTTP: The Listener Hostname MUST match the Host header of the request.
* HTTPS: The Listener Hostname SHOULD match both the SNI and Host header.
Note that this does not require the SNI and Host header to be the same.
The semantics of this are described in more detail below.
To ensure security, Section 11.1 of RFC-6066 emphasizes that server
implementations that rely on SNI hostname matching MUST also verify
hostnames within the application protocol.
Section 9.1.2 of RFC-7540 provides a mechanism for servers to reject the
reuse of a connection by responding with the HTTP 421 Misdirected Request
status code. This indicates that the origin server has rejected the
request because it appears to have been misdirected.
To detect misdirected requests, Gateways SHOULD match the authority of
the requests with all the SNI hostname(s) configured across all the
Gateway Listeners on the same port and protocol:
* If another Listener has an exact match or more specific wildcard entry,
the Gateway SHOULD return a 421.
* If the current Listener (selected by SNI matching during ClientHello)
does not match the Host:
* If another Listener does match the Host, the Gateway SHOULD return a
421.
* If no other Listener matches the Host, the Gateway MUST return a
404.
For HTTPRoute and TLSRoute resources, there is an interaction with the
`spec.hostnames` array. When both listener and route specify hostnames,
there MUST be an intersection between the values for a Route to be
accepted. For more information, refer to the Route specific Hostnames
documentation.
Hostnames that are prefixed with a wildcard label (`*.`) are interpreted
as a suffix match. That means that a match for `*.example.com` would match
both `test.example.com`, and `foo.test.example.com`, but not `example.com`.
Support: Core
pattern:
^(\*\.)?[a-z0-9]([-a-z0-9]*[a-z0-9])?(\.[a-z0-9]([-a-z0-9]*[a-z0-9])?)*$minLength:
1maxLength:
253
name
string required
Name is the name of the Listener. This name MUST be unique within a
Gateway.
Support: Core
pattern:
^[a-z0-9]([-a-z0-9]*[a-z0-9])?(\.[a-z0-9]([-a-z0-9]*[a-z0-9])?)*$minLength:
1maxLength:
253
port
integer required
Port is the network port. Multiple listeners may use the
same port, subject to the Listener compatibility rules.
Support: Core
format:
int32minimum:
1maximum:
65535
protocol
string required
Protocol specifies the network protocol this listener expects to receive.
Support: Core
pattern:
^[a-zA-Z0-9]([-a-zA-Z0-9]*[a-zA-Z0-9])?$|[a-z0-9]([-a-z0-9]*[a-z0-9])?(\.[a-z0-9]([-a-z0-9]*[a-z0-9])?)*\/[A-Za-z0-9]+$minLength:
1maxLength:
255tls object
TLS is the TLS configuration for the Listener. This field is required if
the Protocol field is "HTTPS" or "TLS". It is invalid to set this field
if the Protocol field is "HTTP", "TCP", or "UDP".
The association of SNIs to Certificate defined in ListenerTLSConfig is
defined based on the Hostname field for this listener.
The GatewayClass MUST use the longest matching SNI out of all
available certificates for any TLS handshake.
Support: Core
certificateRefs []object
CertificateRefs contains a series of references to Kubernetes objects that
contains TLS certificates and private keys. These certificates are used to
establish a TLS handshake for requests that match the hostname of the
associated listener.
A single CertificateRef to a Kubernetes Secret has "Core" support.
Implementations MAY choose to support attaching multiple certificates to
a Listener, but this behavior is implementation-specific.
References to a resource in different namespace are invalid UNLESS there
is a ReferenceGrant in the target namespace that allows the certificate
to be attached. If a ReferenceGrant does not allow this reference, the
"ResolvedRefs" condition MUST be set to False for this listener with the
"RefNotPermitted" reason.
This field is required to have at least one element when the mode is set
to "Terminate" (default) and is optional otherwise.
CertificateRefs can reference to standard Kubernetes resources, i.e.
Secret, or implementation-specific custom resources.
Support: Core - A single reference to a Kubernetes Secret of type kubernetes.io/tls
Support: Implementation-specific (More than one reference or other resource types)
maxItems:
64
group
string
Group is the group of the referent. For example, "gateway.networking.k8s.io".
When unspecified or empty string, core API group is inferred.
pattern:
^$|^[a-z0-9]([-a-z0-9]*[a-z0-9])?(\.[a-z0-9]([-a-z0-9]*[a-z0-9])?)*$maxLength:
253
kind
string
Kind is kind of the referent. For example "Secret".
pattern:
^[a-zA-Z]([-a-zA-Z0-9]*[a-zA-Z0-9])?$minLength:
1maxLength:
63
name
string required
Name is the name of the referent.
minLength:
1maxLength:
253
namespace
string
Namespace is the namespace of the referenced object. 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
pattern:
^[a-z0-9]([-a-z0-9]*[a-z0-9])?$minLength:
1maxLength:
63
mode
string
Mode defines the TLS behavior for the TLS session initiated by the client.
There are two possible modes:
- Terminate: The TLS session between the downstream client and the
Gateway is terminated at the Gateway. This mode requires certificates
to be specified in some way, such as populating the certificateRefs
field.
- Passthrough: The TLS session is NOT terminated by the Gateway. This
implies that the Gateway can't decipher the TLS stream except for
the ClientHello message of the TLS protocol. The certificateRefs field
is ignored in this mode.
Support: Core
enum:
Terminate, Passthrough
options
object
Options are a list of key/value pairs to enable extended TLS
configuration for each implementation. For example, configuring the
minimum TLS version or supported cipher suites.
A set of common keys MAY be defined by the API in the future. To avoid
any ambiguity, implementation-specific definitions MUST use
domain-prefixed names, such as `example.com/my-custom-option`.
Un-prefixed names are reserved for key names defined by Gateway API.
Support: Implementation-specific
tls object
TLS specifies frontend and backend tls configuration for entire gateway.
Support: Extended
backend object
Backend describes TLS configuration for gateway when connecting
to backends.
Note that this contains only details for the Gateway as a TLS client,
and does _not_ imply behavior about how to choose which backend should
get a TLS connection. That is determined by the presence of a BackendTLSPolicy.
Support: Core
clientCertificateRef object
ClientCertificateRef references an object that contains a client certificate
and its associated private key. It can reference standard Kubernetes resources,
i.e., Secret, or implementation-specific custom resources.
A ClientCertificateRef is considered invalid if:
* It refers to a resource that cannot be resolved (e.g., the referenced resource
does not exist) or is misconfigured (e.g., a Secret does not contain the keys
named `tls.crt` and `tls.key`). In this case, the `ResolvedRefs` condition
on the Gateway MUST be set to False with the Reason `InvalidClientCertificateRef`
and the Message of the Condition MUST indicate why the reference is invalid.
* It refers to a resource in another namespace UNLESS there is a ReferenceGrant
in the target namespace that allows the certificate to be attached.
If a ReferenceGrant does not allow this reference, the `ResolvedRefs` condition
on the Gateway MUST be set to False with the Reason `RefNotPermitted`.
Implementations MAY choose to perform further validation of the certificate
content (e.g., checking expiry or enforcing specific formats). In such cases,
an implementation-specific Reason and Message MUST be set.
Support: Core - Reference to a Kubernetes TLS Secret (with the type `kubernetes.io/tls`).
Support: Implementation-specific - Other resource kinds or Secrets with a
different type (e.g., `Opaque`).
group
string
Group is the group of the referent. For example, "gateway.networking.k8s.io".
When unspecified or empty string, core API group is inferred.
pattern:
^$|^[a-z0-9]([-a-z0-9]*[a-z0-9])?(\.[a-z0-9]([-a-z0-9]*[a-z0-9])?)*$maxLength:
253
kind
string
Kind is kind of the referent. For example "Secret".
pattern:
^[a-zA-Z]([-a-zA-Z0-9]*[a-zA-Z0-9])?$minLength:
1maxLength:
63
name
string required
Name is the name of the referent.
minLength:
1maxLength:
253
namespace
string
Namespace is the namespace of the referenced object. 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
pattern:
^[a-z0-9]([-a-z0-9]*[a-z0-9])?$minLength:
1maxLength:
63frontend object
Frontend describes TLS config when client connects to Gateway.
Support: Core
default object required
Default specifies the default client certificate validation configuration
for all Listeners handling HTTPS traffic, unless a per-port configuration
is defined.
support: Core
validation object
Validation holds configuration information for validating the frontend (client).
Setting this field will result in mutual authentication when connecting to the gateway.
In browsers this may result in a dialog appearing
that requests a user to specify the client certificate.
The maximum depth of a certificate chain accepted in verification is Implementation specific.
Support: Core
caCertificateRefs []object required
CACertificateRefs contains one or more references to Kubernetes
objects that contain a PEM-encoded TLS CA certificate bundle, which
is used as a trust anchor to validate the certificates presented by
the client.
A CACertificateRef is invalid if:
* It refers to a resource that cannot be resolved (e.g., the
referenced resource does not exist) or is misconfigured (e.g., a
ConfigMap does not contain a key named `ca.crt`). In this case, the
Reason on all matching HTTPS listeners must be set to `InvalidCACertificateRef`
and the Message of the Condition must indicate which reference is invalid and why.
* It refers to an unknown or unsupported kind of resource. In this
case, the Reason on all matching HTTPS listeners must be set to
`InvalidCACertificateKind` and the Message of the Condition must explain
which kind of resource is unknown or unsupported.
* It refers to a resource in another namespace UNLESS there is a
ReferenceGrant in the target namespace that allows the CA
certificate to be attached. If a ReferenceGrant does not allow this
reference, the `ResolvedRefs` on all matching HTTPS listeners condition
MUST be set with the Reason `RefNotPermitted`.
Implementations MAY choose to perform further validation of the
certificate content (e.g., checking expiry or enforcing specific formats).
In such cases, an implementation-specific Reason and Message MUST be set.
In all cases, the implementation MUST ensure that the `ResolvedRefs`
condition is set to `status: False` on all targeted listeners (i.e.,
listeners serving HTTPS on a matching port). The condition MUST
include a Reason and Message that indicate the cause of the error. If
ALL CACertificateRefs are invalid, the implementation MUST also ensure
the `Accepted` condition on the listener is set to `status: False`, with
the Reason `NoValidCACertificate`.
Implementations MAY choose to support attaching multiple CA certificates
to a listener, but this behavior is implementation-specific.
Support: Core - A single reference to a Kubernetes ConfigMap, with the
CA certificate in a key named `ca.crt`.
Support: Implementation-specific - More than one reference, other kinds
of resources, or a single reference that includes multiple certificates.
minItems:
1maxItems:
8
group
string required
Group is the group of the referent. For example, "gateway.networking.k8s.io".
When set to the empty string, core API group is inferred.
pattern:
^$|^[a-z0-9]([-a-z0-9]*[a-z0-9])?(\.[a-z0-9]([-a-z0-9]*[a-z0-9])?)*$maxLength:
253
kind
string required
Kind is kind of the referent. For example "ConfigMap" or "Service".
pattern:
^[a-zA-Z]([-a-zA-Z0-9]*[a-zA-Z0-9])?$minLength:
1maxLength:
63
name
string required
Name is the name of the referent.
minLength:
1maxLength:
253
namespace
string
Namespace is the namespace of the referenced object. 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
pattern:
^[a-z0-9]([-a-z0-9]*[a-z0-9])?$minLength:
1maxLength:
63
mode
string
FrontendValidationMode defines the mode for validating the client certificate.
There are two possible modes:
- AllowValidOnly: In this mode, the gateway will accept connections only if
the client presents a valid certificate. This certificate must successfully
pass validation against the CA certificates specified in `CACertificateRefs`.
- AllowInsecureFallback: In this mode, the gateway will accept connections
even if the client certificate is not presented or fails verification.
This approach delegates client authorization to the backend and introduce
a significant security risk. It should be used in testing environments or
on a temporary basis in non-testing environments.
Defaults to AllowValidOnly.
Support: Core
enum:
AllowValidOnly, AllowInsecureFallbackperPort []object
PerPort specifies tls configuration assigned per port.
Per port configuration is optional. Once set this configuration overrides
the default configuration for all Listeners handling HTTPS traffic
that match this port.
Each override port requires a unique TLS configuration.
support: Core
maxItems:
64
port
integer required
The Port indicates the Port Number to which the TLS configuration will be
applied. This configuration will be applied to all Listeners handling HTTPS
traffic that match this port.
Support: Core
format:
int32minimum:
1maximum:
65535tls object required
TLS store the configuration that will be applied to all Listeners handling
HTTPS traffic and matching given port.
Support: Core
validation object
Validation holds configuration information for validating the frontend (client).
Setting this field will result in mutual authentication when connecting to the gateway.
In browsers this may result in a dialog appearing
that requests a user to specify the client certificate.
The maximum depth of a certificate chain accepted in verification is Implementation specific.
Support: Core
caCertificateRefs []object required
CACertificateRefs contains one or more references to Kubernetes
objects that contain a PEM-encoded TLS CA certificate bundle, which
is used as a trust anchor to validate the certificates presented by
the client.
A CACertificateRef is invalid if:
* It refers to a resource that cannot be resolved (e.g., the
referenced resource does not exist) or is misconfigured (e.g., a
ConfigMap does not contain a key named `ca.crt`). In this case, the
Reason on all matching HTTPS listeners must be set to `InvalidCACertificateRef`
and the Message of the Condition must indicate which reference is invalid and why.
* It refers to an unknown or unsupported kind of resource. In this
case, the Reason on all matching HTTPS listeners must be set to
`InvalidCACertificateKind` and the Message of the Condition must explain
which kind of resource is unknown or unsupported.
* It refers to a resource in another namespace UNLESS there is a
ReferenceGrant in the target namespace that allows the CA
certificate to be attached. If a ReferenceGrant does not allow this
reference, the `ResolvedRefs` on all matching HTTPS listeners condition
MUST be set with the Reason `RefNotPermitted`.
Implementations MAY choose to perform further validation of the
certificate content (e.g., checking expiry or enforcing specific formats).
In such cases, an implementation-specific Reason and Message MUST be set.
In all cases, the implementation MUST ensure that the `ResolvedRefs`
condition is set to `status: False` on all targeted listeners (i.e.,
listeners serving HTTPS on a matching port). The condition MUST
include a Reason and Message that indicate the cause of the error. If
ALL CACertificateRefs are invalid, the implementation MUST also ensure
the `Accepted` condition on the listener is set to `status: False`, with
the Reason `NoValidCACertificate`.
Implementations MAY choose to support attaching multiple CA certificates
to a listener, but this behavior is implementation-specific.
Support: Core - A single reference to a Kubernetes ConfigMap, with the
CA certificate in a key named `ca.crt`.
Support: Implementation-specific - More than one reference, other kinds
of resources, or a single reference that includes multiple certificates.
minItems:
1maxItems:
8
group
string required
Group is the group of the referent. For example, "gateway.networking.k8s.io".
When set to the empty string, core API group is inferred.
pattern:
^$|^[a-z0-9]([-a-z0-9]*[a-z0-9])?(\.[a-z0-9]([-a-z0-9]*[a-z0-9])?)*$maxLength:
253
kind
string required
Kind is kind of the referent. For example "ConfigMap" or "Service".
pattern:
^[a-zA-Z]([-a-zA-Z0-9]*[a-zA-Z0-9])?$minLength:
1maxLength:
63
name
string required
Name is the name of the referent.
minLength:
1maxLength:
253
namespace
string
Namespace is the namespace of the referenced object. 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
pattern:
^[a-z0-9]([-a-z0-9]*[a-z0-9])?$minLength:
1maxLength:
63
mode
string
FrontendValidationMode defines the mode for validating the client certificate.
There are two possible modes:
- AllowValidOnly: In this mode, the gateway will accept connections only if
the client presents a valid certificate. This certificate must successfully
pass validation against the CA certificates specified in `CACertificateRefs`.
- AllowInsecureFallback: In this mode, the gateway will accept connections
even if the client certificate is not presented or fails verification.
This approach delegates client authorization to the backend and introduce
a significant security risk. It should be used in testing environments or
on a temporary basis in non-testing environments.
Defaults to AllowValidOnly.
Support: Core
enum:
AllowValidOnly, AllowInsecureFallbackstatus object
Status defines the current state of Gateway.
addresses []object
Addresses lists the network addresses that have been bound to the
Gateway.
This list may differ from the addresses provided in the spec under some
conditions:
* no addresses are specified, all addresses are dynamically assigned
* a combination of specified and dynamic addresses are assigned
* a specified address was unusable (e.g. already in use)
maxItems:
16
type
string
Type of the address.
pattern:
^Hostname|IPAddress|NamedAddress|[a-z0-9]([-a-z0-9]*[a-z0-9])?(\.[a-z0-9]([-a-z0-9]*[a-z0-9])?)*\/[A-Za-z0-9\/\-._~%!$&'()*+,;=:]+$minLength:
1maxLength:
253
value
string required
Value of the address. The validity of the values will depend
on the type and support by the controller.
Examples: `1.2.3.4`, `128::1`, `my-ip-address`.
minLength:
1maxLength:
253
attachedListenerSets
integer
AttachedListenerSets represents the total number of ListenerSets that have been
successfully attached to this Gateway.
A ListenerSet is successfully attached to a Gateway when all the following conditions are met:
- The ListenerSet is selected by the Gateway's AllowedListeners field
- The ListenerSet has a valid ParentRef selecting the Gateway
- The ListenerSet's status has the condition "Accepted: true"
Uses for this field include troubleshooting AttachedListenerSets attachment and
measuring blast radius/impact of changes to a Gateway.
format:
int32conditions []object
Conditions describe the current conditions of the Gateway.
Implementations should prefer to express Gateway conditions
using the `GatewayConditionType` and `GatewayConditionReason`
constants so that operators and tools can converge on a common
vocabulary to describe Gateway state.
Known condition types are:
* "Accepted"
* "Programmed"
* "Ready"
maxItems:
8
lastTransitionTime
string required
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.
format:
date-time
message
string required
message is a human readable message indicating details about the transition.
This may be an empty string.
maxLength:
32768
observedGeneration
integer
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.
format:
int64minimum:
0
reason
string required
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.
pattern:
^[A-Za-z]([A-Za-z0-9_,:]*[A-Za-z0-9_])?$minLength:
1maxLength:
1024
status
string required
status of the condition, one of True, False, Unknown.
enum:
True, False, Unknown
type
string required
type of condition in CamelCase or in foo.example.com/CamelCase.
pattern:
^([a-z0-9]([-a-z0-9]*[a-z0-9])?(\.[a-z0-9]([-a-z0-9]*[a-z0-9])?)*/)?(([A-Za-z0-9][-A-Za-z0-9_.]*)?[A-Za-z0-9])$maxLength:
316listeners []object
Listeners provide status for each unique listener port defined in the Spec.
maxItems:
64
attachedRoutes
integer required
AttachedRoutes represents the total number of Routes that have been
successfully attached to this Listener.
Successful attachment of a Route to a Listener is based solely on the
combination of the AllowedRoutes field on the corresponding Listener
and the Route's ParentRefs field. A Route is successfully attached to
a Listener when it is selected by the Listener's AllowedRoutes field
AND the Route has a valid ParentRef selecting the whole Gateway
resource or a specific Listener as a parent resource (more detail on
attachment semantics can be found in the documentation on the various
Route kinds ParentRefs fields). Listener or Route status does not impact
successful attachment, i.e. the AttachedRoutes field count MUST be set
for Listeners, even if the Accepted condition of an individual Listener is set
to "False". The AttachedRoutes number represents the number of Routes with
the Accepted condition set to "True" that have been attached to this Listener.
Routes with any other value for the Accepted condition MUST NOT be included
in this count.
Uses for this field include troubleshooting Route attachment and
measuring blast radius/impact of changes to a Listener.
format:
int32conditions []object required
Conditions describe the current condition of this listener.
maxItems:
8
lastTransitionTime
string required
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.
format:
date-time
message
string required
message is a human readable message indicating details about the transition.
This may be an empty string.
maxLength:
32768
observedGeneration
integer
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.
format:
int64minimum:
0
reason
string required
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.
pattern:
^[A-Za-z]([A-Za-z0-9_,:]*[A-Za-z0-9_])?$minLength:
1maxLength:
1024
status
string required
status of the condition, one of True, False, Unknown.
enum:
True, False, Unknown
type
string required
type of condition in CamelCase or in foo.example.com/CamelCase.
pattern:
^([a-z0-9]([-a-z0-9]*[a-z0-9])?(\.[a-z0-9]([-a-z0-9]*[a-z0-9])?)*/)?(([A-Za-z0-9][-A-Za-z0-9_.]*)?[A-Za-z0-9])$maxLength:
316
name
string required
Name is the name of the Listener that this status corresponds to.
pattern:
^[a-z0-9]([-a-z0-9]*[a-z0-9])?(\.[a-z0-9]([-a-z0-9]*[a-z0-9])?)*$minLength:
1maxLength:
253supportedKinds []object
SupportedKinds is the list indicating the Kinds supported by this
listener. This MUST represent the kinds supported by an implementation for
that Listener configuration.
If kinds are specified in Spec that are not supported, they MUST NOT
appear in this list and an implementation MUST set the "ResolvedRefs"
condition to "False" with the "InvalidRouteKinds" reason. If both valid
and invalid Route kinds are specified, the implementation MUST
reference the valid Route kinds that have been specified.
maxItems:
8
group
string
Group is the group of the Route.
pattern:
^$|^[a-z0-9]([-a-z0-9]*[a-z0-9])?(\.[a-z0-9]([-a-z0-9]*[a-z0-9])?)*$maxLength:
253
kind
string required
Kind is the kind of the Route.
pattern:
^[a-zA-Z]([-a-zA-Z0-9]*[a-zA-Z0-9])?$minLength:
1maxLength:
63No matches. Try .spec.addresses for an exact path