- Shipped
- September 23, 2026 at 1:11 PM UTC
- Author
- Kamo
- Commit
- 907927a
Nothing had ever been provisioned, so every grant past the namespace was untested. Each of these refused at exactly the point the previous fix unblocked. `patch` on namespaces and on datavolumes. A server-side apply IS a PATCH, and both objects are created by one. Every other resource in this file that gets applied already carried `patch`; these two did not, which is what makes them an oversight rather than a decision. After the second one the whole list was checked against the templates in one pass — namespaces, resourcequotas, ciliumnetworkpolicies, datavolumes, virtualmachines, services, secrets, persistentvolumeclaims — instead of waiting for the next refusal to name the next gap. Permission to clone the golden image, which is not a verb on the object being created at all. CDI authorises a cross-namespace clone in the SOURCE namespace through a webhook: admission webhook **************** denied the request: User **************** has insufficient permissions in clone source namespace hosted-computers What it wants is `create` on the `datavolumes/source` subresource there. That subresource is not readable or writable and has no other purpose; it exists so this permission can be expressed. It is a namespaced Role, not another ClusterRole rule, and that is the point rather than tidiness. Cluster-wide it would authorise cloning from ANY namespace — and this service already holds `create datavolumes` everywhere, so the pair would be a route to copying any PVC on the platform into a tenant's machine. The only legitimate clone source is the golden image, and the golden image lives in one namespace. Verified: a computer provisions end to end — namespace, quota, isolation policy, DataVolume cloning from hc-golden-noble-20260911, VirtualMachine, and the RDP/agent Service.