Summary
Please triage whether the controller should support configuring upstream mTLS when using Gateway API resources.
Current behavior
The controller already exposes an upstream client-certificate path through the APISIX CRD surface, for example ApisixUpstream.spec.tlsSecret.
However, I did not find an equivalent Gateway API-oriented surface in the current controller model for expressing upstream client-auth when APISIX connects to backend services.
The Gateway API docs currently mark BackendTLSPolicy as not supported, and BackendTrafficPolicy does not appear to expose client certificate material for this use case.
As a result, upstream mTLS setups supported through APISIX CRDs cannot currently be expressed through the Gateway API path in the controller.
Use cases affected
- connecting from APISIX to HTTPS backends that require client certificate authentication
- managing upstream TLS verification and upstream client-auth through the same Gateway API-oriented configuration flow
Code context
docs/en/latest/concepts/gateway-api.md
api/v1alpha1/backendtrafficpolicy_types.go
api/v2/apisixupstream_types.go
Summary
Please triage whether the controller should support configuring upstream mTLS when using Gateway API resources.
Current behavior
The controller already exposes an upstream client-certificate path through the APISIX CRD surface, for example
ApisixUpstream.spec.tlsSecret.However, I did not find an equivalent Gateway API-oriented surface in the current controller model for expressing upstream client-auth when APISIX connects to backend services.
The Gateway API docs currently mark
BackendTLSPolicyas not supported, andBackendTrafficPolicydoes not appear to expose client certificate material for this use case.As a result, upstream mTLS setups supported through APISIX CRDs cannot currently be expressed through the Gateway API path in the controller.
Use cases affected
Code context
docs/en/latest/concepts/gateway-api.mdapi/v1alpha1/backendtrafficpolicy_types.goapi/v2/apisixupstream_types.go