Gateway

gateway.networking.k8s.io/v1

Gateway API Versionv1.6.0

Gateway represents an instance of a service-traffic handling infrastructure by binding Listeners to a set of IP addresses.
A Gateway name SHOULD be compliant with RFC 1035, consisting of a maximum of 63 lower case alphanumeric characters or hyphens (’-’), and MUST start and end with an alphanumeric character.

​
---
config:
  theme: base
  themeVariables:
    secondaryColor: '#ffffff'
---
block
  columns 7

  classDef al_ref_box fill:#F2F2F2,stroke:#555;
  classDef al_mgw_box fill:#70991F,stroke:#555;
  classDef al_gwapi_box fill:#326CE5,stroke:#555;
  classDef al_std_box fill:#808B8F,stroke:#555;
  classDef al_self_box fill:#326CE5,stroke:#777,stroke-width:5px; 

  
  
  block:RefBy:1
    columns 1
    ReferenceGrant["<a href='../../../gateway-api/reference-grant/v1'>&nbsp;&nbsp;ReferenceGrant&nbsp;&nbsp;</a>"]
    space:1
    class ReferenceGrant al_gwapi_box
  end
  class RefBy al_ref_box
  space:2
  
  
  Gateway["<a href='../../../gateway-api/gateway/v1'>&nbsp;&nbsp;<b>Gateway</b>&nbsp;&nbsp;</a>"]
  class Gateway al_self_box
  
  
  space:2
  block:Ref:1
    columns 1
    GatewayClass["<a href='../../../gateway-api/gateway-class/v1'>&nbsp;&nbsp;GatewayClass&nbsp;&nbsp;</a>"]
    GatewayParameters["<a href='../../../microgateway/gateway-parameters/v1alpha1'>&nbsp;&nbsp;GatewayParameters&nbsp;&nbsp;</a>"]
    class GatewayParameters al_mgw_box
    class GatewayClass al_gwapi_box
  end
  class Ref al_ref_box
  
  
  space:7
  
  space:2
  block:TargetedBy:3
    columns 3
    HTTPRoute["<a href='../../../gateway-api/http-route/v1'>&nbsp;&nbsp;HTTPRoute&nbsp;&nbsp;</a>"]
    ListenerSet["<a href='../../../gateway-api/listener-set/v1'>&nbsp;&nbsp;ListenerSet&nbsp;&nbsp;</a>"]
    space:1
    class HTTPRoute,ListenerSet al_gwapi_box
  end
  class TargetedBy al_ref_box
  space:2
  

  RefBy -- "<br><i>references</i>" --> Gateway
  Gateway -- "<br><i>references</i>" --> Ref
  TargetedBy -- "<i>attaches to</i>" --> Gateway
apiVersion: gateway.networking.k8s.io/v1
kind: Gateway
metadata:
  name: gateway-example
spec:
  gatewayClassName: airlock-microgateway
  allowedListeners:
    namespaces:
      from: Same
  listeners:
    - name: http
      port: 80
      protocol: HTTP
      hostname: example.com
      allowedRoutes:
        namespaces:
          from: All
    - name: https
      port: 443
      protocol: HTTPS
      hostname: example.com
      tls:
        mode: Terminate
        certificateRefs:
          - name: cert-secret
      allowedRoutes:
        namespaces:
          from: All
    - name: mtls
      port: 8443
      protocol: HTTPS
      hostname: example.com
      tls:
        mode: Terminate
        certificateRefs:
          - name: cert-secret
      allowedRoutes:
        namespaces:
          from: Selector
          selector:
            matchLabels:
              gateway-example-mtls-routes-allowed: "true"
  tls:
    frontend:
      default: {}
      perPort:
        - port: 8443
          tls:
            validation:
              mode: AllowValidOnly
              caCertificateRefs:
                - group: ""
                  kind: "ConfigMap"
                  name: ca
    backend:
      clientCertificateRef:
        group: ""
        kind: Secret
        name: client-cert-secret
  infrastructure:
    labels:
      some-label: some-value
    annotations:
      some-annotation: some-value
    parametersRef:
      group: microgateway.airlock.com
      kind: GatewayParameters
      name: example-parameters

Gateway

Field Description Type Required Default Allowed Values
metadata defines the resource’s metadata ObjectMeta yes
spec defines the desired state of Gateway. object yes
status defines the current state of Gateway. object no

Gateway.spec

Field Description Type Required Default Allowed Values
addresses Not supported object[] no
allowedListeners defines which ListenerSets can be attached to this Gateway.
The default value is to allow no ListenerSets.		 object no
defaultScope Not supported enum no All, None
gatewayClassName used for this Gateway. This is the name of a GatewayClass resource. string yes
infrastructure defines infrastructure level attributes about this Gateway instance. object no
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).

If traffic to a Gateway does not match any Listener’s hostname (or if the Listener does not specify a hostname and the request does not match any attached Route), the request MUST be rejected. The specific mechanism for rejection depends on the protocol: HTTP returns a 404 status code, while gRPC returns an Unimplemented status code.

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.		 object[] yes
tls specifies frontend and backend tls configuration for entire gateway. object no

Gateway.spec.addresses[]

Field Description Type Required Default Allowed Values
type of the address. string no IPAddress
value 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.		 string no

Gateway.spec.allowedListeners

Field Description Type Required Default Allowed Values
namespaces defines which namespaces ListenerSets can be attached to this Gateway.
The default value is to allow no ListenerSets.		 object no

Gateway.spec.allowedListeners.namespaces

Field Description Type Required Default Allowed Values
from indicates where ListenerSets can attach to this Gateway. Possible values are:
The default value None		 string no None All, None, Same, Selector
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”. LabelSelector no

Gateway.spec.infrastructure

Field Description Type Required Default Allowed Values
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.		 map[string]string no
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.		 map[string]string no
parametersRef

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.

Supported kinds: GatewayParameters

object no

Gateway.spec.infrastructure.parametersRef

Field Description Type Required Default Allowed Values
group

Group is the group of the referent.

Supported groups: microgateway.airlock.com

string yes
kind

Kind is kind of the referent.

Supported kinds: GatewayParameters

string yes
name is the name of the referent. string yes

Gateway.spec.listeners[]

Field Description Type Required Default Allowed Values
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.		 object no
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.		 string no
name is the name of the Listener. This name MUST be unique within a Gateway. string yes
port is the network port. Multiple listeners may use the same port, subject to the Listener compatibility rules. int32 yes [1, 65535]
protocol

Protocol specifies the network protocol this listener expects to receive.

Supported protocols:

  • HTTP: Accepts cleartext HTTP/1.1 or HTTP/2 (H2C with prior knowledge) sessions over TCP.
  • HTTPS: Accepts HTTP/1.1 or HTTP/2 sessions over TLS.
  • microgateway.airlock.com/http3: Accepts HTTP/3 sessions over QUIC and UDP as well as HTTP/1.1 or HTTP/2 sessions over TLS.

string yes
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.		 object no

Gateway.spec.listeners[].allowedRoutes

Field Description Type Required Default Allowed Values
kinds

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.

Supported kinds: HTTPRoute

object[] no
namespaces indicates namespaces from which Routes may be attached to this Listener. This is restricted to the namespace of this Gateway by default. object no

Gateway.spec.listeners[].allowedRoutes.kinds[]

Field Description Type Required Default Allowed Values
group

Group is the group of the Route.

Supported groups: gateway.networking.k8s.io

string no gateway.networking.k8s.io
kind

Kind is the kind of the Route.

Supported kinds: HTTPRoute

string yes

Gateway.spec.listeners[].allowedRoutes.namespaces

Field Description Type Required Default Allowed Values
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.
string no Same All, Same, Selector
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”. LabelSelector no

Gateway.spec.listeners[].tls

Field Description Type Required Default Allowed Values
certificateRefs

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)

Supported kinds: Secret

object[] no
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.
enum no Terminate Passthrough, Terminate
options

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.

Supported options:

  • microgateway.airlock.com/alpn-protocols: defines the application protocols advertised during TLS handshakes.
    The value must be a comma-separated, ordered list of ALPN protocol name preferences, with the most preferred protocol first (e.g., “h2,http/1.1”).
    Possible values are: “h2”, “http/1.1”.
    If not set, the list “h2,http/1.1” is used as a default.
    Note: If exactly one ALPN protocol is configured, all requests using a different protocol are rejected and only requests matching that protocol are accepted.
    Note: If the protocol type is set to microgateway.airlock.com/http3, this option applies only to the TLS listener and not to the QUIC listener.
  • microgateway.airlock.com/ciphers: defines the allowed cipher suites for TLS 1.0–1.2 (this setting has no effect when using TLS 1.3).
    The value must be a comma-separated list of cipher suites (e.g., “ECDHE-ECDSA-AES128-GCM-SHA256,ECDHE-RSA-AES128-GCM-SHA256”).
    If not set, the Envoy default cipher list is used.
  • microgateway.airlock.com/ecdhCurves: defines the elliptic curves allowed for ECDH key exchange.
    The value must be a comma-separated list of curve names ordered by preference (e.g., “X25519,P-256,P-384”).
    If not set, the list “X25519MLKEM768,X25519,P-256” is used as a default.
  • microgateway.airlock.com/maximumVersion: defines the maximum supported TLS protocol version.
    Possible values are: TLSv1_0, TLSv1_1, TLSv1_2, TLSv1_3.
    The maximum version must be greater than or equal to the minimum version.
  • microgateway.airlock.com/minimumVersion: defines the minimum supported TLS protocol version.
    Possible values are: TLSv1_0, TLSv1_1, TLSv1_2, TLSv1_3.
    The minimum version must be less than or equal to the maximum version.
  • microgateway.airlock.com/signatureAlgorithms: defines the allowed signature algorithms for TLS handshakes.
    The value must be a comma-separated list of algorithm names (e.g., “ecdsa_secp256r1_sha256,rsa_pss_rsae_sha256”).
    If not set, the Envoy default list of signature algorithms is used.

map[string]string no

Gateway.spec.listeners[].tls.certificateRefs[]

Field Description Type Required Default Allowed Values
group

Group is the group of the referent. For example, “gateway.networking.k8s.io”.
When unspecified or empty string, core API group is inferred.

Supported groups: ""

string no ""
kind

Kind is kind of the referent. For example “Secret”.

Supported kinds: Secret

string no Secret
name is the name of the referent. string yes
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.		 string no

Gateway.spec.tls

Field Description Type Required Default Allowed Values
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.		 object no
frontend describes TLS config when client connects to Gateway. object no

Gateway.spec.tls.backend

Field Description Type Required Default Allowed Values
clientCertificateRef

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).

Supported kinds: Secret

object no

Gateway.spec.tls.backend.clientCertificateRef

Field Description Type Required Default Allowed Values
group

Group is the group of the referent. For example, “gateway.networking.k8s.io”.
When unspecified or empty string, core API group is inferred.

Supported groups: ""

string no ""
kind

Kind is kind of the referent. For example “Secret”.

Supported kinds: Secret

string no Secret
name is the name of the referent. string yes
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.		 string no

Gateway.spec.tls.frontend

Field Description Type Required Default Allowed Values
default specifies the default client certificate validation configuration for all Listeners handling HTTPS traffic, unless a per-port configuration is defined. object yes
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.		 object[] no

Gateway.spec.tls.frontend.default

Field Description Type Required Default Allowed Values
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.		 object no

Gateway.spec.tls.frontend.default.validation

Field Description Type Required Default Allowed Values
caCertificateRefs

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.

Supported kinds: ConfigMap, Secret

object[] yes
mode 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.		 enum no AllowValidOnly AllowInsecureFallback, AllowValidOnly

Gateway.spec.tls.frontend.default.validation.caCertificateRefs[]

Field Description Type Required Default Allowed Values
group

Group is the group of the referent. For example, “gateway.networking.k8s.io”.
When set to the empty string, core API group is inferred.

Supported groups: ""

string yes
kind

Kind is kind of the referent. For example “ConfigMap” or “Service”.

Supported kinds: ConfigMap, Secret

string yes
name is the name of the referent. string yes
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.		 string no

Gateway.spec.tls.frontend.perPort[]

Field Description Type Required Default Allowed Values
port 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. int32 yes [1, 65535]
tls store the configuration that will be applied to all Listeners handling HTTPS traffic and matching given port. object yes

Gateway.spec.tls.frontend.perPort[].tls

Field Description Type Required Default Allowed Values
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.		 object no

Gateway.spec.tls.frontend.perPort[].tls.validation

Field Description Type Required Default Allowed Values
caCertificateRefs

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.

Supported kinds: ConfigMap, Secret

object[] yes
mode 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.		 enum no AllowValidOnly AllowInsecureFallback, AllowValidOnly

Gateway.spec.tls.frontend.perPort[].tls.validation.caCertificateRefs[]

Field Description Type Required Default Allowed Values
group

Group is the group of the referent. For example, “gateway.networking.k8s.io”.
When set to the empty string, core API group is inferred.

Supported groups: ""

string yes
kind

Kind is kind of the referent. For example “ConfigMap” or “Service”.

Supported kinds: ConfigMap, Secret

string yes
name is the name of the referent. string yes
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.		 string no

Gateway.status

Field Description Type
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)
object[]
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: Uses for this field include troubleshooting AttachedListenerSets attachment and measuring blast radius/impact of changes to a Gateway.		 int32
conditions

describe the current status of the Gateway.

Possible conditions:

  • Accepted: This condition is true when the controller managing the Gateway is syntactically and semantically valid enough to produce some configuration in the underlying data plane. This does not indicate whether or not the configuration has been propagated to the data plane.

    Possible reasons for this condition to be True are:
    • “Accepted”
    • “ListenersNotValid”
    Possible reasons for this condition to be False are:
    • “Invalid”
    • “InvalidParameters”
    • “NotReconciled”
    • “UnsupportedAddress”
    • “ListenersNotValid”
    Possible reasons for this condition to be Unknown are:
    • “Pending”
    Controllers may raise this condition with other reasons, but should prefer to use the reasons listed above to improve interoperability.
  • AttachedRoutes: indicates whether a Gateway has valid routes attached.

    Possible reasons for this condition to be True are:
    • “AttachedRoutesValid” (Route has policies attached and all are valid)
    Possible reasons for this condition to be False are:
    • “InvalidRoutes” (some of the attached routes are invalid)
    • “NoRoutes” (no routes are attached)
  • InsecureBackendValidationMode: is true if insecure TLS certificate verification has been enabled at some point on this Gateway.

    Possible reasons for this condition to be True are:
    • “ConfigurationChanged”
  • InsecureFrontendValidationMode: This condition is true when the Gateway FrontendValidationModeType is configured to allow insecure fallback behavior.

    Possible reasons for this condition to be True are:
    • “ConfigurationChanged”
    This condition is removed as soon as FrontendValidationModeType is changed back to AllowValidOnly.
  • Licensed: summarizes the Airlock Microgateway License status of the Operator instance managing this Gateway.
    If the Licensed condition is False, the Gateway’s Accepted condition will also be False with the reason “Invalid”.

    Possible reasons for this condition to be True are:
    • “ValidLicense”
    Possible reasons for this condition to be False are:
    • “InvalidOrMissingLicense”
    • “ExpiredLicense”
  • Programmed: This condition indicates whether a Gateway has generated some configuration that is assumed to be ready soon in the underlying data plane.

    It is a positive-polarity summary condition, and so should always be present on the resource with ObservedGeneration set.

    It should be set to Unknown if the controller performs updates to the status before it has all the information it needs to be able to determine if the condition is true.

    Possible reasons for this condition to be True are:
    • “Programmed”
    Possible reasons for this condition to be False are:
    • “Invalid”
    • “Pending”
    • “NoResources”
    • “AddressNotAssigned”
    Possible reasons for this condition to be Unknown are:
    • “Pending”
    Controllers may raise this condition with other reasons, but should prefer to use the reasons listed above to improve interoperability.
  • ResolvedRefs: This condition indicates whether the controller was able to resolve all the object references for the Gateway that are not part of a specific Listener configuration, and also provides a positive-polarity summary of Listener’s “ResolvedRefs” condition. This condition does not directly impact the Gateway’s Accepted or Programmed conditions.

    Possible reasons for this condition to be True are:
    • “ResolvedRefs”
    Possible reasons for this condition to be False are:
    • “RefNotPermitted”
    • “InvalidClientCertificateRef”
    • “ListenersNotResolved”
    Controllers may raise this condition with other reasons, but should prefer to use the reasons listed above to improve interoperability.

    Note: This condition is considered Experimental and may change in future releases of the API.

Condition[]
listeners provide status for each unique listener port defined in the Spec. object[]

Gateway.status.addresses[]

Field Description Type
type of the address. string
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.		 string

Gateway.status.listeners[]

Field Description Type
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.		 int32
conditions

Conditions describe the current condition of this listener.

Possible conditions:

  • Accepted: This condition indicates that the listener is syntactically and semantically valid, and that all features used in the listener’s spec are supported.

    In general, a Listener will be marked as Accepted when the supplied configuration will generate at least some data plane configuration.

    For example, a Listener with an unsupported protocol will never generate any data plane config, and so will have Accepted set to false. Conversely, a Listener that does not have any Routes will be able to generate data plane config, and so will have Accepted set to true.

    Possible reasons for this condition to be True are:
    • “Accepted”
    Possible reasons for this condition to be False are:
    • “PortUnavailable”
    • “UnsupportedProtocol”
    • “NoValidCACertificate”
    • “UnsupportedValue”
    Possible reasons for this condition to be Unknown are:
    • “Pending”
    Controllers may raise this condition with other reasons, but should prefer to use the reasons listed above to improve interoperability.
  • Conflicted: This condition indicates that the controller was unable to resolve conflicting specification requirements for this Listener. If a Listener is conflicted, its network port should not be configured on any network elements.

    Possible reasons for this condition to be true are:
    • “HostnameConflict”
    • “ProtocolConflict”
    Possible reasons for this condition to be False are:
    • “NoConflicts”
    Controllers may raise this condition with other reasons, but should prefer to use the reasons listed above to improve interoperability.
    If this condition is not set, it is assumed that there are no conflicts.
  • OverlappingTLSConfig: This condition indicates that TLS configuration within this Listener conflicts with TLS configuration in another Listener on the same port.
    This could happen for two reasons:

    1) Overlapping Hostnames: Listener A matches *.example.com while Listener B matches foo.example.com.
    B) Overlapping Certificates: Listener A contains a certificate with a SAN for *.example.com, while Listener B contains a certificate with a SAN for foo.example.com.

    This overlapping TLS configuration can be particularly problematic when combined with HTTP connection coalescing. When clients reuse connections using this technique, it can have confusing interactions with Gateway API, such as TLS configuration for one Listener getting used for a request reusing an existing connection that would not be used if the same request was initiating a new connection.

    Controllers MUST detect the presence of overlapping hostnames and MAY detect the presence of overlapping certificates.

    This condition MUST be set on all Listeners with overlapping TLS config.
    For example, consider the following listener - hostname mapping:

    A: foo.example.com B: foo.example.org C: *.example.com

    In the above example, Listeners A and C would have overlapping hostnames and therefore this condition should be set for Listeners A and C, but not B.

    Possible reasons for this condition to be True are:
    • “OverlappingHostnames”
    • “OverlappingCertificates”
    If a controller supports checking for both possible reasons and finds that both are true, it SHOULD set the “OverlappingCertificates” Reason.

    This is a negative polarity condition and MUST NOT be set when it is False.

    Controllers may raise this condition with other reasons, but should prefer to use the reasons listed above to improve interoperability.
  • Programmed: This condition indicates whether a Listener has generated some configuration that will soon be ready in the underlying data plane.

    It is a positive-polarity summary condition, and so should always be present on the resource with ObservedGeneration set.

    It should be set to Unknown if the controller performs updates to the status before it has all the information it needs to be able to determine if the condition is true.

    Possible reasons for this condition to be True are:
    • “Programmed”
    Possible reasons for this condition to be False are:
    • “Invalid”
    • “Pending”
    Possible reasons for this condition to be Unknown are:
    • “Pending”
    Controllers may raise this condition with other reasons, but should prefer to use the reasons listed above to improve interoperability.
  • ResolvedRefs: This condition indicates whether the controller was able to resolve all the object references for the Listener.

    Possible reasons for this condition to be true are:
    • “ResolvedRefs”
    Possible reasons for this condition to be False are:
    • “InvalidCertificateRef”
    • “InvalidRouteKinds”
    • “RefNotPermitted”
    • “InvalidCACertificateRef”
    • “InvalidCACertificateKind”
    Controllers may raise this condition with other reasons, but should prefer to use the reasons listed above to improve interoperability.

Condition[]
name is the name of the Listener that this status corresponds to. string
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.		 object[]

Gateway.status.listeners[].supportedKinds[]

Field Description Type
group is the group of the Route. string
kind is the kind of the Route. string