Xila Guard is a fail-closed policy layer for GPU/XPU workload placement on Kubernetes. A single canonical evaluator decides, and explains, every placement — and never says allow on evidence it can't trust.
“Does this candidate placement satisfy this workload's explicit policy, given the evidence we currently have?”
# evaluate a placement offline — no cluster, no GPU $ xila-guard evaluate --request allow_all_satisfied.json allow exit 0 $ xila-guard evaluate --request deny_time_slicing.json deny reasons=[TIME_SLICING_FORBIDDEN] exit 2 $ xila-guard evaluate --request incomplete_inventory.json indeterminate exit 3 (fail-closed — never allow)
What it does
Policy semantics live in a single Rust evaluator. Kubernetes components and orchestrator integrations call it — they never re-implement the rules.
Unknown, unsupported, stale, or untrusted evidence is never treated as satisfied. The safe answer is indeterminate, not allow.
One decision engine with versioned contracts, JSON Schemas, and shared conformance fixtures across Rust and Go. No divergent policy copies.
Report-only observation of every placement by default; opt-in enforcement via a scheduler plugin and a fail-closed admission webhook.
Per-node X.509-SVIDs over mTLS bind each hardware report to a server-verified node — spoof, replay, and untrusted certs are rejected.
A pluggable RFC 9334 verifier model. The shipped simulated verifier is clearly marked and is never accepted by enforcement.
An out-of-tree, co-registered webhook adds policy to other schedulers with no fork. run:ai and Volcano verified; others are a one-line profile.
No over-claiming
A security tool that exaggerates its guarantees is worse than none. Here is the current, verified line between what runs and what is simulated.
| Capability | Status |
|---|---|
| Policy evaluator, CRDs, observer, scheduler + webhook | REAL · e2e in kind |
| NVIDIA basic discovery (consumer RTX 3070) | REAL |
| SPIFFE/SPIRE collector identity, in-cluster | REAL |
| Orchestrator integration (run:ai · Volcano) | REAL · verified |
| MIG & datacenter GPU profiles | SIMULATED |
Enforcement decisions (over mock evidence) | LAB-SIMULATED |
| RATS attestation verifier | SIMULATED · never enforced |
An allow means the evaluated requirements were satisfied under a documented trust model and snapshot — not that any GPU, workload, or environment is secure.