NVIDIA's NVKE Is a Kubernetes Factory That Ships With the Auth Turned Off

NVIDIA has published a preview of the NVIDIA Kubernetes Engine, a management plane that platform teams install to run a managed Kubernetes service on their own bare-metal GPU boxes. The repository describes NVKE as “a self-hosting factory for Kubernetes clusters”: a throwaway seed cluster stands up a management cluster, and that management plane then provisions and lifecycle-manages many isolated workload clusters on demand. Each workload cluster gets its own control plane, its own etcd, and its own node pools. The interesting part is not that NVIDIA built a Kubernetes tool. It is where the tool sits in the stack, and how candidly the preview documents what it cannot yet do.

A factory, not a distribution

NVKE is explicit that it is neither a Kubernetes distribution nor a Cluster API flavour. That distinction matters. A distribution ships you a cluster. A Cluster API flavour lets you manage clusters declaratively. NVKE does something narrower and more operational: it is the thing you install so that someone else can request clusters. The management plane provisions machines through NVIDIA Infra Controller, or NICo, which the docs name as the sole compatible infrastructure provider at preview. It then forms clusters through Cluster API and a node agent.

The build produces nine binaries: agent, updater, controller, nvkectl, capd-reboot-controller, nvke-os-image-check, management-engine, tenant-api and operator-api. That is a lot of moving parts for a preview, and it tells you the intended customer. This is not a developer running kind on a laptop. It is a platform team at a neocloud, a colo operator, or a lab that has bought racks of GPUs and now needs to rent them out in Kubernetes-shaped slices.

The security posture is the story

The most striking lines in the README are the limitations, and they are unusually blunt. API authentication is off after installation. The API uses plain HTTP. The docs tell operators to configure authentication and protected access “before admitting callers.” Read that again: the default state of a management plane that provisions infrastructure is open.

To NVIDIA’s credit, the documentation does not bury this. Nodes attest through SPIFFE/SPIRE using their TPM before receiving join credentials, which is a genuinely solid identity mechanism, and etcd encryption is available per cluster. But the management plane itself, the component that holds the keys to every workload cluster, ships unauthenticated over cleartext HTTP. The full-disk-encryption node images are flagged as evaluation-only and provide “no data-at-rest confidentiality.” The management cluster does not upgrade, scale or replace itself. There is no management-plane upgrade procedure and no backup or restore procedure.

For a preview, that is defensible. For anyone tempted to run this on real hardware with real tenants, it is a checklist of things that will bite. The gap between “TPM-attested node identity” and “plain HTTP with auth off” is the gap between a security model and a security theater prop.

What NVIDIA is actually building toward

Strip away the preview caveats and the architecture is legible. NVIDIA wants a repeatable way to turn bare metal into tenant-ready GPU Kubernetes, with a build pipeline attached. The companion project, NVIDIA Kubernetes Recipes (NVKR), builds node images and NVKE components from pinned inputs. NVKE deploys those artifacts; NVKR owns their build and release evidence. That split, build evidence on one side and deployment on the other, is the kind of supply-chain discipline that regulated buyers and large platform teams ask for. It is also the kind of thing that only matters once you are operating at scale.

The local quickstart needs 6 CPUs, 12 GiB of free memory and 100 GiB of disk, and runs on simulated machines with no NVIDIA account required. That is a sensible on-ramp: evaluate the management plane without owning a single H100. On macOS it runs inside a Colima VM. The toolchain is pinned to Go 1.27.3 and GNU Make 4 or later. Someone at NVIDIA thought about the first hour of a new user’s experience, which is more than most infrastructure previews manage.

The gap between TPM-attested node identity and plain HTTP with auth off is the gap between a security model and a security theater prop.

The strategic read

NVIDIA already owns the accelerator. NVKE is an attempt to own the layer above it: the control plane that decides how GPU capacity gets sliced, scheduled and rented. If platform teams standardize on NVKE to run their GPU clouds, NVIDIA sits in the management path as well as the silicon path. That is a familiar playbook, and it puts NVKE in the same conversation as the managed-Kubernetes offerings from the hyperscalers, except aimed at operators who run their own metal.

The catch is trust. A management plane is the highest-privilege component in the stack. Shipping it in preview with authentication disabled and no backup path is honest, but it also signals that the product is early. The SPIFFE/SPIRE and TPM work shows the team knows how to do identity properly. The question is whether the operational maturity catches up before operators start treating NVKE as production infrastructure, preview label or not.

What to watch

Three things will tell you where this goes. First, whether the authentication and TLS defaults flip to secure-by-default before general availability, because a preview that ships open and a GA that ships open are different products. Second, whether the management-plane upgrade and backup/restore procedures arrive, since a management plane you cannot upgrade or restore is a management plane you cannot run for years. Third, whether NICo stays the only supported infrastructure provider or opens to the broader bare-metal provisioning ecosystem. For now, the honest summary for AI builders is simple: NVKE is a real piece of plumbing with real limitations, and the limitations are printed in the README for anyone who reads past the headline.