Repository navigation
fix(kubevirt): route the export proxy to the Service KubeVirt creates - #4637
Conversation
virt-operator names the export proxy Service virt-exportproxy. The Ingress and the TLSRoute publishing vm-exportproxy.<host> named a vm-exportproxy Service instead, which nothing creates, so both routes had no backend. The public hostname stays vm-exportproxy. Assisted-by: LLM Signed-off-by: Aleksei Sviridkin <[email protected]>
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configuration
📒 Files selected for processing (5)
Included review availability: This review used your included allowance. Your plan provides up to 8 included reviews per hour; 7 remain after this review. 📝 WalkthroughWalkthroughThe tenant network policy allows egress to KubeVirt export-proxy pods on TCP port 8443. The export-proxy Ingress and TLSRoute now target the ChangesVM export-proxy connectivity
Priority: ➖ Normal Estimated code review effort: 2 (Simple) | ~10 minutes Change: Bug fix Suggested reviewers: Merge Risk: ⚪ Minimal · up to The export-proxy routing and tenant egress changes have no identified issue requiring resolution before merge. Normal checks remain appropriate. 🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ 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 |
The vm-exportproxy Ingress is served by the ingress controller in tenant-root, and tenant egress is default-deny. Nothing allowed traffic to virt-exportproxy in cozy-kubevirt, so the Ingress stayed unreachable even with the right backend Service. The new policy renders wherever allow-to-cdi-upload-proxy does, but narrows the destination to the export proxy pods and their container port. Assisted-by: LLM Signed-off-by: Aleksei Sviridkin <[email protected]>
5c80233 to
a141665
Compare
IvanHunters
left a comment
There was a problem hiding this comment.
LGTM. Verified against pinned KubeVirt v1.9.0: virt-exportproxy, port 443/targetPort 8443 and the kubevirt.io: virt-exportproxy selector all match what KubeVirt creates, and the VMExport gate is on. helm unittest green (85/85).
Non-blocking: the new allow-to-vm-exportproxy policy uses endpointSelector: {}, so every pod in the tenant gets egress to the proxy rather than just the ingress controller; it is port- and pod-scoped and the proxy is token-authenticated, so consistent with the sibling policies.
What this PR does
The VM export routes point at a Service that does not exist, and the tenant network policy would block the Ingress even if it did.
KubeVirt creates the export proxy Service under the name
virt-exportproxy(VirtExportProxyNameinpkg/virt-operator/resource/generate/components, v1.9.0). The Ingress and the TLSRoute that publishvm-exportproxy.<host>name avm-exportproxyService, and nothing creates one. The backend wasvirt-exportproxywhen the Ingress was added in 0ddaff9. Then 3780925 renamed the hostname tovm-exportproxyand the backend along with it. The hostname stays, only the backend goes back.Renaming the backend is not enough for the Ingress, because it is served by the ingress controller in tenant-root and tenant egress is default-deny. Each allowed destination has its own
allow-to-*policy. The CDI upload proxy hasallow-to-cdi-upload-proxy, the export proxy had nothing. The newallow-to-vm-exportproxypolicy renders for the same tenants and the same source pods as the CDI one. Its destination is narrower: only thekubevirt.io=virt-exportproxypods incozy-kubevirt, on TCP 8443, the container port virt-operator gives them.The unit tests pin the backend name for the Ingress and the TLSRoute, and the placement, selector and port of the new policy.
I checked this on a test cluster with KubeVirt v1.9.0 and ingress-nginx. Without the fix the controller logs
Error obtaining Endpoints for Service "cozy-kubevirt/vm-exportproxy". With the backend renamed and the tenant allowed egress to virt-exportproxy, a passthrough request tovm-exportproxy.<host>reaches the export proxy, and it answers with its own serving certificate.Downstream repositories
Release note
Summary by CodeRabbit
virt-exportproxybackend, keeping export-proxy traffic directed to the correct service.