Skip to content
Open
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
88 changes: 74 additions & 14 deletions apis/v1/gateway_types.go
Original file line number Diff line number Diff line change
Expand Up @@ -526,20 +526,30 @@ const (

// GatewayBackendTLS describes backend TLS configuration for gateway.
type GatewayBackendTLS struct {
// ClientCertificateRef is a reference to an object that contains a Client
// Certificate and the associated private key.
//
// 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.
//
// ClientCertificateRef can reference to standard Kubernetes resources, i.e.
// Secret, or implementation-specific custom resources.
//
// Support: Core
//
// 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`
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm worried that Cx might confused this error with other TLS based features like ClientCertValidation, can we be more specifica about the certificate?
InvalidClientCertificateRef -> InvalidGatewayClientCertificateRef

Copy link
Member Author

@snorwin snorwin Nov 14, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Wouldn't InvalidBackendClientCertificateRef be more accurate?

However, it is quite long, and since a Gateway only has one clientCertificateRef field, it should be clear which one is meant.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

InvalidBackendClientCertificateRef is not accurate because this is Gateway's certificate to communicate with Backends.

// 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`).
// +optional
// <gateway:experimental>
ClientCertificateRef *SecretObjectReference `json:"clientCertificateRef,omitempty"`
Expand Down Expand Up @@ -1237,6 +1247,56 @@ const (
GatewayReasonNotReconciled GatewayConditionReason = "NotReconciled"
)

const (
// 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
// the Listener's "ResolvedRefs" condition.
//
// 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.
GatewayConditionResolvedRefs GatewayConditionType = "ResolvedRefs"

// This reason is used with the "ResolvedRefs" condition when the condition
// is true.
GatewayReasonResolvedRefs GatewayConditionReason = "ResolvedRefs"

// This reason is used with the "ResolvedRefs" condition when the Gateway
// has an invalid ClientCertificateRef in its backend TLS configuration.
// A ClientCertificateRef is considered invalid when it refers to a
// nonexistent or unsupported resource or kind, or when the data within
// that resource is malformed.
// This reason must be used only when the reference is allowed, either by
// referencing an object in the same namespace as the Gateway, or when
// a cross-namespace reference has been explicitly allowed by a ReferenceGrant.
// If the reference is not allowed, the reason RefNotPermitted must be used
// instead.
GatewayReasonInvalidClientCertificateRef GatewayConditionReason = "InvalidClientCertificateRef"

// This reason is used with the "ResolvedRefs" condition when the Gateway
// has a top-level backend TLS configuration that references an object in
// another namespace, where the object in the other namespace does not have
// a ReferenceGrant explicitly allowing the reference.
GatewayReasonRefNotPermitted GatewayConditionReason = "RefNotPermitted"

// This reason is used with the "ResolvedRefs" condition when one or more
// Listeners have their "ResolvedRefs" condition set to false in their status.
GatewayReasonListenersNotResolved GatewayConditionReason = "ListenersNotResolved"
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think it will be useful to specify what should be overall Gateway Status when References are not resolved. If if is already defined please point me to the docs.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What are you referring to as the overall Gateway status, the Accepted status condition?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

yes

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think it might be tricky since the setting is on Gateway but its usage depends on BackendTLSPolicy so maybe it should not impact Accepted condition but it is worth to define that.

Copy link
Member Author

@snorwin snorwin Nov 14, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good point, I had implicitly assumed that the ResolvedRefs condition wouldn’t affect acceptance (this was the main reason for introducing a new condition). I’ll make this explicit and add a short description.

)

const (
// "Ready" is a condition type reserved for future use. It should not be used by implementations.
//
Expand Down
74 changes: 48 additions & 26 deletions config/crd/experimental/gateway.networking.k8s.io_gateways.yaml

Some generated files are not rendered by default. Learn more about how customized files appear on GitHub.

2 changes: 1 addition & 1 deletion pkg/generated/openapi/zz_generated.openapi.go

Some generated files are not rendered by default. Learn more about how customized files appear on GitHub.