BackendTLSPolicy conformance tests for ResolvedRefs status condition

[snorwin]

What type of PR is this?

/kind test
/area conformance-test

What this PR does / why we need it:
This test covers the following scenarios:

• Invalid Kind
• Malformed CA certificate ConfigMap
• Missing (nonexistent) CA certificate ConfigMap
• Valid CA certificate (implemented as part of the normative tests)

Which issue(s) this PR fixes:

Fixes #3993

Does this PR introduce a user-facing change?:

NONE

[snorwin]

/cc @candita @kl52752

[kl52752]

Thanks for the PR, LGTM

[kl52752]

/lgtm

[snorwin]

/assign @LiorLieberman

[snorwin]

/assign @shaneutt

[shaneutt]

Thanks for taking the time to do this @snorwin 👍

My initial pass looked good, have we tried to run these tests on an implementation yet?

[snorwin]

@shaneutt it's not possible to verify this with an actual implementation, as the required API changes will be released in v1.4.0. However, I tested it using a patched version of the Airlock Microgateway implementation.

[rikatz]

I was testing against envoy gateway, but due to the lack of resolvedRefs conditions it is not passing as well.

[rikatz]

Is this right? Per the manifest, you are applying a backend that has failure already on backendtlspolicy, resulting on the following condition on HTTPRoute

    - lastTransitionTime: "2025-08-25T20:27:03Z"
      message: |-
        Failed to process route rule 0 backendRef 0: configmap nonexistent-ca-certificate not found in namespace gateway-conformance-infra.
        Failed to process route rule 1 backendRef 0: no ca found in configmap malformed-ca-certificate.
      observedGeneration: 1
      reason: InvalidBackendTLS
      status: "False"
      type: ResolvedRefs

[youngnick]

Pretty sure that is implementation specific behavior, I don't remember defining that in the BackendTLSPolicy GEP at all.

[snorwin]

@rikatz yes, there are many implementation-specific behaviors. That’s why we updated the GEP in #3909, and we’re now enforcing this new behavior through these conformance tests.

[snorwin]

I removed the assertion on the HTTPRoute since it is not specified whether the invalid ResolvedRefs status condition on the BackendTLSPolicy should be propagated to the HTTPRoute or not.

Should I add an assertion that the HTTPRoute is at least accepted, or does an invalid BackendTLSPolicy also influence its acceptance? - Already done.

/cc @kl52752

[kl52752]

thanks for removing that.This question requires new GEP. I think that you can just leave TODO to address this issue later.

[rikatz]

@snorwin a comment on the new cases, the initial test is already failing because at least on envoy gateway, the backendtlspolicy failure to resolve the configmap causes the httproute to have a problem on resolvedrefs.

[kl52752]

Looks good to me, again :)

[rikatz]

/lgtm

Thank you

/assign @candita @shaneutt

[shaneutt]

Thanks @snorwin I think this looks good.

/approve

It shouldn't block us merging this, but as I understand it it's difficult to test this with implementations right now because no implementations actually follow the resolvedRefs correctly....

So what I would like to do @snorwin is have some kind of follow up where we engage with implementations and get more feedback as soon as we can. Would you mind putting an item on the agenda for our community call today to ask for implementations to implement and try the tests? (if you wont be there today though, I can field it just let me know)

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: kl52752, shaneutt, 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:

• conformance/OWNERS [shaneutt]

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