qarait/gate0Um pequeno motor de micropolíticas auditável, terminante e determinístico
Um pequeno motor de micropolítica auditável, com término garantido e determinístico.
Construí o Gate0 porque estava cansado de depurar políticas baseadas em RegEx em produção. Queria algo que fosse chato, limitado e impossível de travar. Se você quer um mecanismo de políticas flexível e de propósito geral, deve usar OPA. Se você quer um mecanismo de políticas que faça benchmark com avaliação abaixo de 50µs e zero alocações para caminhos críticos de segurança, você quer o Gate0.
O Gate0 é projetado para ambientes de alta confiança onde a avaliação de políticas deve ser determinística e limitada em recursos. Consulte a Política de Segurança para relatar vulnerabilidades e o Modelo de Segurança para o modelo de ameaça completo e garantias mecânicas.
O Gate0 usa uma estratégia de avaliação linear, Deny-Overrides (sobreposição de negação). Cada regra consiste em um Target (alvo de caminho rápido) e uma Condition (lógica profunda) opcional.
+----------+ +-------------+ +--------+
| Ephemera | ----> | GateBridge | ----> | Gate0 |
| (Legacy) | | (Normalize) | | (Core) |
+----------+ +-------------+ +--------+
| ^
| |
+----(Shadow Log)----+
A correção e a segurança do Gate0 são verificadas mecanicamente por meio de testes de unidade que cobrem a lógica central e casos extremos, testes baseados em propriedades via proptest com centenas de cenários gerados e verificação MIRI para operação livre de pânico e livre de UB (comportamento indefinido). Entradas de pior caso são testadas para garantir término limitado.
cargo test
cargo +nightly miri test --lib
O avaliador do Gate0 usa buffers de tamanho fixo alocados na pilha para garantir zero alocações na heap durante a avaliação. A implementação padrão usa MaybeUninit para evitar a inicialização de slots não utilizados, resultando em custo de inicialização O(usado) em vez de O(capacidade).
O código inseguro (unsafe) está confinado a um único módulo (fixed_stack.rs) com invariantes diretas: os elementos 0..len estão inicializados, os elementos len..N não estão. Todos os caminhos unsafe são verificados com MIRI.
Para usuários que preferem código zero unsafe, o Gate0 fornece SafeFixedStack por trás da flag de recurso safe-stack. Esta variante usa [T; N] com T: Default + Copy e inicializa todos os slots antecipadamente. A compensação é a inicialização O(capacidade) em cada chamada de avaliação.
cargo build --features safe-stack
Ambas as implementações fornecem semântica idêntica e a mesma garantia de zero alocação durante a avaliação. A escolha é entre desempenho (O(usado)) e segurança absoluta (O(capacidade)). Para pilhas pequenas com tipos Default baratos como bool, a diferença é insignificante.
O Gate0 é projetado para funcionar como um Ponto de Decisão de Política (PDP) dentro de uma aplicação hospedeira maior. Para manter o determinismo e limites estritos, o Gate0 não lida com E/S, rede ou ciclos de vida de objetos.
O padrão de integração recomendado separa responsabilidades em três camadas. A aplicação hospedeira (gateway de API, servidor SSH, etc.) gerencia estado, identidade e efeitos colaterais. Uma camada adaptadora normaliza esse estado complexo em primitivas que o Gate0 entende (strings, bools, ints). O Gate0 avalia o contexto achatado de forma pura e retorna uma Decisão.
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
Essa separação explica por que o Gate0 não inclui correspondentes complexos como verificações de intervalo de IP ou regex. A camada adaptadora lida com a lógica específica do domínio e apresenta ao Gate0 atributos booleanos ou de string pré-calculados. O Gate0 permanece pequeno, auditável e determinístico.
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());
O diretório examples/ contém cenários ilustrativos que demonstram padrões comuns de uso do Gate0:
SaaS API: Lógica padrão de RBAC/Multi-inquilinos. Zero Trust Network: Controle de Acesso Baseado em Atributos (ABAC) com MFA e verificações de localização. Complex Overrides: Demonstração da resolução de conflitos Deny-Overrides.
Execute-os com:
cargo run --example saas_api
cargo run --example zero_trust_network
cargo run --example complex_overrides
O Gate0 é intencionalmente limitado para permanecer previsível e eficiente.
Sem Correspondentes Complexos: Lógica como CIDR de máscara de bits completa ou Regex avançado permanece responsabilidade da camada adaptadora. O Gate0 avalia primitivas pré-processadas.
Sem Multithreading Nativo: A implementação FFI atual para Python não é thread-safe. Usuários de alta concorrência devem usar multiprocessamento ou esperar pela estabilização da FFI Fase 4, que abordará as travas globais.
Sem Decisões Sobrepostas: Dentro de uma única classe de efeito (Allow/Deny), apenas a primeira regra correspondente é retornada. A resolução de conflitos é estritamente dependente da ordem.
Os seguintes projetos estendem o mecanismo Gate0 para casos de uso especializados.
gate0_dsl: Uma Linguagem de Domínio Específico nativa em Rust para o Gate0 desenvolvida por hardliner66. Ela aproveita as macros do Rust para fornecer uma sintaxe limpa e legível para definir políticas diretamente no código. Você pode encontrar a implementação e a documentação em hardliner66/gate0_dsl.
MIT