gep: refine ClientCertificateRef description for backend TLS

[snorwin]

What type of PR is this?

/kind gep

What this PR does / why we need it:
In the current version of the GEP-3155, the semantics of an invalid ClientCertificateRef are not fully specified.
Additionally, the GEP states that an invalid ClientCertificateRef affects the ResolvedRefs condition on the Listeners, which I think is incorrect.

This PR clarifies the behavior by introducing a ResolvedRefs condition on the Gateway instead. That condition will be set whenever a ClientCertificateRef is invalid or not permitted.

Which issue(s) this PR fixes:

N/A

Does this PR introduce a user-facing change?:

NONE

[snorwin]

/cc @robscott @kl52752 @rikatz

[kl52752]

This statement is no longer true. gateway client certificate is part of gateway identity and should be the same for all connections from gateway to backend, this setting cannot be overridden on service level

[snorwin]

I was thinking the same, but I didn’t want to remove it without discussing it first. If everyone agrees, I’ll go ahead and remove it.

[rikatz]

/assign

[rikatz]

overall lgtm.

Will leave final word for approvers :)

[snorwin]

@robscott @youngnick what do you think about adding a ResolvedRefs condition to the Gateway? Would that make sense to you, or should we instead extend the Accepted condition with another reason? In general, how would an invalid client certificate affect acceptance?

I’m interested to hear your thoughts so we can improve the description further.

[snorwin]

@robscott Just a friendly reminder to PTAL.

[youngnick]

Up until this point, we did not have anything in the top-level Gateway that could be an invalid reference, so having this did not make sense.

Now that we do, with tls and tls.frontend, then yes, to me it makes sense to add ResolvedRefs to the top-level Gateway Conditions.

[youngnick]

To actually implement this, we will need to:

• update the godoc with these changes
• Add a new GatewayConditionType constant of ResolvedRefs, with associated Reason as its own GatewayConditionReason, with a description similar to what is talked about in the main godoc.
• Make sure all of this is marked Experimental.

[snorwin]

@youngnick thanks for the review.

• update the godoc with these changes
• Add a new GatewayConditionType constant of ResolvedRefs, with associated Reason as its own GatewayConditionReason, with a description similar to what is talked about in the main godoc.
• Make sure all of this is marked Experimental.

Yes exactly, I will take care of the follow-up changes as soon as we have agreed on the refinement. Let me know if you would prefer to include them in this PR.

[robscott]

Thanks @snorwin! This change LGTM, but would like to see a LGTM from @candita or @kl52752 before we merge this.

/approve

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: robscott, snorwin

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:

• geps/OWNERS [robscott]

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

[robscott]

Yes exactly, I will take care of the follow-up changes as soon as we have agreed on the refinement. Let me know if you would prefer to include them in this PR.

Thanks! I don't have a strong preference on if these are in the same PR or in a follow up. Since these specific changes are confined to the GEP and not API types, I think it's fine to leave this for a follow up.