qarait/gate0Un piccolo, verificabile, terminante, deterministico motore di micro-policy.
Un piccolo motore di policy micro, verificabile, terminante e deterministico.
Ho creato Gate0 perché ero stanco di fare debug di policy basate su RegEx in produzione. Volevo qualcosa di noioso, limitato e impossibile da mandare in crash. Se vuoi un motore di policy flessibile e general-purpose, dovresti usare OPA. Se vuoi un motore di policy con valutazione sub-50µs e zero allocazioni per percorsi critici di sicurezza, vuoi Gate0.
Gate0 è progettato per ambienti ad alta affidabilità dove la valutazione delle policy deve essere deterministica e con risorse limitate. Consulta la Security Policy per segnalare vulnerabilità e il Security Model per il modello di minaccia completo e le garanzie meccaniche.
Gate0 utilizza una strategia di valutazione lineare, Deny-Overrides. Ogni regola è composta da un Target (match rapido) e una Condition opzionale (logica approfondita).
+----------+ +-------------+ +--------+
| Ephemera | ----> | GateBridge | ----> | Gate0 |
| (Legacy) | | (Normalize) | | (Core) |
+----------+ +-------------+ +--------+
| ^
| |
+----(Shadow Log)----+
La correttezza e la sicurezza di Gate0 sono verificate meccanicamente tramite test unitari che coprono la logica principale e i casi limite, test basati su proprietà tramite proptest con centinaia di scenari generati e verifica MIRI per un funzionamento senza panico e senza UB. Gli input peggiori sono testati per garantire terminazione limitata.
cargo test
cargo +nightly miri test --lib
L'evaluator di Gate0 utilizza buffer di dimensione fissa allocati sullo stack per garantire zero allocazioni heap durante la valutazione. L'implementazione predefinita usa MaybeUninit per evitare di inizializzare slot inutilizzati, risultando in un costo di inizializzazione O(usato) anziché O(capacità).
Il codice unsafe è confinato in un singolo modulo (fixed_stack.rs) con invarianti semplici: gli elementi 0..len sono inizializzati, gli elementi len..N no. Tutti i percorsi unsafe sono verificati con MIRI.
Per gli utenti che preferiscono codice zero unsafe, Gate0 fornisce SafeFixedStack dietro il flag di feature safe-stack. Questa variante usa [T; N] con T: Default + Copy e inizializza tutti gli slot in anticipo. Il compromesso è un'inizializzazione O(capacità) ad ogni chiamata di valutazione.
cargo build --features safe-stack
Entrambe le implementazioni forniscono semantica identica e la stessa garanzia di zero allocazioni durante la valutazione. La scelta è tra prestazioni (O(usato)) e sicurezza assoluta (O(capacità)). Per stack piccoli con tipi Default economici come bool, la differenza è trascurabile.
Gate0 è progettato per funzionare come Policy Decision Point (PDP) all'interno di un'applicazione host più grande. Per mantenere determinismo e limiti rigorosi, Gate0 non gestisce I/O, rete o cicli di vita degli oggetti.
Il modello di integrazione raccomandato separa le responsabilità in tre livelli. L'applicazione host (API gateway, server SSH, ecc.) gestisce stato, identità ed effetti collaterali. Un livello adapter normalizza questo stato complesso in primitive che Gate0 comprende (stringhe, booleani, interi). Gate0 valuta il contesto appiattito in modo puro e restituisce una Decisione.
Host Application (User Request)
│
▼
[Adapter Layer] → Pre-calcola il contesto (tempo, intervalli IP, stato MFA)
│ Converte "complesso" in "primitivo"
▼
[Gate0 Engine] → Valutazione pura (0 allocazioni, stack limitato)
│
▼
Decision::Allow / Deny
Questa separazione spiega perché Gate0 non include matcher complessi come controlli di intervallo IP o regex. Il livello adapter gestisce la logica specifica del dominio e presenta a Gate0 attributi booleani o stringa precalcolati. Gate0 rimane piccolo, verificabile e deterministico.
use gate0::{Policy, Rule, Target, Request, ReasonCode};
let policy = Policy::builder()
.rule(Rule::allow(Target::any(), ReasonCode(1)))
.build()?;
let decision = policy.evaluate(&Request::new("alice", "read", "doc"))?;
assert!(decision.is_allow());
La directory examples/ contiene scenari illustrativi che dimostrano i pattern di utilizzo comuni di Gate0:
SaaS API: Logica standard RBAC/Multi-tenancy. Zero Trust Network: Controllo degli accessi basato su attributi (ABAC) con MFA e verifica della posizione. Complex Overrides: Dimostrazione della risoluzione dei conflitti Deny-Overrides.
Eseguili con:
cargo run --example saas_api
cargo run --example zero_trust_network
cargo run --example complex_overrides
Gate0 è intenzionalmente limitato per rimanere prevedibile e performante.
Niente Matcher Complessi: Logica come CIDR a maschera di bit completa o Regex avanzata rimane responsabilità del livello adapter. Gate0 valuta primitive pre-elaborate.
Niente Multithreading Nativo: L'attuale implementazione FFI per Python non è thread-safe. Gli utenti con alta concorrenza dovrebbero usare multiprocessing o attendere la stabilizzazione FFI della Fase 4 che affronterà i lock globali.
Niente Decisioni Sovrapposte: All'interno di una singola classe di effetto (Allow/Deny), viene restituita solo la prima regola corrispondente. La risoluzione dei conflitti è strettamente dipendente dall'ordine.
I seguenti progetti estendono il motore Gate0 per casi d'uso specializzati.
gate0_dsl: Un Domain Specific Language nativo Rust per Gate0 sviluppato da hardliner66. Sfrutta le macro di Rust per fornire una sintassi chiara e leggibile per definire policy direttamente nel codice. Puoi trovare l'implementazione e la documentazione su hardliner66/gate0_dsl.
MIT