Configuratie

Het control plane is één Go binary, olivares, geconfigureerd door een kleine set vlaggen op zijn serve-subcommando en een handvol omgevingsvariabelen — geen uitgebreid configuratiebestand. De standaarden zijn gekozen om fail-closed te zijn: loopback-binds, TLS aan, geen meegeleverde credentials. Alles hieronder is overgenomen van de eigen commando- definities en compositiewortel van de binary; waar een instelling niet bevestigd kan worden in de broncode, staat het hier niet vermeld.

Geheimen die echte bronnen aansluiten en echte sleutels bewaren blijven in operatorbestanden of gemounte secrets gerefereerd door omgevingsvariabele — nooit in de opslag. Voor het uitvoerbare end-to-end pad, zie de zelfhostgids; voor de volledige vlaggenlijst, zie de CLI-referentie.

Het serve-subcommando

olivares serve draait de REST/web HTTP-server en de gRPC-server in één proces, met de webconsole geserveerd vanuit dezelfde origin als de API. Dit zijn de gebruikelijke configuratie-inputs.

TLS is standaard aan. Zonder meegeleverd --tls-cert/--tls-key zorgt de engine voor een zelfondertekend certificaat in de datadirectory eenmalig, vooraf, voordat enige listener een verbinding accepteert — zodat zowel de HTTP- als gRPC-servers hetzelfde certificaat gebruiken en geen van beide terugvalt naar plaintext. Wanneer het dat certificaat genereert logt het de SHA-256-vingerafdruk zodat clients het kunnen vertrouwen of pinnen.

--insecure is de enige manier om plaintext te serveren, en het gRPC-pad faalt closed: buiten --insecure weigert de server een plaintext-listener te construeren in plaats van stilzwijgend te degraderen. Gebruik het alleen tegen 127.0.0.1 tijdens lokale ontwikkeling.

--seed-demo richt een demo-administrator in met een publiek, broncode-wachtwoord en verzonnen domeindata — alleen voor demo’s en E2E. De engine weigert het te starten als een van beide listeners niet-loopback is. Gebruik een wegwerp-datadirectory.

Een tweede laag vlaggen bestuurt gedistribueerde en wederzijdse-TLS-topologieën — --admin-dsn en --allow-privileged-db-role (Postgres), --grpc-client-ca (collector wederzijdse TLS), en --region/--known-regions (dataresidentie). Deze worden hieronder behandeld en volledig opgesomd in de CLI-referentie.

Omgevingsvariabelen

De engine leest een klein aantal omgevingsvariabelen bij opstart. De onderstaande zijn bevestigd in de compositiewortel en bedrading.

Datadirectory en bronnen

OLIVARES_SOURCES_CONFIG is de enkele input waarmee niet-demo signaalbronnen en rosterproviders worden opgelost. Het is de geheimendragende configuratie van de operator en wordt bewust buiten de opslag gehouden. De engine leest het bij opstart en registreert elke bron voordat de runtime start.

De afhandeling is eerlijk in plaats van fail-fast. Een ontbrekende variabele, een onleesbaar of ongeldig-JSON-bestand, of een geconfigureerde-maar-lege bronlijst waarschuwen allemaal en leveren een lege configuratie — de engine breekt de opstart nooit af. Een niet-geconfigureerde bron toont een waarschuwing in plaats van het plane te laten crashen of te doen alsof het werkt: zonder iets aangesloten blijft de toegangskaart simpelweg leeg. Om het te vullen, configureer minimaal één bron — zie een bron aansluiten en, voor het coöperatieve Claude Code pad, Claude Code aansluiten.

Autorisatiebeslissingspunt

De native op attributen gebaseerde en op rollen gebaseerde toegangscontrole besturen altijd. Een extern beleidsbeslissingspunt (PDP), wanneer geselecteerd, is een extra alleen-beperkende laag die alleen de beslissing kan vernauwen die de ingebouwde RBAC al heeft genomen — nooit verbreden.

Twee adapters zitten achter één naad — een ingebouwde Cedar-evaluator (het pure-Go pad) en een OPA-via-HTTP-adapter. Als OLIVARES_PDP_ENGINE een engine selecteert maar de configuratie ongeldig is (een onleesbaar Cedar-bestand, een verkeerd gevormd OPA-doel), schakelt de engine alleen het externe PDP uit, houdt de native ABAC-engine en RBAC handhavend, en logt luid. Een defect beleidsbestand laat verzoeken nooit onbestuurd en laat het plane nooit crashen. Zie bestuur voor het deny-by-default-model.

Audit-ondertekeningssleutel

Het auditlogboek is append-only, hash-chained en verankerd door Ed25519-ondertekende checkpoints. De per-event-ondertekeningssleutel wordt bij opstart opgelost, fail-closed voor elke bewaarde bron.

Zonder een van deze ingesteld, wordt de sleutel bij eerste opstart aangemaakt in de datadirectory — de eerlijke single-node / ontwikkel-fallback. Het delen van één sleutel over replica’s (via de env-waarde of een gemount secret) is vereist voor hoge beschikbaarheid: anders genereert elk node zijn eigen en forkt het logboek bij failover. Per-event-ondertekening blijft altijd on-box. KMS-gewrapte (customer-managed-key) bewaring is een extra houding geconfigureerd via OLIVARES_KEY_WRAP; zie de CLI-referentie.

Opslagselectie

De engine selecteert zijn opslag via --engine.

SQLite is de standaard en heeft geen externe service nodig — het is de air-gap-klare, nul-afhankelijkheden-opslag voor de single-node-topologie, en degene die de one-command Docker Compose-deployment draait. Stap over naar Postgres wanneer je multi-tenant-isolatie nodig hebt of horizontale schaal, niet eerder.

Het kiezen van postgres opt-int in de row-level-security-backstop die tenants isoleert. De engine weigert te starten tegen een Postgres-superuser of BYPASSRLS-rol — wat die backstop zou uitschakelen — tenzij --allow-privileged-db-role expliciet de bewaking overschrijft (alleen single-tenant / wegwerp). Voor volledige cross-tenant systeem- lezingen (organisatielijst, multi-tenant-checkpointdekking) lever een toegewijd NOSUPERUSER BYPASSRLS admin-rol via --admin-dsn; zonder die draaien die lezingen RLS-beperkt en kunnen leeg retourneren. OLIVARES_DB_MAX_CONNS begrenst de per-node applicatiepool.

Tenancy en residency

Een enkele instantie is multi-tenant by construction op Postgres, met row-level security die de data van elke tenant isoleert. Dataresidency wordt er bovenop gelaagd via --region.

• Single-region (standaard, geen --region): geen residencyhandhaving.
• Region-afgebakend (--region eu, --region us, …): de instantie bedient alleen tenants vastgezet op zijn thuisregio en weigert cross-region-toegang fail-closed. --known-regions somt de regiocodes op die geldig zijn over de hele deployment; de pin van een tenant moet er een van zijn, en een verkeerde regioconfiguratie faalt de opstart voordat de opslag opent.

Audit-checkpoints

--checkpoint-interval bepaalt hoe vaak een ondertekend checkpoint wordt geschreven over elke tenantketen (standaard 1h; 0 schakelt uit). Een laatste checkpoint wordt geschreven bij schone afsluiting voordat de opslag sluit, zodat de keten verankerd is bij afsluiting net als op het interval. Zie een release verifiëren voor hoe de ondertekende keten downstream wordt geverifieerd.

Veilige standaarden

Deze houdingen zijn van kracht zonder configuratie buiten serve. Ze zijn de standaardhouding van het product, geen optionele verharding.

De loopback-binds betekenen dat de engine niet off-host bereikbaar is totdat je ze wijzigt. Wanneer je het publiceert — bijvoorbeeld door een hostpoort in Docker Compose te mappen — is TLS al aan om het te beschermen; combineer een gepubliceerde bind niet met --insecure. Op een verse installatie print de engine een FIRST-BOOT SETUP-blok naar standaarduitvoer met het eenmalige setup- token (lees uit de containerlogs onder Compose); de administrator gebruikt het om de eerste gebruiker aan te maken en authenticeert vervolgens.

Voor wat het product observeert, waar het bestuurt, en waar dekking gelaagd is, lees eerlijkheid en beperkingen.