feat(k8s): Support new Gateway api - #875
Conversation
|
Important Review skippedDraft detected. Please check the settings in the CodeRabbit UI or the ⚙️ Run configurationConfiguration used: Path: .coderabbit.yaml Review profile: CHILL Plan: Pro Plus Run ID: You can disable this status message by setting the Use the checkbox below for a quick retry:
✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
Codecov Report❌ Patch coverage is
📢 Thoughts on this report? Let us know! |
|
@contre95 is there any chance we could rebase this to main? I did make some significant changes in the way the Kubernetes service works. |
Yes, I saw the changes, the docs on k8s are great. Unfortunately I was not able to work on this one for a while, been very busy at work. I'll try to rebase and work on it this weekend if possible. |
Reapply the Gateway API support on top of the KubernetesService rework from main, which moved the service to ding-managed watchers and a Lookup based LabelProvider, and started requiring an app to match a host the resource actually routes. Ingresses declare their hosts in spec.rules[].host while HTTPRoutes and GRPCRoutes use spec.hostnames, so host extraction is now dispatched per resource kind. Route hostnames may carry the Gateway API wildcard label, which is matched as a suffix, and routes without hostnames are skipped since the hosts of the gateway listeners they attach to cannot be resolved from the route alone. The cache key gains the resource kind because an Ingress and an HTTPRoute may share a name within a namespace, and the catch-all path warning is extended to HTTPRoute path matches. Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
The app name fallback matches any domain that starts with the app name, so an app named myapp served on myapp.example.com also defined the ACLs of myapp.evil.com. Behind a proxy with a catch-all route, a request can be authorized against the wrong app that way. Label providers now receive the domain being authorized. The Kubernetes provider keeps the hosts of every Ingress, HTTPRoute and GRPCRoute it watches and withholds the apps of the resources that do not route the domain, which bounds the name fallback to the hosts a resource actually serves. Wildcard hostnames keep matching as a suffix, so nested subdomains stay resolvable by app name. Container labels carry no routing information, so the Docker provider cannot narrow its results down and keeps yielding every app. Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
2 participants
I'm adding support to the Kubernetes Service reader to read labels not only from 'Ingress' class but also
GRPCRouteandHTTPRoutefrom the new Gateway API.