Skip to content

Threat model

This is the threat model for the prototype. It restates what the code does and — just as importantly — what it does not defend. The guiding rule is that unknown, unsupported, stale, or untrusted evidence must never silently pass.

Assets

Placement rules, tenant identity, decision integrity, discovery data, and audit metadata. Workload assets (model weights, prompts, training data, credentials, checkpoints) are out of scope — the prototype never inspects or ingests them.

Adversaries and assumptions

  • An untrusted tenant may submit Pods, manipulate permitted metadata, request unusual resources, retry, and attempt to select a different scheduler.
  • Operational faults occur: stale caches, malformed reports, missing collectors, partial outages.
  • The prototype trusts: the cluster administrator, the API server, the configured policy administrator, the host kernel, the GPU driver, and the authenticated collection path.
  • A compromised host may lie about its own state. The prototype does not claim to defend tenant data against a malicious host administrator.

Trust boundaries

flowchart TD
    T[Untrusted tenant] -->|namespace-UID mapping only| ID[Identity resolver]
    ID -->|server-resolved tenant| EV[Evaluator]
    COL[Collector] -->|authenticated, bound to node UID| ES[Evidence store]
    ES --> EV
    ADM[Policy administrator] -->|versioned + digested policy| EV
    EV -->|subject, candidate, digest, evidence refs, validity| SCH[Scheduler]
    SCH -->|only the checked scope| ALLOC[Device allocation]
    RT[Runtime] -->|observations + gaps, never 'promoted' to crypto| MON[Monitoring]
Boundary Rule Status
Tenant → identity Derive tenant from admin-controlled Namespace-UID mapping; ignore tenant identity claims WorkloadIdentity.tenantId is server-resolved; TenantBinding is admin-owned
Collector → evidence Authenticate source; bind to node UID; a report body cannot choose its authority Opt-in SPIFFE/mTLS: bound server-side from the cert (403/409/TLS-reject)
Policy admin → evaluator Version + digest the effective policy; tenant overrides may only tighten Policy digest implemented; "tighten-only" conjunction is the rule
Evaluator → scheduler Decision includes subject, candidate, policy digest, evidence refs, validity Implemented in PlacementDecision
Scheduler → allocation Admit only the checked scope; device guarantees need allocation binding Node-scope only; device binding out of scope
Runtime → monitoring Record observations and gaps; never turn telemetry into cryptographic evidence Observation status + sources; attestation stays separate

GPU management components may need substantial privileges, but the discovery agent does not copy the GPU Operator's privileges by default; each real collector documents the minimum access it needs.

Explicit non-claims (never silently pass)

What Xila Guard does NOT claim

  • Admission does not select a physical GPU; the scheduler evaluates node-scope policy, not a specific allocated device (device binding needs an allocation hook).
  • mock / admin_inventory evidence is not attestation; telemetry is not isolation proof; a simulated attestation result is never real evidence.
  • No defense against a malicious host administrator; the prototype trusts the host kernel, GPU driver, API server, and configured administrator.
  • Attestation, confidential execution, memory erasure, and region / tenant exclusivity as hardware-attested facts are unsupported.
  • A shared DaemonSet service account with a self-chosen node_id is not a valid node identity.
  • Unknown / unsupported / stale / untrusted evidence is never treated as satisfied.
  • No claim of SOC 2 / ISO 27001 certification, legally-compliant placement, verified isolation, or protection against malicious administrators.

Residual risks acknowledged

  • Observation is periodic; gaps exist between checks.
  • PreBind and drift detection narrow, but cannot prove, that state is unchanged at execution time.
  • Consumer-card NVIDIA discovery validates basic fields only; MIG, confidential computing, and attestation are not validated on it.

See the support matrix for the versioned capability boundary and the trust-sources ADR for acceptance rules.