Skip to content

Xila Guard

Xila Guard is a vendor-neutral, fail-closed security policy layer for accelerator (GPU / XPU) workload placement on Kubernetes. It answers exactly one question, and refuses to guess:

The one question

Does this candidate placement satisfy this workload's explicit policy, given the evidence we currently have?

An allow decision means the evaluated requirements were satisfied under a documented trust model and a specific evidence snapshot. It is not a declaration that a GPU, workload, or environment is secure. Unknown, unsupported, stale, conflicting, or untrusted evidence is never treated as satisfied — it blocks.

Status: research prototype

This is an open-source prototype, not a product launch and not an audited security control. The project is deliberately explicit about what is real versus simulated — see the table below and the support matrix.

Why it exists

Accelerators are shared across tenants through partitioning (MIG), time-slicing / MPS, and virtualization. Who may land where — and on what evidence — is a placement security decision that performance schedulers do not make. Xila Guard supplies one canonical, explainable, fail-closed evaluator plus the Kubernetes glue to observe and (opt-in) enforce it. The data model is vendor-neutral: NVIDIA is the first discovery adapter because it is a concrete target, but AMD Instinct, Google TPU, AWS Trainium, and Intel Gaudi fit the same model without pretending their capabilities are equivalent.

What's real vs. simulated

Credibility is the point of this project, so the boundary is stated plainly:

Capability Status
Policy evaluator, CRDs, observer, scheduler + webhook wiring Real — e2e-verified in a kind cluster
NVIDIA basic discovery (UUID / model / PCI / driver / VBIOS) Real — validated on a consumer RTX 3070
SPIFFE collector identity (opt-in) Real in-cluster — SPIRE + SPIFFE CSI + per-node SVIDs (spoof / replay / untrusted rejected)
Orchestrator integration (run:ai, Volcano) Real — run:ai verified from source; Volcano verified via live e2e against v1.12.2
MIG / datacenter GPU profiles Simulated — no such hardware available
Enforcement decisions Real components, lab-simulated over mock — not real GPU isolation
RATS attestation (opt-in) Simulated verifier; a sim: id is never accepted by enforcement

See the support matrix for the full, versioned breakdown.

Architecture at a glance

flowchart TD
    A[Administrator policy &amp; tenant mapping] --> E[Canonical policy evaluator<br/>xila-guard-core / Rust]
    B[Authenticated inventory snapshots] --> E
    C[Workload &amp; candidate placement] --> E
    E --> D[Decision + evidence references<br/>allow / deny / indeterminate]
    D --> K[Kubernetes adapter<br/>xila-guard-k8s / Go]
    K --> S[Opt-in enforcement<br/>scheduler plugin + webhook]
    K --> O[Observation &amp; drift events]
    O --> B

The observation path may trigger re-evaluation when inventory changes; it preserves each source's provenance rather than treating an event as a new hardware fact. See architecture for the full data flow.

The three repositories

Repo Language Role
xila-guard-core Rust The single policy evaluator, contracts + JSON Schemas, discovery providers (nvidia / mock), CLI, HTTP server + mTLS inventory receiver
xila-guard-k8s Go Placement observer (report-only), opt-in enforcement (scheduler plugin + fail-closed admission webhook + tenant RBAC), CRDs (*.guard.xila.us), Helm chart, orchestrator integrations. Never reimplements policy — it calls core.
xila-guard-lab bash / make Reproducible demos (offline → kind → enforcement → nvidia → in-cluster → attestation → identity → SPIRE), latency benchmark, supply-chain scans

Conventions used across this site

  • Kubernetes API group: guard.xila.us (version v1alpha1).
  • SPIFFE trust domain: xila.us.
  • Namespace: xila-guard-system.
  • License: Apache-2.0 across all repositories.