BackendTLSPolicy

gateway.networking.k8s.io/v1

Gateway API Versionv1.6.0

BackendTLSPolicy provides a way to configure how a Gateway connects to a Backend via TLS.

​
---
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; 

  
  space:2
  block:Targets:3
    columns 3
    Service["<a href='https://kubernetes.io/docs/concepts/services-networking/service/'>&nbsp;&nbsp;Service&nbsp;&nbsp;</a>"]
    space:2
    class Service al_std_box
  end
  class Targets al_ref_box
  space:2
  
  space:7
  
  space:3
  
  BackendTLSPolicy["<a href='../../../gateway-api/backend-tls-policy/v1'>&nbsp;&nbsp;<b>BackendTLSPolicy</b>&nbsp;&nbsp;</a>"]
  class BackendTLSPolicy al_self_box
  
  space:3
  

  BackendTLSPolicy -- "<i>attaches to</i>" --> Targets
apiVersion: gateway.networking.k8s.io/v1
kind: BackendTLSPolicy
metadata:
  name: backend-tls-policy-example
spec:
  targetRefs:
    - kind: Service
      group: ""
      name: example-service
      sectionName: https
  validation:
    hostname: example
    caCertificateRefs:
      - group: ""
        kind: ConfigMap
        name: example-ca

BackendTLSPolicy

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

BackendTLSPolicy.spec

Field Description Type Required Default Allowed Values
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/allowExpiredCertificate: allows connections with expired certificates.
    Possible values are: “true” (default: “false”).
  • 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/insecure: disables ALL certificate validations, allowing insecure connections without proper trust verification.
    Possible values are: “true” (default: “false”).
  • 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.
  • microgateway.airlock.com/verifyCertificateHashes: specifies a list of allowed certificate fingerprints for TLS connections as a multi-line string.
    Each line represents one fingerprint, blank lines and lines beginning with ‘#’ are ignored. Fingerprints must be hex-encoded SHA-256 hashes, written as either:
    • 64 hexadecimal characters (e.g., df6ff72fe9116521268f6f2dd4966f51df479883fe7037b39f75916ac3049d1a), or
    • 32 colon-separated byte pairs (e.g., DF:6F:F7:2F:E9:11:65:21:26:8F:6F:2D:D4:96:6F:51:DF:47:98:83:FE:70:37:B3:9F:75:91:6A:C3:04:9D:1A).
    Note: This TLS option pins connections to specific server certificates instead of any other validation method.
    Therefore, it cannot be combined with SAN or CA certificate-based validation, and other TLS validation options.

map[string]string no
targetRefs

TargetRefs identifies an API object to apply the policy to.
Note that this config applies to the entire referenced resource by default, but this default may change in the future to provide a more granular application of the policy.

TargetRefs must be distinct. This means either that:

  • They select different targets. If this is the case, then targetRef entries are distinct. In terms of fields, this means that the multi-part key defined by group, kind, and name must be unique across all targetRef entries in the BackendTLSPolicy.
  • They select different sectionNames in the same target.
When more than one BackendTLSPolicy selects the same target and sectionName, implementations MUST determine precedence using the following criteria, continuing on ties:
  • The older policy by creation timestamp takes precedence. For example, a policy with a creation timestamp of “2021-07-15 01:02:03” MUST be given precedence over a policy with a creation timestamp of “2021-07-15 01:02:04”.
  • The policy appearing first in alphabetical order by {namespace}/{name}.
    For example, a policy named foo/bar is given precedence over a policy named foo/baz.
For any BackendTLSPolicy that does not take precedence, the implementation MUST ensure the Accepted Condition is set to status: False, with Reason Conflicted.

Implementations SHOULD NOT support more than one targetRef at this time. Although the API technically allows for this, the current guidance for conflict resolution and status handling is lacking. Until that can be clarified in a future release, the safest approach is to support a single targetRef.

Support Levels:
  • Extended: Kubernetes Service referenced by backendRefs used on a Route.
    • HTTPRoute, GRPCRoute, TLSRoute with termination
    • Filters that needs a backend of type Service, like Mirror and External Authorization
  • Implementation-Specific: Implementations MAY use BackendTLSPolicy for:
    • Services not referenced by any Route (e.g., infrastructure services)
    • Service mesh workload-to-service communication
    • Other resource types beyond Service
Implementations SHOULD aim to ensure that BackendTLSPolicy behavior is consistent, even outside of the extended HTTPRoute -(backendRef) -> Service path.
They SHOULD clearly document how BackendTLSPolicy is interpreted in these scenarios, including:
  • Which resources beyond Service are supported
  • How the policy is discovered and applied
  • Any implementation-specific semantics or restrictions
Note that this config applies to the entire referenced resource by default, but this default may change in the future to provide a more granular application of the policy.

Supported kinds: Service

object[] yes
validation contains backend TLS validation configuration. object yes

BackendTLSPolicy.spec.targetRefs[]

Field Description Type Required Default Allowed Values
group

Group is the group of the target resource.

Supported groups: ""

string yes
kind

Kind is kind of the target resource.

Supported kinds: Service

string yes
name is the name of the target resource. string yes
sectionName is the name of a section within the target resource. When unspecified, this targetRef targets the entire resource. In the following resources, SectionName is interpreted as the following:
If a SectionName is specified, but does not exist on the targeted object, the Policy must fail to attach, and the policy implementation should record a ResolvedRefs or similar Condition in the Policy’s status.		 string no

BackendTLSPolicy.spec.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 to validate a TLS handshake between the Gateway and backend Pod.

If CACertificateRefs is empty or unspecified, then WellKnownCACertificates must be specified. Only one of CACertificateRefs or WellKnownCACertificates may be specified, not both. If CACertificateRefs is empty or unspecified, the configuration for WellKnownCACertificates MUST be honored instead if supported by the implementation.

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 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 must be set to InvalidKind and the Message of the Condition must explain which kind of resource is unknown or unsupported.
  • It refers to a resource in another namespace. This may change in future spec updates.
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 for the invalid reference.

In all cases, the implementation MUST ensure the ResolvedRefs Condition on the BackendTLSPolicy is set to status: False, with a Reason and Message that indicate the cause of the error. Connections using an invalid CACertificateRef MUST fail, and the client MUST receive an HTTP 5xx error response. If ALL CACertificateRefs are invalid, the implementation MUST also ensure the Accepted Condition on the BackendTLSPolicy is set to status: False, with a Reason NoValidCACertificate.

A single CACertificateRef to a Kubernetes ConfigMap kind has “Core” support.
Implementations MAY choose to support attaching multiple certificates to a backend, but this behavior is implementation-specific.

Support: Core - An optional 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[] no
hostname is used for two purposes in the connection between Gateways and backends:
  1. Hostname MUST be used as the SNI to connect to the backend (RFC 6066).
  2. Hostname MUST be used for authentication and MUST match the certificate served by the matching backend, unless SubjectAltNames is specified.
  3. If SubjectAltNames are specified, Hostname can be used for certificate selection but MUST NOT be used for authentication. If you want to use the value of the Hostname field for authentication, you MUST add it to the SubjectAltNames list.
string yes
subjectAltNames contains one or more Subject Alternative Names.
When specified the certificate served from the backend MUST have at least one Subject Alternate Name matching one of the specified SubjectAltNames.		 object[] no
wellKnownCACertificates

WellKnownCACertificates specifies whether a well-known set of CA certificates may be used in the TLS handshake between the gateway and backend pod.

If WellKnownCACertificates is unspecified or empty (""), then CACertificateRefs must be specified with at least one entry for a valid configuration. Only one of CACertificateRefs or WellKnownCACertificates may be specified, not both.
If an implementation does not support the WellKnownCACertificates field, or the supplied value is not recognized, the implementation MUST ensure the Accepted Condition on the BackendTLSPolicy is set to status: False, with a Reason Invalid.

Valid values include:

  • “System” - indicates that well-known system CA certificates should be used.
Implementations MAY define their own sets of CA certificates. Such definitions MUST use an implementation-specific, prefixed name, such as mycompany.com/my-custom-ca-certificates.

Supported values:

  • System: indicates that well known system CA certificates should be used.
  • microgateway.airlock.com/openShiftServiceCA: indicates that well known service ca certificates from OpenShift should be used. Only applicable on OpenShift clusters.

string no

BackendTLSPolicy.spec.validation.caCertificateRefs[]

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 yes
kind

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

Supported kinds: ConfigMap, Secret

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

BackendTLSPolicy.spec.validation.subjectAltNames[]

Field Description Type Required Default Allowed Values
hostname contains Subject Alternative Name specified in DNS name format.
Required when Type is set to Hostname, ignored otherwise.		 string no
type determines the format of the Subject Alternative Name. Always required. enum yes Hostname, URI
uri contains Subject Alternative Name specified in a full URI format.
It MUST include both a scheme (e.g., “http” or “ftp”) and a scheme-specific-part.
Common values include SPIFFE IDs like “spiffe://mycluster.example.com/ns/myns/sa/svc1sa”.
Required when Type is set to URI, ignored otherwise.		 string no

BackendTLSPolicy.status

Field Description Type
ancestors is a list of ancestor resources (usually Gateways) that are associated with the policy, and the status of the policy with respect to each ancestor. When this policy attaches to a parent, the controller that manages the parent and the ancestors MUST add an entry to this list when the controller first sees the policy and SHOULD update the entry as appropriate when the relevant ancestor is modified.

Note that choosing the relevant ancestor is left to the Policy designers; an important part of Policy design is designing the right object level at which to namespace this status.

Note also that implementations MUST ONLY populate ancestor status for the Ancestor resources they are responsible for. Implementations MUST use the ControllerName field to uniquely identify the entries in this list that they are responsible for.

Note that to achieve this, the list of PolicyAncestorStatus structs MUST be treated as a map with a composite key, made up of the AncestorRef and ControllerName fields combined.

A maximum of 16 ancestors will be represented in this list. An empty list means the Policy is not relevant for any ancestors.

If this slice is full, implementations MUST NOT add further entries.
Instead they MUST consider the policy unimplementable and signal that on any related resources such as the ancestor that would be referenced here. For example, if this list was full on BackendTLSPolicy, no additional Gateways would be able to reference the Service targeted by the BackendTLSPolicy.		 object[]

BackendTLSPolicy.status.ancestors[]

Field Description Type
ancestorRef corresponds with a ParentRef in the spec that this PolicyAncestorStatus struct describes the status of. object
conditions

Conditions describes the status of the Policy with respect to the given Ancestor.

Possible conditions:

  • Accepted: indicates whether the policy has been accepted or rejected by a targeted resource, and why.

    Possible reasons for this condition to be True are:
    • “Accepted”
    Possible reasons for this condition to be False are:
    • “Conflicted”
    • “Invalid”
    • “TargetNotFound”
  • ResolvedRefs: This condition indicates whether the controller was able to resolve all object references for the BackendTLSPolicy.

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

Condition[]
controllerName is a domain/path string that indicates the name of the controller that wrote this status. This corresponds with the controllerName field on GatewayClass.

Example: “example.net/gateway-controller”.

The format of this field is DOMAIN “/” PATH, where DOMAIN and PATH are valid Kubernetes names (https://kubernetes.io/docs/concepts/overview/working-with-objects/names/#names).

Controllers MUST populate this field when writing status. Controllers should ensure that entries to status populated with their ControllerName are cleaned up when they are no longer necessary.		 string

BackendTLSPolicy.status.ancestors[].ancestorRef

Field Description Type
group is the group of the referent.
When unspecified, “gateway.networking.k8s.io” is inferred.
To set the core API group (such as for a “Service” kind referent), Group must be explicitly set to "" (empty string).		 string
kind is kind of the referent.

There are two kinds of parent resources with “Core” support:
  • Gateway (Gateway conformance profile)
  • Service (Mesh conformance profile, ClusterIP Services only)
Support for other resources is Implementation-Specific.		 string
name is the name of the referent. string
namespace is the namespace of the referent. When unspecified, this refers to the local namespace of the Route.

Note that there are specific rules for ParentRefs which cross namespace boundaries. Cross-namespace references are only valid if they are explicitly allowed by something in the namespace they are referring to. For example:
Gateway has the AllowedRoutes field, and ReferenceGrant provides a generic way to enable any other kind of cross-namespace reference.
Note: This section only applies to the Gateway API experimental channel

ParentRefs from a Route to a Service in the same namespace are “producer” routes, which apply default routing rules to inbound connections from any namespace to the Service.

ParentRefs from a Route to a Service in a different namespace are “consumer” routes, and these routing rules are only applied to outbound connections originating from the same namespace as the Route, for which the intended destination of the connections are a Service targeted as a ParentRef of the Route.
string
port is the network port this Route targets. It can be interpreted differently based on the type of parent resource.

When the parent resource is a Gateway, this targets all listeners listening on the specified port that also support this kind of Route(and select this Route). It’s not recommended to set Port unless the networking behaviors specified in a Route must apply to a specific port as opposed to a listener(s) whose port(s) may be changed. When both Port and SectionName are specified, the name and port of the selected listener must match both specified values.
Note: This section only applies to the Gateway API experimental channel

When the parent resource is a Service, this targets a specific port in the Service spec. When both Port (experimental) and SectionName are specified, the name and port of the selected port must match both specified values.
Implementations MAY choose to support other parent resources.
Implementations supporting other types of parent resources MUST clearly document how/if Port is interpreted.

For the purpose of status, an attachment is considered successful as long as the parent resource accepts it partially. For example, Gateway listeners can restrict which Routes can attach to them by Route kind, namespace, or hostname. If 1 of 2 Gateway listeners accept attachment from the referencing Route, the Route MUST be considered successfully attached. If no Gateway listeners accept attachment from this Route, the Route MUST be considered detached from the Gateway.		 int32
sectionName is the name of a section within the target resource. In the following resources, SectionName is interpreted as the following:
  • Gateway: Listener name. When both Port (experimental) and SectionName are specified, the name and port of the selected listener must match both specified values.
  • Service: Port name. When both Port (experimental) and SectionName are specified, the name and port of the selected listener must match both specified values.
Implementations MAY choose to support attaching Routes to other resources.
If that is the case, they MUST clearly document how SectionName is interpreted.

When unspecified (empty string), this will reference the entire resource.
For the purpose of status, an attachment is considered successful if at least one section in the parent resource accepts it. For example, Gateway listeners can restrict which Routes can attach to them by Route kind, namespace, or hostname. If 1 of 2 Gateway listeners accept attachment from the referencing Route, the Route MUST be considered successfully attached. If no Gateway listeners accept attachment from this Route, the Route MUST be considered detached from the Gateway.		 string