Configuração

O plano de controlo e um único binário Go, olivares, configurado por um pequeno conjunto de flags no seu subcomando serve e um punhado de variaveis de ambiente — não um ficheiro de configuração extenso. Os valores predefinidos são escolhidos para falhar fechado: binds loopback, TLS ativo, sem credenciais distribuídas. Tudo abaixo e retirado das próprias definições de comando e raiz de composição do binário; onde uma definição não pode ser confirmada no código-fonte, não esta listada aqui.

Segredos que ligam fontes reais e custodiam chaves reais permanecem em ficheiros detidos pelo operador ou segredos montados referenciados por variavel de ambiente — nunca no armazém. Para o caminho executavel de ponta a ponta, veja o guia de auto-hospedagem; para a listagem completa de flags, veja a referência CLI.

O subcomando serve

olivares serve executa o servidor HTTP REST/web e o servidor gRPC num único processo, com a consola web servida na mesma origem que a API. Estes são os inputs de configuração comuns.

TLS esta ativo por defeito. Sem --tls-cert/--tls-key fornecidos, o motor garante um certificado auto-assinado no diretório de dados uma vez, antecipadamente, antes de qualquer listener aceitar uma conexão — portanto tanto os servidores HTTP como gRPC usam o mesmo certificado e nenhum recua para texto simples. Quando gera esse certificado regista a impressão digital SHA-256 para que os clientes possam confiar nele ou fixa-lo.

--insecure e a única forma de servir texto simples, e o caminho gRPC falha fechado: fora de --insecure o servidor recusa construir um listener em texto simples em vez de degradar silenciosamente. Use-o apenas contra 127.0.0.1 durante desenvolvimento local.

--seed-demo provisiona um administrador de demonstração com uma palavra-passe pública na árvore de código e dados de ambiente fabricados — apenas para demos e E2E. O motor recusa-se a arranca-lo se qualquer listener for não-loopback. Use um diretório de dados descartavel.

Um segundo nível de flags governa topologias distribuídas e de TLS mutuo — --admin-dsn e --allow-privileged-db-role (Postgres), --grpc-client-ca (TLS mutuo de coletor), e --region/--known-regions (residência de dados). Estes são cobertos abaixo e listados na integra na referência CLI.

Variaveis de ambiente

O motor le um pequeno número de variaveis de ambiente no arranque. As abaixo são confirmadas na raiz de composição e ligação.

Diretório de dados e fontes

OLIVARES_SOURCES_CONFIG e o único input através do qual fontes de sinal não-demo e fornecedores de roster são resolvidos. E a configuração com segredos do operador e e deliberadamente mantida fora do armazém. O motor le-a no arranque e regista cada fonte antes do runtime arrancar.

O tratamento e honesto em vez de fail-fast. Uma variavel em falta, um ficheiro ilegível ou JSON invalido, ou uma lista de fontes configurada-mas-vazia todos avisam e produzem uma configuração vazia — o motor nunca aborta o arranque. Uma fonte não configurada mostra um aviso em vez de crashar o plano ou fingir que funciona: sem nada ligado, o mapa de acesso simplesmente fica vazio. Para o popular, configure pelo menos uma fonte — veja ligar uma fonte e, para o caminho cooperativo Claude Code, ligar Claude Code.

Ponto de decisão de autorização

O controlo de acesso nativo baseado em atributos e papeis sempre governa. Um ponto de decisão de políticas externo (PDP), quando selecionado, e uma camada adicional apenas de restrição que só pode estreitar a decisão que RBAC incorporado já tomou — nunca amplia-la.

Dois adaptadores residem atrás de um ponto — um avaliador Cedar embebido (o caminho Go puro) e um adaptador OPA-via-HTTP. Se OLIVARES_PDP_ENGINE seleciona um motor mas a sua config e invalida (um ficheiro Cedar ilegível, um alvo OPA malformado), o motor desativa apenas o PDP externo, mantém o motor ABAC nativo e RBAC a aplicar, e regista em voz alta. Um ficheiro de políticas quebrado nunca deixa pedidos sem governança e nunca crasha o plano. Para o modelo deny-by-default, veja governança.

Chave de assinatura de auditoria

O registo de auditoria e apenas adicao, encadeado por hash e ancorado por pontos de verificação assinados com Ed25519. A chave de assinatura por evento e resolvida no arranque, fail-closed para cada fonte custodiada.

Sem nenhuma destas definida, a chave e cunhada no primeiro arranque no diretório de dados — o fallback honesto de no único / desenvolvimento. Partilhar uma chave entre replicas (via o valor env ou um segredo montado) e necessário para alta disponibilidade: caso contrário cada no cunha a sua e o registo bifurca-se no failover. A assinatura por evento permanece sempre on-box. A custódia encapsulada por KMS (chave gerida pelo cliente) e uma postura adicional configurada através de OLIVARES_KEY_WRAP; veja a referência CLI.

Seleção de armazém

O motor seleciona o seu armazém a partir de --engine.

SQLite e o predefinido e não precisa de serviço externo — e o armazém compatível com air-gap, sem dependências para a topologia de no único, e o que a implantação Docker Compose de um comando executa. Mude para Postgres quando precisar de isolamento multi-inquilino ou escala horizontal, não antes.

Escolher postgres opta pelo backstop de segurança ao nível de linha que isola inquilinos. O motor recusa arrancar contra um superutilizador Postgres ou papel BYPASSRLS — o que desativaria esse backstop — a menos que --allow-privileged-db-role explicitamente sobreponha a guarda (apenas inquilino único / descartavel). Para leituras cross-inquilino completas de Sistema (listagem de organizações, cobertura de pontos de verificação multi-inquilino) forneca um papel admin dedicado NOSUPERUSER BYPASSRLS via --admin-dsn; sem ele essas leituras funcionam limitadas por RLS e podem retornar vazio. OLIVARES_DB_MAX_CONNS limita o pool de aplicação por no.

Multi-inquilino e residência

Uma única instancia e multi-inquilino por construção em Postgres, com segurança ao nível de linha isolando os dados de cada inquilino. A residência de dados e sobreposta por --region.

• Região única (predefinido, sem --region): sem aplicação de residência.
• Com escopo de região (--region eu, --region us, …): a instancia serve apenas inquilinos fixados a sua região de origem e nega acesso cross-região fail-closed. --known-regions lista os códigos de região válidos em toda a implantação; a fixacao de um inquilino deve ser um deles, e uma config de região malformada falha o arranque antes do armazém abrir.

Pontos de verificação de auditoria

--checkpoint-interval controla a frequência de escrita de um ponto de verificação assinado sobre cada cadeia de inquilino (predefinido 1h; 0 desativa). Um ponto de verificação final e escrito no encerramento limpo antes do armazém fechar, portanto a cadeia e ancorada no encerramento assim como no intervalo. Veja verificar uma versão para como a cadeia assinada e verificada a jusante.

Valores seguros por defeito

Estas posturas estão em vigor sem nenhuma configuração além de serve. São a postura predefinida do produto, não endurecimento opcional.

Os binds loopback significam que o motor não é alcançável fora do host até que os mude. Quando o pública — digamos mapeando uma porta do host em Docker Compose — TLS já esta ativo para o proteger; não emparelhe um bind publicado com --insecure. Numa instalação nova o motor imprime um bloco FIRST-BOOT SETUP para a saída padrão com o token de configuração único (leia dos registos do contentor sob Compose); o administrador usa-o para criar o primeiro utilizador, depois autentica-se.

Para o que o produto observa, onde governa e onde a cobertura e escalonada, leia honestidade e limites.