Configuration

Le plan de contrôle est un seul binaire Go, olivares, configuré par un petit ensemble de flags sur sa sous-commande serve et une poignée de variables d’environnement — pas un fichier de configuration tentaculaire. Les défauts sont choisis pour échouer en fermé : liaisons loopback, TLS activé, aucun identifiant livré. Tout ce qui suit est tiré des propres définitions de commande et de la racine de composition du binaire ; là où un paramètre ne peut pas être confirmé dans le source, il n’est pas listé ici.

Les secrets qui câblent des sources réelles et gardent de vraies clés restent dans des fichiers détenus par l’opérateur ou des secrets montés référencés par variable d’environnement — jamais dans le store. Pour le chemin exécutable de bout en bout, voir le guide d’auto-hébergement ; pour la liste complète des flags, voir la référence CLI.

La sous-commande serve

olivares serve lance le serveur HTTP REST/web et le serveur gRPC dans un seul processus, avec la console web servie depuis la même origine que l’API. Voici les entrées de configuration courantes.

TLS est activé par défaut. Sans --tls-cert/--tls-key fournis, le moteur génère un certificat auto-signé dans le répertoire de données une seule fois, en amont, avant que tout écouteur n’accepte de connexion — de sorte que les serveurs HTTP et gRPC utilisent le même certificat et qu’aucun ne bascule en texte clair. Quand il génère ce certificat, il journalise l’empreinte SHA-256 pour que les clients puissent lui faire confiance ou l’épingler.

--insecure est la seule manière de servir en texte clair, et le chemin gRPC échoue en fermé : hors --insecure, le serveur refuse de construire un écouteur texte clair plutôt que de dégrader silencieusement. Utilisez-le uniquement contre 127.0.0.1 en développement local.

--seed-demo provisionne un administrateur de démonstration avec un mot de passe public de l’arborescence source et des données d’environnement fabriquées — pour les démos et l’E2E uniquement. Le moteur refuse de le démarrer si l’un des écouteurs est non-loopback. Utilisez un répertoire de données éphémère.

Un deuxième niveau de flags gouverne les topologies distribuées et mutual-TLS — --admin-dsn et --allow-privileged-db-role (Postgres), --grpc-client-ca (mutual TLS collecteur), et --region/--known-regions (résidence des données). Ils sont couverts ci-dessous et listés en intégralité dans la référence CLI.

Variables d’environnement

Le moteur lit un petit nombre de variables d’environnement au démarrage. Celles ci-dessous sont confirmées dans la racine de composition et le câblage.

Répertoire de données et sources

OLIVARES_SOURCES_CONFIG est l’entrée unique à travers laquelle les sources de signal et fournisseurs de roster non-démo sont résolus. C’est la configuration de l’opérateur portant les secrets et est délibérément gardée hors du store. Le moteur la lit au démarrage et enregistre chaque source avant que le runtime ne démarre.

Le traitement est honnête plutôt que fail-fast. Une variable manquante, un fichier illisible ou de JSON invalide, ou une liste de sources configurée mais vide préviennent et produisent une configuration vide — le moteur n’interrompt jamais le démarrage. Une source non configurée fait remonter un avertissement au lieu de planter le plan ou de prétendre fonctionner : sans rien de câblé, la carte d’accès reste simplement vide. Pour la peupler, configurez au moins une source — voir connecter une source et, pour le chemin coopératif Claude Code, connecter Claude Code.

Point de décision d’autorisation

Le contrôle d’accès natif basé sur les attributs et les rôles gouverne toujours. Un point de décision de politique externe (PDP), quand sélectionné, est une couche additionnelle de restriction uniquement qui ne peut que restreindre la décision que le RBAC intégré a déjà prise — jamais l’élargir.

Deux adaptateurs se trouvent derrière un seul point d’accès — un évaluateur Cedar embarqué (le chemin pure-Go) et un adaptateur OPA-via-HTTP. Si OLIVARES_PDP_ENGINE sélectionne un moteur mais que sa config est invalide (un fichier Cedar illisible, une cible OPA malformée), le moteur ne désactive que le PDP externe, garde le moteur ABAC natif et le RBAC en application, et journalise bruyamment. Un fichier de politique cassé ne laisse jamais les requêtes non gouvernées et ne plante jamais le plan. Pour le modèle fermé par défaut, voir gouvernance.

Clé de signature d’audit

Le registre d’audit est append-only, chaîné par hash, et ancré par des checkpoints signés Ed25519. La clé de signature par événement est résolue au démarrage, fermée en échec pour chaque source gardée.

Sans aucune de ces variables définie, la clé est générée au premier démarrage dans le répertoire de données — le repli honnête nœud unique / développement. Partager une clé entre réplicas (via la valeur env ou un secret monté) est requis pour la haute disponibilité : sinon chaque nœud génère la sienne et le registre se bifurque au basculement. La signature par événement reste toujours on-box. La garde par clé KMS (clé gérée par le client) est une posture additionnelle configurée via OLIVARES_KEY_WRAP ; voir la référence CLI.

Sélection du store

Le moteur sélectionne son store depuis --engine.

SQLite est le défaut et n’a besoin d’aucun service externe — c’est le store air-gap-ready, zéro dépendance pour la topologie nœud unique, et celui que le déploiement Docker Compose en une commande exécute. Passez à Postgres quand vous avez besoin d’isolation multi-tenant ou d’échelle horizontale, pas avant.

Choisir postgres opte pour le backstop de sécurité au niveau des lignes qui isole les tenants. Le moteur refuse de démarrer contre un superutilisateur Postgres ou un rôle BYPASSRLS — ce qui désactiverait ce backstop — sauf si --allow-privileged-db-role surcharge explicitement la garde (mono-tenant / jetable uniquement). Pour les lectures System véritablement cross-tenant (liste des orgs, couverture des checkpoints multi-tenants), fournissez un rôle admin dédié NOSUPERUSER BYPASSRLS via --admin-dsn ; sans cela, ces lectures s’exécutent limitées par RLS et peuvent retourner vide. OLIVARES_DB_MAX_CONNS borne le pool applicatif par nœud.

Multi-tenancy et résidence

Une instance unique est multi-tenant par construction sur Postgres, avec la sécurité au niveau des lignes isolant les données de chaque tenant. La résidence des données se superpose via --region.

• Région unique (défaut, pas de --region) : pas d’application de résidence.
• Scopé par région (--region eu, --region us, …) : l’instance ne sert que les tenants épinglés à sa région d’origine et refuse l’accès cross-région en fermé. --known-regions liste les codes de région valides à travers tout le déploiement ; l’épingle d’un tenant doit être l’un d’eux, et une config de région malformée échoue le démarrage avant que le store ne s’ouvre.

Checkpoints d’audit

--checkpoint-interval contrôle la fréquence d’écriture d’un checkpoint signé sur chaque chaîne de tenant (défaut 1h ; 0 désactive). Un checkpoint final est écrit à l’arrêt propre avant que le store ne se ferme, de sorte que la chaîne est ancrée à l’arrêt comme sur l’intervalle. Voir vérifier une release pour comment la chaîne signée est vérifiée en aval.

Défauts sécurisés

Ces postures sont en vigueur sans aucune configuration au-delà de serve. Elles sont la position par défaut du produit, pas un durcissement optionnel.

Les liaisons loopback signifient que le moteur n’est pas accessible hors-hôte tant que vous ne les changez pas. Quand vous le publiez — par exemple en mappant un port hôte dans Docker Compose — TLS est déjà activé pour le protéger ; ne combinez pas une liaison publiée avec --insecure. Sur une installation neuve, le moteur affiche un bloc FIRST-BOOT SETUP sur la sortie standard avec le token de configuration à usage unique (lisible depuis les logs du conteneur sous Compose) ; l’administrateur l’utilise pour créer le premier utilisateur, puis s’authentifie.

Pour ce que le produit observe, où il gouverne, et où la couverture est graduée, lisez transparence et limites.