AlinsRan commented on code in PR #2804:
URL:
https://github.com/apache/apisix-ingress-controller/pull/2804#discussion_r3643412062
##########
internal/controller/utils.go:
##########
@@ -836,51 +916,53 @@ func getListenerStatus(
supportedKinds = []gatewayv1.RouteGroupKind{}
)
+ // A port serving more than one TLS mode cannot be programmed,
so the
+ // listener is rejected rather than accepted with undefined
behaviour.
+ if listener.Protocol == gatewayv1.TLSProtocolType &&
tlsModeConflictPorts[listener.Port] {
+ conditionAccepted.Status = metav1.ConditionFalse
+ conditionAccepted.Reason =
string(gatewayv1.ListenerReasonProtocolConflict)
+ conditionAccepted.Message = "listeners on this port
disagree on tls.mode"
+ conditionConflicted.Status = metav1.ConditionTrue
+ conditionConflicted.Reason =
string(gatewayv1.ListenerReasonProtocolConflict)
+ conditionProgrammed.Status = metav1.ConditionFalse
+ conditionProgrammed.Reason =
string(gatewayv1.ListenerReasonInvalid)
+
+ statusArray = append(statusArray,
reuseUnchangedListenerStatus(gateway, i, gatewayv1.ListenerStatus{
+ Name: listener.Name,
+ Conditions: []metav1.Condition{
+ conditionProgrammed,
+ conditionAccepted,
+ conditionConflicted,
+ conditionResolvedRefs,
+ },
+ SupportedKinds: supportedKinds,
+ AttachedRoutes: attachedRoutes,
+ }))
+ continue
Review Comment:
Fixed. TLS-passthrough and conflicting-tls-mode listeners are now treated as
non-programmable at all three attachment points, via `listenerNotProgrammable`:
`ParseRouteParentRefs` no longer matches them (the parentRef gets
`NotAllowedByListeners`), `getAttachedRoutesForListener` returns 0, and
`getListenerStatus` reports `Accepted=False`. So a route can no longer be
programmed through a listener that reports `Accepted=False`, and
`AttachedRoutes` is 0. (97b3875f)
##########
internal/adc/translator/gateway.go:
##########
@@ -134,26 +146,43 @@ func (t *Translator) translateSecret(tctx
*provider.TranslateContext, listener g
}
}
- // Only supported on TLSRoute. The certificateRefs field is ignored in
this mode.
- case gatewayv1.TLSModePassthrough:
- return sslObjs, nil
default:
- return nil, fmt.Errorf("unknown TLS mode %s",
*listener.TLS.Mode)
+ return nil, fmt.Errorf("unknown TLS mode %s", mode)
}
return sslObjs, nil
}
-// translateFrontendValidation builds the downstream mTLS client configuration
from a
-// listener's frontendValidation. The referenced CA certificates (ConfigMap,
key `ca.crt`)
-// are bundled into a single trust anchor used to validate client certificates.
+// frontendTLSValidation resolves the Gateway-level frontend TLS client-cert
+// validation that applies to the given HTTPS listener. In Gateway API v1.6,
+// frontendValidation moved from the per-listener TLS config to the
Gateway-level
+// spec.tls.frontend: Default applies to all HTTPS listeners, and a PerPort
entry
+// overrides it for listeners on the matching port.
+func frontendTLSValidation(obj *gatewayv1.Gateway, listener
gatewayv1.Listener) *gatewayv1.FrontendTLSValidation {
Review Comment:
Fixed. Resolution is consolidated into
`internaltypes.FrontendTLSValidationForListener`, which returns nil unless
`listener.Protocol == HTTPSProtocolType`. Both `translateSecret` and the status
validation call the same helper, so a TLS/Terminate listener never picks up
frontendValidation. (51870e7c)
##########
internal/adc/translator/gateway.go:
##########
@@ -134,26 +146,43 @@ func (t *Translator) translateSecret(tctx
*provider.TranslateContext, listener g
}
}
- // Only supported on TLSRoute. The certificateRefs field is ignored in
this mode.
- case gatewayv1.TLSModePassthrough:
- return sslObjs, nil
default:
- return nil, fmt.Errorf("unknown TLS mode %s",
*listener.TLS.Mode)
+ return nil, fmt.Errorf("unknown TLS mode %s", mode)
}
return sslObjs, nil
}
-// translateFrontendValidation builds the downstream mTLS client configuration
from a
-// listener's frontendValidation. The referenced CA certificates (ConfigMap,
key `ca.crt`)
-// are bundled into a single trust anchor used to validate client certificates.
+// frontendTLSValidation resolves the Gateway-level frontend TLS client-cert
+// validation that applies to the given HTTPS listener. In Gateway API v1.6,
+// frontendValidation moved from the per-listener TLS config to the
Gateway-level
+// spec.tls.frontend: Default applies to all HTTPS listeners, and a PerPort
entry
+// overrides it for listeners on the matching port.
+func frontendTLSValidation(obj *gatewayv1.Gateway, listener
gatewayv1.Listener) *gatewayv1.FrontendTLSValidation {
+ if obj.Spec.TLS == nil || obj.Spec.TLS.Frontend == nil {
+ return nil
+ }
+ frontend := obj.Spec.TLS.Frontend
+ for i := range frontend.PerPort {
+ if frontend.PerPort[i].Port == listener.Port {
+ return frontend.PerPort[i].TLS.Validation
+ }
+ }
+ return frontend.Default.Validation
+}
+
+// translateFrontendValidation builds the downstream mTLS client configuration
from the
+// Gateway's frontendValidation that applies to the listener. The referenced CA
+// certificates (ConfigMap, key `ca.crt`) are bundled into a single trust
anchor used
+// to validate client certificates.
func (t *Translator) translateFrontendValidation(tctx
*provider.TranslateContext, listener gatewayv1.Listener, obj
*gatewayv1.Gateway) (*adctypes.ClientClass, error) {
- if listener.TLS.FrontendValidation == nil ||
len(listener.TLS.FrontendValidation.CACertificateRefs) == 0 {
+ validation := frontendTLSValidation(obj, listener)
Review Comment:
Fixed by rejecting the unsupported mode instead of silently programming
strict mTLS. AllowInsecureFallback is an Extended feature that APISIX cannot
express (per-SSL verification is all-or-nothing — there is no way to request a
client cert without enforcing it). `translateFrontendValidation` now returns a
sentinel so `translateSecret` emits no SSL for that listener, and the listener
is reported `Accepted=False/UnsupportedValue` + `Programmed=False`. It is
contained to the single listener — other listeners on the Gateway are
unaffected (covered by `TestTranslateGateway_InsecureFallbackIsContained`).
(ced6eea1)
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
