Summary
Please triage whether the controller should support configuring downstream mTLS when using Gateway API resources.
Current behavior
The controller already exposes downstream client certificate validation through the APISIX CRD surface, for example ApisixTls.spec.client.
However, I did not find an equivalent Gateway API-oriented surface in the current controller model for expressing downstream mTLS on incoming traffic.
As a result, downstream mTLS setups supported through APISIX CRDs cannot currently be expressed through the Gateway API path in the controller.
Use cases affected
- requiring client certificates for traffic entering APISIX while using Gateway API resources for listener and route management
- expressing downstream client-auth through the Gateway API path instead of falling back to a separate APISIX CRD configuration path
Code context
docs/en/latest/concepts/gateway-api.md
api/v2/apisixtls_types.go
internal/adc/translator/apisixtls.go
Summary
Please triage whether the controller should support configuring downstream mTLS when using Gateway API resources.
Current behavior
The controller already exposes downstream client certificate validation through the APISIX CRD surface, for example
ApisixTls.spec.client.However, I did not find an equivalent Gateway API-oriented surface in the current controller model for expressing downstream mTLS on incoming traffic.
As a result, downstream 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/v2/apisixtls_types.gointernal/adc/translator/apisixtls.go