mirror of
https://github.com/cozystack/cozystack.git
synced 2026-10-29 16:17:20 +09:00
## 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` (`VirtExportProxyName` in `pkg/virt-operator/resource/generate/components`, v1.9.0). The Ingress and the TLSRoute that publish `vm-exportproxy.<host>` name a `vm-exportproxy` Service, and nothing creates one. The backend was `virt-exportproxy` when the Ingress was added in0ddaff938. Then3780925a6renamed the hostname to `vm-exportproxy` and 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 has `allow-to-cdi-upload-proxy`, the export proxy had nothing. The new `allow-to-vm-exportproxy` policy renders for the same tenants and the same source pods as the CDI one. Its destination is narrower: only the `kubevirt.io=virt-exportproxy` pods in `cozy-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 to `vm-exportproxy.<host>` reaches the export proxy, and it answers with its own serving certificate. ### Downstream repositories - [x] No downstream repository is affected by this change - [ ] [cozystack/website](https://github.com/cozystack/website) - follow-up: - [ ] [cozystack/terraform-provider-cozystack](https://github.com/cozystack/terraform-provider-cozystack) - follow-up: - [ ] [cozystack/ansible-cozystack](https://github.com/cozystack/ansible-cozystack) - follow-up: - [ ] [cozystack/ccp](https://github.com/cozystack/ccp) - follow-up: - [ ] [cozystack/talm](https://github.com/cozystack/talm) - follow-up: - [ ] [cozystack/cozyhr](https://github.com/cozystack/cozyhr) - follow-up: - [ ] [cozystack/cozy-proxy](https://github.com/cozystack/cozy-proxy) - follow-up: - [ ] [cozystack/cozystack-telemetry-server](https://github.com/cozystack/cozystack-telemetry-server) - follow-up: - [ ] [cozystack/external-apps-example](https://github.com/cozystack/external-apps-example) - follow-up: - [ ] [cozystack/examples](https://github.com/cozystack/examples) - follow-up: - [ ] [cozystack/community](https://github.com/cozystack/community) - follow-up: ### Release note ```release-note fix(kubevirt): requests to vm-exportproxy.<host> now reach the KubeVirt export proxy: the Ingress and TLSRoute route to the virt-exportproxy Service KubeVirt creates, and tenants are allowed egress to the export proxy. ``` <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit * **New Features** * Tenant workloads can now connect to the KubeVirt export proxy over TCP port 8443. * **Bug Fixes** * Updated export-proxy Ingress and TLSRoute routing to use the `virt-exportproxy` backend, keeping export-proxy traffic directed to the correct service. <!-- end of auto-generated comment: release notes by coderabbit.ai -->