Network Isolation
Network isolation keeps the network traffic of one tenant's Compute Pool separate from that of another tenant on shared AI edge infrastructure. It is built for regulated and secure-AI environments where two tenants can run on the same physical fabric yet must be provably unable to reach the other tenant's GPU traffic or external ingress.
The scope of that separation is not unconditional. It applies under the dedicated model, where each tenant runs in its own cluster on dedicated servers, and each network plane is isolated only when the underlying fabric advertises the matching capability. The What Is Isolated and What Is Shared and Fabric Capability Matrix sections below define exactly which planes are isolated and which remain shared.
You configure network isolation from the Network Isolation page in the PaletteAI console, available at the system, tenant, and project scope. The page has up to three tabs:
- Integrations — Connect PaletteAI to an external network fabric provider. PaletteAI supports the Aviz provider, which integrates with the Aviz ONES fabric.
- Isolation Units — Review the per-tenant isolation units that the provider allocates on the fabric.
- Tenancy Settings — Govern whether network isolation is optional or required for System-scoped, Tenant-scoped, and Project-scoped Compute Pools. This tab appears at the system and tenant scope. At the project scope, PaletteAI displays the inherited governance state as read-only instead, so only Integrations and Isolation Units are shown.
A Compute Pool opts into isolation through its networkIsolation field, which names the provider and the Aviz ONES Tenant the pool uses. For the full manifest schema, refer to the ComputePool Configuration reference. To create a pool with isolation enabled, refer to Create and Manage Compute Pools.
Network Isolation Planes
When a Compute Pool has network isolation enabled, PaletteAI separates the edge host's traffic into distinct network planes, each carried on its own interface rather than collapsed onto a single tenant VLAN. This lets management, external ingress, GPU traffic, and storage be addressed and isolated independently.
The planes map onto two groups of physical network interfaces on each edge host.
The front-end NIC is the host's single primary interface. It carries three planes:
| Plane | Interface | Purpose |
|---|---|---|
| Management | Base interface | The node IP, the primary Cilium CNI pod network, and the edge agent's connection to Palette. |
| North-South | VLAN sub-interface | External ingress to the tenant's workloads, addressed from the tenant's North-South IP pool. |
| Storage | VLAN sub-interface | Storage traffic on a dedicated tenant VLAN. Optional. |
The East-West rail NICs are the separate high-speed ConnectX interfaces used for GPU-to-GPU communication. An HGX host typically exposes eight rails, one per GPU:
| Plane | Substrate | Purpose |
|---|---|---|
| East-West | Rail NICs handed whole to GPU pods | GPU collective traffic over RoCE, addressed per tenant and isolated by the fabric. |
The East-West rails are passed directly to GPU pods as host devices, so RoCE traffic bypasses the pod overlay and runs at the performance the NVIDIA reference architecture expects.
What Is Isolated and What Is Shared
Network isolation protects the tenant data planes — East-West GPU traffic and North-South ingress. The management plane is shared by design. Understanding this boundary is important when you assess whether isolation meets your security requirements.
| Plane | Status | Isolation guarantee |
|---|---|---|
| East-West (GPU RoCE) | Isolated | Each tenant's rail NICs sit on a per-tenant fabric segment, so one tenant's GPU traffic cannot reach another tenant's. |
| North-South ingress | Isolated | Load balancer and gateway virtual IPs are drawn from the tenant's North-South pool and announced only on that tenant's segment. |
| North-South egress | Shared | Workload egress rides the shared front-end path. This is safe because each tenant runs in its own cluster on dedicated servers, so a node only ever carries one tenant's workloads. |
| Storage | Optional | Isolated when the fabric provides a tenant storage segment; otherwise routed to shared storage. |
| Management | Shared | The node IP, pod overlay, and edge agent share the front-end NIC's base segment across tenants. Palette is a single multi-tenant SaaS, so the agent's connection to it is shared by design. |
Isolation is enforced at the segments tenant traffic crosses. Because each isolated tenant runs in its own cluster on dedicated servers, there is no shared in-cluster pod network to breach, and the shared management segment only ever carries a single tenant's workloads.
Network isolation assumes the dedicated model: one cluster per tenant on whole servers. Shared Compute Pools, where multiple tenants share a cluster, are not covered by these isolation guarantees.
Fabric Capability Matrix
A fabric can be tenant-aware on the East-West plane, the North-South plane, or both, and PaletteAI adapts to what the fabric reports rather than assuming full isolation. The fabric advertises two independent capability flags, and each plane's isolation is applied only when its own flag is set. The two flags do not depend on each other: North-South ingress can be isolated whether or not East-West is, and the reverse.
The following table lists all four combinations. The first two columns are the fabric flags; the last two are the resulting isolation of each plane.
| East-West tenant-aware | North-South tenant-aware | East-West (GPU RoCE) | North-South ingress |
|---|---|---|---|
| ✅ | ✅ | Isolated per tenant | Isolated per tenant |
| ✅ | ❌ | Isolated per tenant | Shared — falls back to the shared path |
| ❌ | ✅ | Unavailable — no per-tenant East-West segment | Isolated per tenant |
| ❌ | ❌ | Unavailable — no per-tenant East-West segment | Shared — falls back to the shared path |
Full isolation, the design target, is the first row, where both flags are set. When the East-West flag is not set, the fabric provides no per-tenant East-West segment, so GPU RoCE isolation is unavailable regardless of the North-South flag. When the North-South flag is not set, PaletteAI does not render a per-tenant ingress pool, because announcing it onto a segment that is not tenant-private would leak traffic across tenants. Instead, PaletteAI degrades to the shared path and marks the North-South plane as not tenant-isolated, so the reduced guarantee is explicit rather than silent.
Requirements
Network isolation depends on the following:
- The dedicated Compute Pool model — Each isolated tenant runs in its own cluster on dedicated servers. Shared Compute Pools are not supported for isolation.
- A resolved default NIC on each host — Because the node IP and Cilium stay on the front-end NIC, each multi-NIC edge host must have a resolved default NIC before it is allocated to a Compute Pool, and on clusters without network overlay that NIC must have a usable IP address. Refer to Default NIC and Static IP for how PaletteAI resolves the front-end NIC.
- Cilium as the primary CNI — The primary pod network is always Cilium. Other CNIs are not supported for isolation.
- The NVIDIA Network Operator — Delivered as a cluster add-on, it installs Multus, NV-IPAM, and the device plugins that advertise the East-West rail NICs.
- RoCE-capable rail NICs — East-West isolation requires ConnectX rail NICs prepared for lossless RoCE.
- An Aviz ONES fabric — The fabric supplies the per-tenant isolation facts and enforces East-West segment isolation.
How Network Isolation Is Delivered
The isolation facts flow from a single source of truth — the tenant's Aviz ONES record — with no manual per-host configuration. Two ownership boundaries deliver the planes:
- Host plane — The edge agent brings up the North-South and optional storage VLAN sub-interfaces on the front-end NIC and keeps the node IP and Cilium on that NIC's base management interface. The agent does not touch the rail NICs.
- Cluster plane — PaletteAI delivers the cluster content that wires the remaining planes. The NVIDIA Network Operator add-on profile attaches the East-West rails to GPU pods and assigns their per-tenant addresses. Cilium's built-in load-balancer IP management announces the tenant's North-South ingress pool on its segment. Because the announcer is part of Cilium, no separate load-balancer add-on is required.
The result is that GPU RoCE gets a real per-tenant path, external ingress gets an explicit isolated path, and the shared management path stays shared on purpose — all rendered automatically from the tenant's fabric facts.
Next Steps
- Create and Manage Network Isolation — Connect an Aviz ONES fabric, define isolation units, and govern where isolation is required.
- Create and Manage Compute Pools — Create a Compute Pool with network isolation enabled.
- ComputePool Configuration — Review the
networkIsolationmanifest schema.