Skip to main content
Much of a supervisor’s per-tenant networking is not configured on the Networking page at all — it is configured on the project. The division of labor is deliberate:
  • Projects define the per-tenant intent: which address slices a tenant gets, what source IP its traffic leaves with, whether it is isolated.
  • The Networking page shows and operates the resulting objects: the pools, egress policies, and advertise rows those intents materialize as.
This page is the networking view of projects. For the general project model — creation, isolation policy contents, deletion, permissions — see Projects.

The supervisor addressing plan

Before projects can be carved automatically, the supervisor holds a set of super-CIDRs. Every new project gets its slices cut from them: Allocation reads the live pool objects on every create, so ranges claimed outside Celum are still counted. How the plan is seeded — and why an unseeded plan is a placeholder, not a configuration — is covered under supervisor pool configuration.

What a project provisions

Creating a project materializes its network in one pass: A project’s network profile, as the platform reports it (sanitized):
An empty podCidr means the project’s pods share the cluster-wide pod CIDR. A non-empty one means the project has its own pod pool — its prefix then becomes independently advertisable.

Egress identity

Each project can leave the cluster with its own source addresses — the basis for upstream, per-tenant firewall rules. The project’s egress IPs are drawn from the supervisor’s egress pool and distributed across the egress gateway nodes: each node/IP pair is implemented as one read-only egress policy on the BGP & Egress tab. The egressRouting mode records how those IPs are used — single-active keeps one IP active at a time with failover handled by Egress HA; the per-node spread mode gives each selected node its own always-active IP. The full mode table lives in Projects.

BGP advertise toggles

A project carries an advertise choice — on, off, or default — for each of its three prefix kinds: These selections are stored on the project and fanned out to the BGP engine. On the advertise table they appear as project-sourced rows; the table’s toggles and the project’s toggles are the same state seen from two sides, and the Live column verifies both against what the BGP daemons actually push.

Desired versus present

Isolation-related settings track intent and reality separately, and the gap between them is your reconciliation signal: Desired true with present false means the reconciled policy is missing — usually deleted by hand in Policy Studio. The project then reports itself open even though its recorded intent says isolated. The same pattern (annotation records intent, live object is truth) is explained in Projects. Observability egress rides the isolation policy: when on, the policy opens egress for metrics and log shipping. Turning it off silently stops that data — nothing errors.

Permissions

Project networking follows the project permissions — cilium:GetState to read, cilium:Apply to change, scoped to krn:vks:supervisor:<supervisor>:cilium:*. See Projects — permissions for the caveat about the grant’s breadth.

Projects

The full project model — creation, isolation, deletion.

Pools & IPAM

Where project pools and allocations surface.

BGP & Egress

Where project egress policies and advertise rows surface.

VM identity pools

The optional per-project identity range for VMs.