feat(networking): cozyplane eBPF CNI + cozyplane-kpr networking variant (drops Cilium) - #3149

Timofei Larkin (@lllamnyp) NOT LGTM. The pinned arm64 images carry x86-64 binaries, CI is red on the new packages, and the variant switch is accepted on bundle variants where it breaks networking. Reviewed at 312ec1b.

Business context: an opt-in networkingVariant: cozyplane for the Talos system bundle that replaces kube-ovn, Cilium and kube-proxy with the cozyplane eBPF CNI, its aggregated API server and a socket-LB kube-proxy replacement.

The default path is safe. I rendered the platform chart on current main and on main with this diff applied, for all four system variants with default values. The only difference is two new PackageSources (cozystack.cozyplane-apiserver, cozystack.cozyplane-cilium-crds) and the new cozyplane entry in cozystack.networking. No Package changes, so existing clusters are untouched.

Blockers

B1: the arm64 image entries contain amd64 binaries

The platform is going multi-arch, so the arm64 entry has to actually run on arm64. Both indexes list linux/arm64, but only the Debian base layer is arm64. Every binary copied on top is x86-64.

ghcr.io/lllamnyp/cozyplane@sha256:a50c456b… arm64 entry sha256:bb142456…
  usr/local/bin/cozyplane-agent       ELF 64-bit LSB executable, x86-64
  usr/local/bin/cozyplane-apiserver   ELF 64-bit LSB executable, x86-64
  usr/local/bin/sdn-controller        ELF 64-bit LSB executable, x86-64
  usr/local/bin/cozyplane-responder   ELF 64-bit LSB executable, x86-64
  opt/cni/bin/cozyplane, host-local, loopback   x86-64
  usr/sbin/xtables-nft-multi          ARM aarch64   (debian base, correct)
ghcr.io/lllamnyp/cozyplane-kpr@sha256:7417b9ad… arm64 entry sha256:cfe471d8…
  usr/bin/cozyplane-kpr               ELF 64-bit LSB executable, x86-64
registry.k8s.io/etcd:3.5.16-0 arm64 entry: etcd, etcdctl   ARM aarch64 (fine)

The agent binary in the arm64 entry has the same sha256 as the one in the amd64 entry (da363880…), and layers 3 to 10 of the two manifests are byte-identical. The cause is in both upstream Dockerfiles at 7454b02 (the commit main-7454b02 resolves to this digest; kpr's digest is main-60525cd): ARG TARGETARCH=amd64. With a default value, BuildKit does not fill in the platform ARG for that stage (docker/buildx#510), so GOARCH=${TARGETARCH} and the cni-plugins-linux-${TARGETARCH} download are amd64 for both legs. On an arm64 node the agent, controller, apiserver and kpr fail with exec format error. install-cni also copies x86-64 plugins into the host /opt/cni/bin, so the kubelet can't set up any pod network there. Commit 077f04f says "the kpr image is CI-built now, amd64+arm64", and cozyplane-kpr/values.yaml says the same. Both statements are false for these digests.

Fix: in both Dockerfiles, change ARG TARGETARCH=amd64 to a bare ARG TARGETARCH in every stage that reads it, rebuild, and repin. A cheap guard in the upstream release job is file on one binary per leg.

The BPF side is fine. overlay_bpfel.o has only tc programs, and bpf_sock.o has only cgroup/connect*, sendmsg*, recvmsg* and sock_release. Neither has kprobes, fentry or PT_REGS access, so one little-endian object is correct for both architectures. No chart value, nodeSelector or affinity pins kubernetes.io/arch. Both DaemonSets tolerate everything.

B2: CI is red because of the new packages

Unit & controller tests (run 36410226587, attempt 1, 2026-09-28T10:31:34Z) fails in helm-unit-tests:

ERROR: packages/system/cozyplane reported no test suite that ran. Its Makefile
       declares a 'test' target, so its recipe is expected to
       run helm-unittest over suites under tests/ matching *_test.yaml.
ERROR: Tests failed in the following directories:
  - packages/system/cozyplane
  - packages/system/cozyplane-apiserver
  - packages/system/cozyplane-kpr

The three Makefiles have test: helm lint ., and none of the packages has a tests/ directory. E2E Tests is red only because finalize needs checks, so the in-tree e2e was skipped ("result: skipped"). This does not count as an e2e failure, and it is not e2e coverage either.

The new platform branches have no tests, and packages/core/platform/tests has a suite for every comparable switch (bundles_multus_staging_test.yaml, bundles_networking_encryption_test.yaml). Nothing in that suite or in packages/system/cozystack-api/tests mentions networkingVariant, cozyplane or serveSDN. I'd expect at least these: the default renders kubeovn-cilium, an unknown value fails, cozyplane drops multus, kubeovn-webhook/plunger, securitygroup-controller and the VPC app, serveSDN: false removes only the sdn APIService, and the B3 guard. The new charts need a suite each that renders the Talos overlay, KubePrism host included.

B3: networkingVariant: cozyplane is accepted on variants where it breaks the cluster

The value is validated only inside the isp-full branch (system.yaml:43). Everything else it controls is gated without looking at variant. I rendered variant: isp-full-generic with networkingVariant: cozyplane. It renders without error. cozystack.networking stays on kubeovn-cilium-generic, so Cilium and kube-ovn still run. At the same time the bundle drops kubeovn-webhook, kubeovn-plunger, securitygroup-controller and virtualprivatecloud-application and turns off the sdn APIService in cozystack-api. It also adds cozyplane-cilium-crds next to the real Cilium and cozyplane-apiserver with no cozyplane CNI. isp-hosted and distro-full also get the last three changes.

The same gap applies to gateway.enabled: true on the variant. The default gateway.className is cilium, and nothing serves that class once Cilium is gone.

Fix: fail when networkingVariant != "kubeovn-cilium" and variant != "isp-full", and fail or require a different class when the gateway is enabled on cozyplane. Both need unit tests.

B4: tenant isolation stops being enforced and nothing says so

The tenant chart's isolation is CiliumNetworkPolicy and CiliumClusterwideNetworkPolicy (packages/apps/tenant/templates/networkpolicy.yaml). cozyplane-cilium-crds exists so those objects apply. Nothing on the variant enforces them, so every tenant install reports success while tenant-to-tenant traffic on the default network is open. The same is true for the linstor, monitoring-agents and ingress-nginx policies. The PR body lists this as a known gap, but an operator reads values.yaml, and there the option says only "(no Cilium, no kube-proxy)". For a multi-tenant platform that is the most important property of the choice. Before this leaves draft, the networkingVariant comment and the package docs need to say that tenant network isolation and the host firewall are not enforced on cozyplane.

B5: images come from a personal namespace with no version and no vendoring recipe

The tree already accepts third-party images from a personal namespace. Ouroboros and kuberture do it, so the namespace alone is not the problem. The problem is that nothing ties these pins to a release:

1. The refs are digest-only. docs/agents/image-refs.md wants tag plus digest, and ouroboros carries 0.8.1@sha256:… with a comment on mirroring for air-gapped installs. Upstream has no release tags, only floating main and main-<sha> tags from pushes to main. So ghcr.io/lllamnyp/cozyplane:<version>@sha256:… is not possible yet.
2. The release job builds with provenance: false, sbom: false, and does not sign. Only the upstream repo owner can push to that namespace. So the CNI, which runs privileged with hostNetwork on every node, has one person's account as its only supply-chain control.
3. The three charts are copied by hand. Other vendored packages have an update target that fetches a pinned upstream ref, and these Makefiles have none. Chart.yaml says "the real version is stamped by the build/release pipeline", but nothing here stamps it.
4. The refs sit outside the promote, retag and nightly-mirror flows (third-party class), and no comment says who mirrors them.

Minimum before this leaves draft: an upstream release tag with the image tagged by it, repo:vX.Y.Z@sha256:… in values, and an update target that re-vendors the charts from that tag. The better long-term answer for a default-capable CNI is to build it under ghcr.io/cozystack in the project's release process.

B6: the PR body and commit history don't describe what ships

This repo merges with merge commits, so the body becomes the merge message and all 45 commits land on main. Two sections of the body are wrong against the diff:

1. "Bootstrap ordering" describes the bootstrap-CRD takeover. Commit 46f2104 says the takeover is gone and the tenant kinds have no CRDs.
2. "removes the old cozyplane-cilium variant and system/cilium/values-cozyplane.yaml". Neither exists on main, and the diff removes nothing.

The commits need a rewrite before this leaves draft. Only one of the 45 subjects uses a Conventional Commits type. The rest look like cozyplane: bump to …, cozyplane: vpc-nat reply mark or cozyplane: repair the apiserver template. Eighteen have no body beyond the trailers. Several narrate the process instead of the reason, for example f6ccb5b "it was left out of the bump commit" and cb76b4e "the old 0.3.17 pin had that regression". A few commits split by component, with a WHY each, would do.

Non-blocking

1. sources/networking.yaml:153 points to docs/kube-proxy-replacement.md, which lives upstream, not here. Line 155 says VM-guest ClusterIP does not work yet, while the body says net-0 ClusterIP DNAT is done.
2. There is no e2e lane for the variant. The in-tree e2e only runs kubeovn-cilium. The upstream e2e workflow ran on schedule on 2026-09-14 and 2026-09-21 and failed both times, so the 107/107 kind result has no CI run behind it. A lane isn't required for a draft, but it is needed before anyone can select this.
3. Size: about 13,450 of the 15,340 added lines are the two Cilium CRDs, vendored verbatim from 1.19.5. About 1,740 are the three vendored cozyplane charts and about 144 are platform and cozystack-api wiring. Reviewers here really own the wiring and the pins. The charts' substance is reviewed upstream, which makes B5 more important.
4. The failing Require API owner review for sizeable API changes check is process, not a defect.

Timofei Larkin (@lllamnyp) NOT LGTM. The arm64 images still carry x86-64 binaries, which was the main point of my last review. The new head only changes the image digest.

On the arm64 entry of ghcr.io/lllamnyp/cozyplane (digest starting sha256:3d87b7ad), crane export --platform linux/arm64 plus file shows cozyplane-apiserver, sdn-controller, cozyplane-gateway, cozyplane-responder and the CNI binaries built for x86-64. cozyplane-kpr (sha256:7417b9ad) was not rebuilt and is the same. The cause is upstream: ARG TARGETARCH=amd64 in Dockerfile:15,28 and kpr/Dockerfile:26 stops BuildKit from filling the platform arg. hack/verify-multiarch.sh only checks the platform list in the index, so CI won't catch it, while cozyplane-kpr/values.yaml:1-3 says the image is built for both.

The other points from that review are still open. There are no chart tests for the cozyplane branches, and the platform suite never sets networkingVariant or serveSDN. networkingVariant is gated on isp-full in bundles/system.yaml:4,42 but not at :183, :206, _helpers.tpl:131 or iaas.yaml:212. Tenant access to sdn.cozystack.io is neither enforced nor documented: the cozyplane-tenant-* roles aggregate into the built-in admin/edit/view, and Cozystack tenants don't get those. Images are pinned only by digest from a personal namespace with no update target, and registry.k8s.io/etcd:3.5.16-0 has no digest.

New in this round:

1. sdn.cozystack.io/v1alpha1 SecurityGroup is served twice with different schemas, by cozystack-api and by cozyplane. docs/security/threat-model.md:57 is wrong on this variant.
2. The apiserver role can get, list and delete any CRD and create or patch any APIService, with no resourceNames (cozyplane-apiserver/templates/apiserver.yaml:82-91). A compromised pod could delete any CRD or take over v1alpha1.apps.cozystack.io. The controller can create Deployments cluster-wide (controller.yaml:100).
3. The PR body says etcd runs memory-backed, but the default is persistent: true (values.yaml:34). The body becomes the merge commit, and 44 of the 45 commit subjects are not Conventional Commits.

Not blocking: the apiserver runs one replica, so the whole API group goes down with it, and the controller runs with --leader-elect=false. There is a small conflict with main in cozystack-api/values.yaml, and the website and ansible-cozystack follow-ups are not ticked.

Timofei Larkin (@lllamnyp) NOT LGTM. The arm64 image entries still carry x86-64 binaries, the apiserver RBAC is still not scoped, the branch conflicts with main, and the variant ignores the platform's pod and service CIDRs. Reviewed at 03a5713.

The tests, the variant guard and the "not enforced" wording are done. The new suites pass, and the mutations I tried are caught: dropping the isp-full check, setting serveSDN back to true, and changing the KubePrism port each fail a test. The SecurityGroup GVK collision is closed within one cluster, because serveSDN: false removes only the sdn APIService and apiservice_test.yaml pins that.

The default path is still safe. I rendered the platform chart at this head and at its merge base for all four system variants, with only the system bundle and with every bundle on. No Package changed. The only additions are the two new PackageSources and the cozyplane entry in cozystack.networking. The dependsOn graph of the cozyplane render has no cycles and no missing packages. CI on this head is green except the API owner gate, which is process.

Blockers

B1: the arm64 entries are still amd64

This push didn't change the digests. In ghcr.io/lllamnyp/cozyplane@sha256:3d87b7ad…, the linux/arm64 entry sha256:add6c72a0f2d… has the agent, apiserver, gateway, responder, sdn-controller and the three CNI binaries built as ELF x86-64. The arm64 entry of cozyplane-kpr@sha256:7417b9ad… is the same. The vendoring ref COZYPLANE_REF=ac934e14 still has ARG TARGETARCH=amd64 in kpr/Dockerfile:26.

Upstream fixed it about 40 minutes after this head was pushed. e44cb7eda drops the default, and 65bade1c3 repins to cozyplane@sha256:60111aff… and cozyplane-kpr@sha256:41a76cbc…. I checked the arm64 entries of both new digests, and the agent, host-local and cozyplane-kpr there are ARM aarch64. Bumping COZYPLANE_REF to 65bade1c3 or later and running make update in the three packages should be enough. I diffed the vendored charts against ac934e14, and only the Chart.yaml version stanza differs, so the recipe reproduces the tree.

B2: the apiserver and controller RBAC is still cluster-wide

cozyplane-apiserver/templates/apiserver.yaml:83-91 still grants get, create, patch on every APIService and get, list, delete on every CRD, with no resourceNames. cozyplane/templates/controller.yaml:100 still lets the controller create and delete Deployments in any namespace. Upstream 2cb23e62a fixes all three. It scopes get and patch to v1alpha1.sdn.cozystack.io, limits delete to the listed CRD names, keeps create as its own rule (RBAC can't restrict create by name), and moves the Deployment writes into a namespaced Role. The same re-vendor as B1 brings it in.

B3: merge conflicts with main

packages/core/platform/values.yaml, templates/_helpers.tpl and templates/bundles/system.yaml conflict. Since the merge base, main added the isp-slim, isp-slim-generic and isp-hosted-slim variants, dropped distro-full, and moved the common packages to cozystack.platform.package.full.default. The guard at system.yaml:9 only accepts exactly isp-full, so the resolution has to decide what the slim variants do, and the networking-variant suite needs a case for one of them.

B4: the variant ignores networking.podCIDR and networking.serviceCIDR

The platform passes its network settings only to the kube-ovn and Cilium components, and the cozyplane variant installs neither. system.yaml:22-53 builds $networkingComponents for kubeovn and cilium only. So cozyplane always runs with the chart defaults in cozyplane/values.yaml:45-53: clusterCIDR: 10.244.0.0/16, serviceCIDR: 10.96.0.0/16, clusterDNS: 10.96.0.10. Those values feed --cluster-cidr and --internal-cidrs in agent.yaml:167-177 and controller.yaml:159-163.

On a cluster with a non-default pod or service CIDR, the masquerade matches the wrong source range. VPC gateways block the wrong internal ranges, and their one DNS opening points at an address with no DNS behind it. Fix: on the cozyplane variant, set the component's egress.clusterCIDR and egress.serviceCIDR from .Values.networking. clusterDNS has no platform value today, so either derive it from the service CIDR or add one. A platform test with a non-default CIDR should cover it.

B5: the PR body and the commits still don't match what ships

This repo merges with merge commits, so the body becomes the merge message and all 50 commits land on main.

1. "Bootstrap ordering" (body lines 30-62) says the CNI serves sdn.cozystack.io as bootstrap CRDs and the apiserver takes over from them. system.yaml:227 says "There is no takeover: the tenant kinds have no CRDs at all", and cozyplane/tests/talos_render_test.yaml asserts that only local.sdn.cozystack.io CRDs ship.
2. The body still says it "removes the old cozyplane-cilium variant and system/cilium/values-cozyplane.yaml". Neither exists on main, and the diff removes nothing.
3. It still says the apiserver's etcd "runs memory-backed". cozyplane-apiserver/values.yaml:34 defaults to persistent: true.
4. The body is hard-wrapped at about 80 columns. AGENTS.md (Prose Formatting) asks for one line per paragraph.
5. 44 of the 50 subjects are not Conventional Commits. Some carry upstream issue numbers as bare refs, like (#15) in f63c4b1 and 22986e5, (#14 increment 0) in a56ebae and #11 in ed2bd4b. On this repo GitHub links them to unrelated cozystack issues. Others use planning labels instead of a reason, like "increment 3 Half A" in 63aca5b or "R5" in 8e79252. A few commits split by component, each with a WHY, would fix this.

Still open, not blocking a draft

1. Cozystack tenants still can't reach the variant's tenant API. cozystack-basics/templates/clusterroles.yaml:36,93,285 grants only securitygroups in sdn.cozystack.io, and here that is cozyplane's kind with a different schema. VPCs, bindings, peerings, gateways and floating IPs come only through aggregate-to-admin/edit/view, which tenant users are not bound to. The bundle also drops virtualprivatecloud-application, so the variant has no tenant-facing VPC app. The work from the closed #4034 would land here or in a follow-up.
2. registry.k8s.io/etcd:3.5.16-0 at cozyplane-apiserver/values.yaml:40 has no digest, and the cozyplane refs are digest-only. Upstream now cuts vX.Y.Z tags (24d380910), so a repo:vX.Y.Z@sha256:… pin and a tag as COZYPLANE_REF are possible before this leaves draft.
3. make update writes "the real version is stamped by the build/release pipeline" into each Chart.yaml, but nothing stamps it. CHART_VERSION is hard-coded in the Makefile.
4. cozyplane-cilium-crds is the only package under packages/system without a Makefile. Its two CRDs are copied from Cilium 1.19.5 with no recipe, so they will drift from the cilium package without anyone noticing.

Verdict

NOT LGTM

Draft opt-in cozyplane variant. The default kubeovn-cilium path is unchanged (231 platform unit tests green, 3 mutations covered, Package set identical). Two confirmed defects in the new variant, an acknowledged default-network isolation gap, and the unmet API-owner gate keep it from merging.

Findings

• [MAJOR] packages/system/cozyplane/templates/tenant-rbac.yaml:21, tenant VPC grant aggregates into built-in roles no tenant is bound to

• [MAJOR] packages/system/cozyplane-kpr/templates/daemonset.yaml:28, kpr ClusterRole wildcards all of cilium.io with mutating verbs

• [MINOR] packages/core/platform/templates/bundles/system.yaml:76, empty podCIDR silently drops masquerade; non-IPv4 serviceCIDR panics illegibly

• [MINOR] packages/system/cozyplane-apiserver/values.yaml:38, EtcdCluster storageClass replicated is hardcoded and immutable

• [MINOR] packages/system/cozyplane/templates/controller.yaml:194, controller.replicas settable while --leader-elect=false is hardcoded

• [MINOR] packages/system/cozyplane/templates/agent.yaml:183, unauthenticated metrics on hostPort 9411 with host firewall dropped

• [MINOR] packages/system/cozyplane/templates/agent.yaml:22, multi-paragraph prose in # comments ships into rendered manifests

• [MINOR] packages/system/cozyplane-cilium-crds/Chart.yaml:2, no Makefile / re-vendor recipe for the vendored Cilium CRDs

Operational risks

• Default-network tenant-to-tenant isolation is NOT enforced on the cozyplane variant (CiliumNetworkPolicy ships inert; native-NetworkPolicy enforcement and the RBAC for it are not wired yet). Disclosed in docs/security/threat-model.md, values.yaml and the PR body. Keep the variant out of multi-tenant production until isolation is rebuilt (author-acknowledged follow-up).

Caveats

• Switching networkingVariant on a live cluster is destructive: the operator's orphan-HR cleanup removes the cilium/kube-ovn releases while resource-policy: keep Packages linger. Not an in-place operation; add a lookup-guard that fails on a variant change, or document it as install-time only. Not verified in Go (no .go in this diff).
• CI red "Require API owner review" is a governance gate, not a code defect: self-approval is forbidden and the author is an API owner, so a second owner must approve.
• The two denypolicy-identity-reachability lint hits are false positives: both files are kind: CustomResourceDefinition only, every ingressDeny is an OpenAPI schema property name, no policy instance ships.
• Multi-arch image legs are unverifiable in a hermetic review; the digests are the fixed refs. docker manifest inspect ghcr.io/lllamnyp/cozyplane@sha256:60111af... settles it.
• Cilium CRDs confirmed CRD-only and inert; a byte-match to upstream 1.19.5 was not fetched.

Recommended follow-ups

• Before leaving draft: move the images off the personal ghcr.io/lllamnyp/* namespace into the cozystack org registry, digest-pin registry.k8s.io/etcd:3.5.16-0, and add the variant's e2e lane.

Verdict

NOT LGTM

Round 2, now covering the networking substance the first pass could not reach: I read the datapath from lllamnyp/cozyplane@65bade1c3 and mutation-tested the chart wiring. Thanks for the fast turnaround: the 3 fixes you pushed (input validation, etcd SC local, cilium-crds Makefile) close my earlier system.yaml / etcd / vendoring notes. Three blockers remain, two new from the networking review.

Findings

• [MAJOR] packages/core/platform/templates/bundles/system.yaml:253, inert Cilium policies disable platform self-protection, wider than threat model discloses

• [MAJOR] packages/system/cozyplane/templates/agent.yaml:171, egress/isolation datapath has no test coverage (mutation-proven)

• [MAJOR] packages/system/cozyplane/templates/tenant-rbac.yaml:21, tenant VPC grant still never reaches tenants (unchanged since round 1)

• [MINOR] packages/system/cozyplane/values.yaml:56, default internalCIDRs omits the node/management network

• [MINOR] packages/core/platform/sources/networking.yaml:166, variant hard-requires Talos/KubePrism with no precondition guard

• [MINOR] packages/system/cozyplane-kpr/templates/daemonset.yaml:28, kpr ClusterRole wildcards all of cilium.io with mutating verbs (downgraded from round 1 MAJOR)

• [MINOR] packages/system/cozyplane/templates/controller.yaml:194, controller.replicas settable while --leader-elect=false is hardcoded

• [MINOR] packages/system/cozyplane/templates/agent.yaml:183, unauthenticated metrics on hostPort 9411 with host firewall dropped

• [MINOR] packages/system/cozyplane/templates/agent.yaml:22, multi-paragraph prose in # comments ships into rendered manifests

Operational risks

• Default-network tenant isolation is off AND platform-component CNP self-protection is inert (MAJOR 1). Keep the variant out of multi-tenant production until isolation is rebuilt; ingressDeny-class protections need more than native NetworkPolicy.

Caveats

• Datapath notes from the source read (lllamnyp/cozyplane@65bade1c3): default-network KubeVirt VMs load-balance across at most 16 Service backends silently (kpr/services.go:60), and SCTP ClusterIP Services are unsupported (kpr/services.go:114), a narrow regression vs the kube-proxy being replaced. Both deserve a docs note.
• NIT: the new input-validation guard (5389123ad) rejects an IPv4-primary dual-stack serviceCIDR like 10.96.0.0/16,fd00::/112 with its IPv4-only regex; the pre-fix code derived clusterDNS from the leading v4. Legible failure, so minor, but stricter than needed.
• Live traffic (ClusterIP/NodePort/LB, pod-to-pod, VM-to-service, DNS, isolation) is NOT verified: swapping the CNI on a running cluster is irreversible and no disposable Talos stand was available, so the datapath is confirmed only by the source read above, not by a run. A fresh 3-node Talos stand is needed to prove packets actually move. This unverified surface is itself a blocking caveat, not a silent pass.

Recommended follow-ups

• Digest-pin registry.k8s.io/etcd:3.5.16-0; add the variant's e2e lane (there is none in-tree today); before leaving draft move images off the personal ghcr.io/lllamnyp/* namespace.

Timofei Larkin (@lllamnyp) NOT LGTM, only because the branch conflicts with main again. Everything else that blocked in my last review is fixed at 484c0655.

What I checked:

1. The arm64 leg of cozyplane@sha256:880db757... (sha256:70bb1821...) now carries ARM aarch64 binaries. I extracted the layers and ran file on the agent, apiserver, gateway, responder, sdn-controller and all three CNI plugins. cozyplane-kpr@sha256:41a76cbc... is the build I already checked last time. Both digests match what upstream pins at 2608ed75.
2. The apiserver role names v1alpha1.sdn.cozystack.io for get/patch and lists the CRD names for delete. The Deployment writes moved into a namespaced Role.
3. The platform threads podCIDR, serviceCIDR and the derived clusterDNS into the component, and the platform suite covers that, the explicit override and both refusals.
4. The commits and the PR body now describe what ships.

On the PR head, helm unittest passes for platform (235), cozystack-api (16), cozyplane (4), cozyplane-kpr (3) and cozyplane-apiserver (4).

Blocker

packages/core/platform/templates/_helpers.tpl and templates/bundles/system.yaml conflict with current main, and GitHub reports the PR as CONFLICTING. The cause is #4778, which landed after your rebase. It adds the ciliumPool helpers next to the securitygroup-controller block. In system.yaml it also rewrites the end of the kube-ovn/Cilium values block, so kube-ovn excludes the last /21 of the pod CIDR and Cilium allocates from it. Keep those lines inside the kubeovn-cilium path. The /20 or shorter podCIDR check there must not fire on cozyplane, which has no kube-ovn. One test with networkingVariant: cozyplane and a /24 pod CIDR would pin that.

Not blocking

1. Red Unit & controller tests on this head (2026-10-07T12:46Z, attempt 1) is hack/bats-strict-setup.bats complaining about hack/fork-new-images.bats. That file is not in this diff, and main fixed it in 0ea11b4. A rebase clears it. Require API owner review is process.
2. registry.k8s.io/etcd:3.5.16-0 in cozyplane-apiserver/values.yaml still has no digest, and each Chart.yaml still says the version "is stamped by the build/release pipeline" while nothing stamps it.
3. On IvanHunters' last review: the kpr cilium.io wildcard, the leader election and the unauthenticated metrics are fixed. Three points are still open. The threat-model note covers only the tenant rows, not the platform components' own CiliumNetworkPolicies. The cozyplane chart suite has no case for egress.* reaching --cluster-cidr/--internal-cidrs. tenant-rbac.yaml still aggregates only into admin/edit/view, and the body defers that to #4508.