Support BackendTLSPolicy SubjectAltNames

[sjberman]

trafficstars

As an NGF user, I want to specify Subject Alternative (SAN) names for my backends, So that I can allow multiple alternative names to be present in the backend certificate.

Note: this may not actually be possible with nginx to support a list of SANs. See https://github.com/kubernetes-sigs/gateway-api/pull/3591 which is changing this field to extended for this reason.

We still may want to investigate.

Acceptance

• Support the SubjectAltNames field in the BackendTLSPolicy

[github-actions[bot]]

This issue is stale because it has been open 14 days with no activity. Remove stale label or comment or this will be closed in 14 days.

[bjee19]

After some investigation, we have decided that supporting BackendTLSPolicy SubjectAltNames is currently not worth investing in.

In the Gateway API, BackendTLSPolicy SubjectAltNames is an extended feature, however the three fields inside of it, type, hostname, uri, are all core. There was also a comment by a Gateway API maintainer saying something along the lines of:

My interpretation of this is that supporting SubjectAltNames is extended/optional, but if you claim support for the feature, you have to support all fields marked Core within that field. If others agree with that interpretation, we should make a corresponding update to our docs to make the pattern more clear.

@ciarams87 brought up a great point offline about the current limitations of proxy_ssl_name with regards to it only accepting a single value:

NGINX only supports a single hostname in the proxy_ssl_name directive, which in our BackendTLSPolicy implementation is set to the value of hostname, as per the spec: Hostname MUST be used for authentication and MUST match the certificate served by the matching backend, unless SubjectAltNames is specified. The hostname field already allows defining this proxy_ssl_name to something else, so if we supported SubjectAltNames, we could only a. support a single entry and b. this entry would replace the value defined in hostname, we could not support it in addition to hostname

In addition, the proxy_ssl_name directive will not work with URIs, and as stated above, the uri field in BackendTLSPolicy SubjectAltNames is core. Although proxy_ssl_name will accept a URI, how it functions behind the scenes is by passing that value through TLS SNI. TLS SNI as defined in RFC 6066 states:

"HostName" contains the fully qualified DNS hostname of the server...

Meaning we would not be able to support the URI field.

If we want to revisit this issue, we would need to request the Gateway API to make URI extended, and probably talk with the NGINX OSS group to find a way to make the proxy_ssl_name directive accept a list of values.

[bjee19]

However, if any community members see this story and would like BackendTLSPolicy SubjectAltNames to be supported, we welcome any inputs and use cases and we will likely revisit this issue if enough desire is there.

[sjberman]

I'll note that if the URI field is marked as Core and this API is promoted to standard, I doubt that they would revert it back to Extended. Possible, but feels unlikely to me.