Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

TLS Config Should be Optional #2713

Closed
robscott opened this issue Jan 11, 2024 · 0 comments · Fixed by #2721
Closed

TLS Config Should be Optional #2713

robscott opened this issue Jan 11, 2024 · 0 comments · Fixed by #2721
Labels
kind/bug Categorizes issue or PR as related to a bug.

Comments

@robscott
Copy link
Member

What happened:
Our CEL validation currently requires that TLS config is specified on a Listener when the protocol is HTTPS or TLS:

// +kubebuilder:validation:XValidation:message="tls must be specified for protocols ['HTTPS', 'TLS']",rule="self.all(l, l.protocol in ['HTTPS', 'TLS'] ? has(l.tls) : true)"

What you expected to happen:
Similar to #2668, I believe this validation is unnecessarily strict and should be reverted.

Anything else we need to know?:
As I've been thinking about more TLS user stories for Gateway API, particularly self service and generated certs (#763 (comment)), I've realized that the strictness of our validation here has made it unnecessarily complex to handle some very real use cases. I think it is critical for our API to be flexible enough here to enable different personas to configure TLS.

When I pulled TLS Certs out of Routes, I still had every intention of enabling app owners to configure TLS Certs (thus #763 was created). Unfortunately I think we lost track of that goal when writing this specific validation.

Note the this is closely tied to #2668 and if we get consensus around this approach as well, I'll work on a change that incorporates reverting both validations + adding documentation and guidance for how implementations should handle the absence of these fields.

@robscott robscott added the kind/bug Categorizes issue or PR as related to a bug. label Jan 11, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
kind/bug Categorizes issue or PR as related to a bug.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

1 participant