BackendTLSPolicy SANs field marked as extended

[mlavacca]

What type of PR is this?

What this PR does / why we need it:

Given the not triviality of supporting this feature for nginx-based implementations (such as Kong) and the fact that this feature is not mandatory to ensure core functionality in the proxy->backend encrypted communication, we can set the SANs field of the BackendTLSPolicy API as an extended feature.

/cc @robscott @shaneutt @youngnick @LiorLieberman @candita

Which issue(s) this PR fixes:

Fixes #

Does this PR introduce a user-facing change?:

The SANs field of `backendTLSPolicy` has been marked as an extended feature.

[howardjohn]

My understanding is this is required to fully validate a certificate. So it seems rather insecure and defeating most benefits of TLS to not validate this, which doesn't seem great.

Am I missing something that makes this not essentially insecureSkipVerify (which, as the name implies, is not secure)?
I get it still validates the CA but that is not relevant - anyone can get a certificate

[howardjohn]

Or is it specifically subject alt names that is the issue and CN (deprecated for like 20 years IIRC) is used?

[mlavacca]

The problem is the list of subjectAlternativeNames for which at least a match is required to validate the certificate. In the Kong proxy, it is possible to provide a single value (which by default for this API is the hostname).

In the proxy, the certificate is properly validated against the SANs field; what's missing is the possibility of setting multiple SANs in the proxy configuration to check the certificate against.

[howardjohn]

Then can we make support for 1 core and support for more than 1 extended? I think we do that with gateway TLS certs

[howardjohn]

I guess using Hostname for that is probably pretty close to that. But might be slightly more flexible to allow 1

[mlavacca]

I guess using Hostname for that is probably pretty close to that. But might be slightly more flexible to allow 1

How would it be more flexible? As you said, I don't see much difference compared to using Hostname for cert validation, except for complicating the interface and the validation.

[howardjohn]

SNI is not always the same as the certificate subject
for example it's quite common for a kube-apiserver to have IP SANs - those cannot be the SNI.

Or many other SANS exist like email, uri, etc

or I may go through a proxy routing on SNI but the TLS is terminated by another host

[mlavacca]

SNI is not always the same as the certificate subject for example it's quite common for a kube-apiserver to have IP SANs - those cannot be the SNI.

Or many other SANS exist like email, uri, etc

or I may go through a proxy routing on SNI but the TLS is terminated by another host

Agreed with all the above, which I honestly think we can consider more advanced use cases. Having just the hostname is not an insecure practice, as it boils down to assuming the certificate SAN to be the same as the SNI. All the valid scenarios you proposed are completely legit, but do they need to be treated as core and mandatory for an implementation?

[howardjohn]

Yep I didn't make the full connection with Hostname in my initial comments. I think there's still an argument to be made on what exactly is core or not, but as long as "secure is core" then that works for me

[shaneutt]

/approve

/cc @robscott @youngnick for lgtm

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: mlavacca, shaneutt

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

• OWNERS [mlavacca,shaneutt]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[youngnick]

/lgtm

[mlavacca]

/unhold