Conformance tests for BackendTLSPolicy

[candita]

What would you like to be added:
Conformance tests for BackendTLSPolicy. Comment below if you're interested in working on covering any of these areas.

Core Capabilities:

• Valid BackendTLSPolicy with 1 targetRef/service using CACertificateRef and matching hostname
• Invalid: hostname doesn't match the hostname in the certificate served by the backend
• Invalid BackendTLSPolicy performs no default forwarding
• Valid BackendTLSPolicy with 1 targetRef/service using WellKnownCACertificates and matching hostname
• Invalid: targetRef in different namespace
• Invalid: both CACertificateRef and WellKnownCACertificates is specified
• Invalid: SNI hostname invalid - not RFC1123 (should be caught by validation)
• Invalid: Namespace (of targetRef) not set

Why this is needed:
This is needed in order for BackendTLSPolicy to graduate from v1alpha3 to v1.

[candita]

cc @whitneygriffith @mlavacca

[whitneygriffith]

#1897

[mlavacca]

Invalid: both CACertificateRef and WellKnownCACertificates is specified

I think this test cannot be implemented, as this rule is directly enforced by CEL:

gateway-api/apis/v1alpha3/backendtlspolicy_types.go

Line 81 in d49ae96

// +kubebuilder:validation:XValidation:message="must not contain both CACertificateRefs and WellKnownCACertificates",rule="!(has(self.caCertificateRefs) && size(self.caCertificateRefs) > 0 && has(self.wellKnownCACertificates) && self.wellKnownCACertificates != \"\")"

[mlavacca]

Valid BackendTLSPolicy with 1 targetRef/service using WellKnownCACertificates and matching hostname

WellKnownCACertificates is an implementation-specific feature, therefore I think we should either:

• leave it out of conformance tests, or
• accept that the implementation set the Accepted condition to false, as stated in

  gateway-api/apis/v1alpha3/backendtlspolicy_types.go

  Lines 115 to 118 in d49ae96

  	// CACertificateRefs or WellKnownCACertificates may be specified, not both. If an
  	// implementation does not support the WellKnownCACertificates field or the value
  	// supplied is not supported, the Status Conditions on the Policy MUST be
  	// updated to include an Accepted: False Condition with Reason: Invalid.

If we go the second way, though, in my opinion, this is beyond the bare minimum set of conformance tests needed for graduation.

[mlavacca]

Invalid: targetRef in different namespace

The TargetRef is a LocalPolicyTargetReference, there is no namespace field in it. I think that a TargetRef in a different namespace is impossible, given the current API state.

gateway-api/apis/v1alpha2/policy_types.go

Lines 39 to 48 in 86c06a0

	type LocalPolicyTargetReference struct {
	// Group is the group of the target resource.
	Group Group `json:"group"`
	// Kind is kind of the target resource.
	Kind Kind `json:"kind"`
	// Name is the name of the target resource.
	Name ObjectName `json:"name"`
	}

[keithmattix]

/assign @candita @whitneygriffith

[whitneygriffith]

Invalid: targetRef in different namespace
The TargetRef is a LocalPolicyTargetReference, there is no namespace field in it. I think that a TargetRef in a different namespace is impossible, given the current API state.

I agree, we don't need a conformance test for this case. The same applies for Invalid: Namespace (of targetRef) not set.

[whitneygriffith]

Updated test cases:

• Valid BackendTLSPolicy with 1 targetRef/service using CACertificateRef and matching hostname
• Invalid: hostname doesn't match the hostname in the certificate served by the backend
• Invalid: if an implementation doesn't claim support for BackendTLSPolicy, it rejects forwarding to Services with a BackendTLSPolicy attached.

Removed test cases:

• Valid BackendTLSPolicy with 1 targetRef/service using WellKnownCACertificates and matching hostname (WellKnownCACertificates is an implementation-specific feature and is beyond the minimum set of tests needed for graduation)
• Invalid: targetRef in different namespace (targetRef is of type LocalPolicyTargetReference which does not have a namespace field)
• Invalid: both CACertificateRef and WellKnownCACertificates is specified (enforced by CEL)
• Invalid: SNI hostname invalid - not RFC1123 (should be caught by validation)
• Invalid BackendTLSPolicy performs no default forwarding as all the required fields are set (enforced by validation)
• Invalid: Namespace (of targetRef) not set (targetRef is of type LocalPolicyTargetReference which does not have a namespace field)

[k8s-triage-robot]

The Kubernetes project currently lacks enough contributors to adequately respond to all issues.

This bot triages un-triaged issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue as fresh with /remove-lifecycle stale
• Close this issue with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale