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

Improve TLS conditions on route reconciliation #15237

Open
ReToCode opened this issue May 23, 2024 · 0 comments
Open

Improve TLS conditions on route reconciliation #15237

ReToCode opened this issue May 23, 2024 · 0 comments
Labels
area/networking triage/accepted Issues which should be fixed (post-triage)
Milestone

Comments

@ReToCode
Copy link
Member

Currently the TLS conditions are a bit tricky. We re-use the same condition to reflect the status of external-domain-tls and cluster-local-domain-tls. The first one also needs considering if an external route actually exists. The proposal now is to:

Maybe it would be a good idea to introduce another condition to separate cluster-local from external-domain certificates? It's a bit hard to follow that the condition is influenced by two feature flags and if there is actually a route (e.g. external-domain-tls enabled but no external routes and cluster-local-domain-tls disabled). We could even have better messages like

  • external-domain-tls: feature is disabled
  • external-domain-tls: no certificate required, no external domains found

Original discussion see: #15234 (comment)

@ReToCode ReToCode added this to the v1.15.0 milestone May 23, 2024
@ReToCode ReToCode added area/networking triage/accepted Issues which should be fixed (post-triage) labels May 23, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area/networking triage/accepted Issues which should be fixed (post-triage)
Projects
None yet
Development

No branches or pull requests

1 participant