
Un motor de micropolíticas pequeño, auditable, terminante y determinista.
Un pequeño motor de micropolíticas auditable, terminante, determinista.
Construí Gate0 porque estaba harto de depurar políticas basadas en RegEx en producción. Quería algo que fuera aburrido, acotado e imposible de bloquear. Si necesitas un motor de políticas flexible y de propósito general, deberías usar OPA. Si quieres un motor de políticas que evalúe en menos de 50 µs y con cero asignaciones en rutas críticas de seguridad, quieres Gate0.
Gate0 está diseñado para entornos de alta confianza donde la evaluación de políticas debe ser determinista y con recursos acotados. Consulta la Política de Seguridad para informar vulnerabilidades y el Modelo de Seguridad para conocer el modelo de amenazas completo y las garantías mecánicas.
Gate0 utiliza una estrategia de evaluación lineal de Deny-Overrides (denegación por defecto). Cada regla consiste en un Objetivo (coincidencia de ruta rápida) y una Condición opcional (lógica profunda).
+----------+ +-------------+ +--------+
| Ephemera | ----> | GateBridge | ----> | Gate0 |
| (Legacy) | | (Normalize) | | (Core) |
+----------+ +-------------+ +--------+
| ^
| |
+----(Shadow Log)----+
La corrección y seguridad de Gate0 se verifican mecánicamente mediante pruebas unitarias que cubren la lógica central y casos extremos, pruebas basadas en propiedades a través de proptest con cientos de escenarios generados, y verificación MIRI para operaciones libres de pánico y de comportamiento indefinido. Las entradas de peor caso se prueban para garantizar una terminación acotada.
cargo test
cargo +nightly miri test --lib
El evaluador de Gate0 utiliza buffers de tamaño fijo asignados en la pila para garantizar cero asignaciones en el montón durante la evaluación. La implementación por defecto utiliza MaybeUninit para evitar inicializar ranuras no utilizadas, lo que resulta en un costo de inicialización O(usado) en lugar de O(capacidad).
El código inseguro está confinado a un solo módulo (fixed_stack.rs) con invariantes simples: los elementos de 0 a len están inicializados, los de len a N no lo están. Todos los caminos inseguros se verifican con MIRI.
Para usuarios que prefieren cero código inseguro, Gate0 proporciona SafeFixedStack detrás del indicador de característica safe-stack. Esta variante utiliza [T; N] con T: Default + Copy e inicializa todas las ranuras de antemano. La compensación es una inicialización O(capacidad) en cada llamada de evaluación.
cargo build --features safe-stack
Ambas implementaciones proporcionan la misma semántica y la misma garantía de cero asignaciones durante la evaluación. La elección es entre rendimiento (O(usado)) y seguridad absoluta (O(capacidad)). Para pilas pequeñas con tipos Default baratos como bool, la diferencia es insignificante.
Gate0 está diseñado para funcionar como un Punto de Decisión de Políticas (PDP) dentro de una aplicación anfitriona más grande. Para mantener el determinismo y los límites estrictos, Gate0 no maneja E/S, redes ni ciclos de vida de objetos.
El patrón de integración recomendado separa las responsabilidades en tres capas. La aplicación anfitriona (puerta de enlace API, servidor SSH, etc.) gestiona el estado, la identidad y los efectos secundarios. Una capa adaptadora normaliza este estado complejo en primitivas que Gate0 entiende (cadenas, booleanos, enteros). Gate0 evalúa el contexto aplanado de forma pura y devuelve una Decisión.
Host Application (User Request)
│
▼
[Adapter Layer] → Pre-computes context (time, IP ranges, MFA status)
│ Converts "complex" to "primitive"
▼
[Gate0 Engine] → Pure evaluation (0 allocations, bounded stack)
│
▼
Decision::Allow / Deny
Esta separación explica por qué Gate0 no incluye comparadores complejos como verificación de rangos IP o expresiones regulares. La capa adaptadora maneja la lógica específica del dominio y presenta a Gate0 atributos booleanos o de cadena precalculados. Gate0 se mantiene pequeño, auditable y determinista.
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());
El directorio examples/ contiene escenarios ilustrativos que demuestran patrones de uso comunes de Gate0:
SaaS API: Lógica estándar de RBAC/multi-inquilino. Red de Confianza Cero: Control de Acceso Basado en Atributos (ABAC) con MFA y verificación de ubicación. Anulaciones Complejas: Demostración de la resolución de conflictos Deny-Overrides.
Ejecútalos con:
cargo run --example saas_api
cargo run --example zero_trust_network
cargo run --example complex_overrides
Gate0 está intencionalmente limitado para mantenerse predecible y eficiente.
Sin comparadores complejos: Lógica como CIDR de máscara de bits completa o expresiones regulares avanzadas sigue siendo responsabilidad de la capa adaptadora. Gate0 evalúa primitivas preprocesadas.
Sin subprocesamiento múltiple nativo: La implementación FFI actual para Python no es segura para subprocesos. Los usuarios de alta concurrencia deberían usar multiprocesamiento o esperar la estabilización de la Fase 4 de FFI, que abordará los bloqueos globales.
Sin decisiones superpuestas: Dentro de una sola clase de efecto (Permitir/Denegar), solo se devuelve la primera regla que coincida. La resolución de conflictos es estrictamente dependiente del orden.
Los siguientes proyectos extienden el motor Gate0 para casos de uso especializados.
gate0_dsl: Un Lenguaje Específico del Dominio (DSL) nativo de Rust para Gate0, desarrollado por hardliner66. Aprovecha las macros de Rust para proporcionar una sintaxis limpia y legible para definir políticas directamente en código. Puedes encontrar la implementación y la documentación en hardliner66/gate0_dsl.
MIT