Sécurité

Cette page décrit le modèle de sécurité de navin-manager. La référence contractuelle est la section 5 de navin-manager/CONTRACT.md.

Connexion

Source	Détails
Comptes locaux	Mots de passe hachés par scrypt (coût NM_SCRYPT_N, 32768 par défaut). Politique : longueur minimale (12), quatre classes de caractères, nom d'utilisateur interdit dans le mot de passe, historique des 5 derniers, âge maximal facultatif.
LDAP ou Active Directory	Liaison de service, recherche de l'utilisateur avec un filtre échappé, liaison de l'utilisateur, groupes par memberOf ou par une recherche de groupes, LDAPS ou StartTLS avec l'autorité de la banque. Les correspondances entre groupes et rôles s'appliquent à chaque connexion.
OIDC (Keycloak, Entra ID)	Code d'autorisation avec PKCE S256, state et nonce stockés hachés et à usage unique, jeton d'identité vérifié avec le JWKS (signature, émetteur, audience, expiration, nonce). La revendication des groupes donne les rôles. Les redirections ne visent qu'un chemin relatif de la console.

Le compte initial s'appelle navin, comme sur la plateforme. Il est créé au premier démarrage du serveur avec le mot de passe initial de NM_ADMIN_PASSWORD (/etc/navin-manager/server.env) : ce mot de passe ne sert qu'à la première connexion, la console demande alors un mot de passe personnel avant d'ouvrir une session, et un redémarrage ne le remet jamais. En installation locale (bac à sable), c'est navin / navin ; en production, navin-manager check refuse un mot de passe initial faible et le paquet en écrit un aléatoire. Mot de passe perdu : navin-manager reset-admin remet le mot de passe initial, à changer à la connexion suivante, ferme les sessions du compte et trace l'opération dans l'audit. D'autres administrateurs se créent depuis la page Utilisateurs ou avec navin-manager create-admin --username <nom> --password-stdin (mot de passe à changer à la première connexion).

Second facteur. TOTP (RFC 6238, 30 secondes, 6 chiffres, une période de tolérance, un code n'est jamais accepté deux fois) et 10 codes de secours à usage unique. La politique rend le second facteur obligatoire pour des rôles (par défaut admin et security_admin) : les utilisateurs concernés l'enrôlent à leur prochaine connexion.

Verrouillage et limitation. Après 5 échecs (réglage lockout_threshold), un compte est verrouillé 15 minutes (lockout_minutes). Les tentatives de connexion sont limitées par adresse et par nom d'utilisateur (HTTP 429 avec Retry-After). Un nom inconnu coûte le même temps qu'un nom connu.

Sessions et jetons

Les sessions sont conservées côté serveur. Le cookie nm_session est HttpOnly, Secure et SameSite=Strict. Une session se termine après 30 minutes d'inactivité ou 12 heures au total (session_idle_minutes, session_absolute_hours). Chaque requête de modification avec une session porte l'en-tête X-CSRF-Token. Un changement de mot de passe ferme les autres sessions de l'utilisateur.

Les jetons d'API (Authorization: Bearer nmt_<id>_<secret>) s'affichent une seule fois, sont stockés en sha256, expirent, se révoquent et peuvent être restreints à une partie des permissions de leur propriétaire. Utilisez-les pour l'automatisation et pour la découverte de services de Prometheus.

Rôles et permissions

Rôle	Portée	Droits principaux
admin	globale	tout
security_admin	globale	utilisateurs, authentification, audit, certificats
cluster_admin	globale ou un cluster	hôtes, installation et exploitation des services, configurations, alertes
operator	globale ou un cluster	démarrage, arrêt, redémarrage, commandes, journaux, alertes
viewer	globale ou un cluster	lecture seule
auditor	globale	journal d'audit et lecture seule

Un rôle attribué sur un seul cluster ne donne jamais les permissions globales (utilisateurs, authentification, réglages, connexions, création de cluster). Chaque refus est inscrit au journal d'audit.

Secrets

Chaque secret (mots de passe des services, secrets des fournisseurs d'identité, mots de passe des connexions, secrets des agents, clé de l'autorité, contenu des tâches qui transportent des fichiers de configuration) est scellé en AES-256-GCM avec la clé maître (/etc/navin-manager/master.key, 32 octets aléatoires, propriété de navin-manager, mode 0600, créée à l'installation du paquet ou par navin-manager init-key ; le serveur refuse une clé lisible par le groupe ou par les autres). L'API ne renvoie jamais un secret : elle affiche {"secret": true, "set": true}. Les aperçus de configuration, les différences entre versions et les résumés de tâches masquent les secrets. Gardez une copie de la clé maître dans le coffre de la banque : sans elle, les secrets stockés sont illisibles.

Coffre-fort et consoles des services

Le coffre-fort (page Administration, Coffre-fort, permission vault:manage) garde l'adresse, l'identifiant, le mot de passe et la clé de chaque service installé, scellés comme les autres secrets ; seul le nom est stocké en clair, et l'affichage d'un mot de passe (POST /api/v1/vault/entries/{id}/reveal) est journalisé.

• Chaque installation génère ses propres mots de passe et clés (paramètres du catalogue avec generate) : aucun mot de passe n'est partagé entre deux clusters ou deux clients, et aucun service ne garde un mot de passe par défaut.
• Après chaque installation ou application de configuration réussie, le Manager crée ou met à jour l'entrée du coffre-fort du service avec les valeurs appliquées (une mise à jour qui échoue est journalisée en vault.sync). POST /api/v1/vault/import met à jour les services installés avant.
• Un champ qu'un administrateur modifie à la main est conservé par la mise à jour suivante. L'identifiant, le mot de passe et la clé d'une console que le service relit dans sa configuration à chaque démarrage (statistiques HAProxy, LiteLLM, administration SeaweedFS, ClickHouse) ne changent que par Changer le mot de passe (POST /api/v1/clusters/{id}/consoles/{service}/credentials/rotate, configs:edit et vault:manage) : nouvelle version de configuration, opération d'application, puis le coffre-fort. Un mot de passe appliqué seulement au premier démarrage ou partagé avec d'autres services (Keycloak, OpenSearch) se change dans la console du service, puis s'enregistre dans le coffre-fort.

La page Consoles (services:operate, opérateurs et administrateurs) liste les interfaces web locales des services installés. Chaque console est contrôlée sur quatre exigences : HTTPS, un nom DNS interne (jamais localhost ni une adresse IP), une authentification (sa propre connexion, ou la passerelle authentifiée déclarée par un administrateur) et aucune ressource chargée depuis Internet. Sur un cluster de production ou de préproduction, une console qui échoue à un contrôle ne peut pas être ouverte ; ailleurs, les contrôles s'affichent en avertissement. L'ouverture d'une console passe par POST /api/v1/clusters/{id}/consoles/{service}/open, qui est journalisée (console.open). Un administrateur qui détient cluster:manage publie l'adresse interne d'une console derrière la passerelle HTTPS de la banque (PUT .../consoles/{service}/access). Les consoles des identités et des secrets (Keycloak, OpenBao, OpenFGA) sont réservées aux détenteurs de vault:manage : les autres les voient verrouillées, sans leur adresse.

Audit

Chaque modification et chaque refus produisent un événement d'audit. Les événements sont chaînés par sha256 (chacun conserve l'empreinte du précédent) ; GET /api/v1/audit/verify recalcule la chaîne et indique le premier événement altéré. Les exports NDJSON ou CSV alimentent le SIEM de la banque. Les tâches de rétention ne purgent jamais le journal d'audit.

Agents et hôtes

• L'agent ouvre toutes les connexions : les hôtes gérés n'exposent aucun port à la console.
• L'enregistrement utilise un jeton d'amorçage (un seul cluster, date d'expiration, nombre d'utilisations limité, stocké en sha256). La commande d'enregistrement affiche l'empreinte sha256 de l'autorité de la console, que l'agent vérifie avant de lui faire confiance.
• L'autorité de la console signe le certificat de l'agent ; le sujet et les noms viennent du serveur, jamais de la demande. En production, l'API agent exige ce certificat client.
• Chaque requête de l'agent est en plus signée en HMAC-SHA256 avec un horodatage (fenêtre de 5 minutes).
• L'agent n'écrit que sous ses répertoires autorisés (/etc/navin, /opt/navin, /var/lib/navin, /var/log/navin, /run/navin, unités systemd et fichiers Quadlet navin-*, fichiers sysctl et limites 90-navin-*). Un lien symbolique dans le chemin d'une écriture est refusé, le fichier final s'ouvre sans suivre les liens.
• Les commandes s'exécutent avec un chemin absolu de programme pris dans la liste autorisée ou dans les répertoires gérés. Les valeurs des variables d'environnement sensibles sont masquées dans les journaux et les résultats.
• Les téléchargements sont vérifiés avec le sha256 du manifeste du miroir et les images avec leur empreinte.
• Pare-feu de l'hôte (firewall.open, firewalld ou ufw) : les ports des clients sont ouverts à toutes les sources ; les ports que seul le cluster utilise (transport, pairs, réplication, gossip, liaisons, Prometheus du cluster, d'après la matrice des flux) ne sont ouverts qu'aux hôtes du cluster et au Manager, par l'ipset firewalld navin-<cluster> ou une règle ufw par membre, et fermés aux autres sources. La tâche network.firewall_members envoie le nouvel ensemble de membres à chaque hôte quand un hôte arrive ou part (installation durcie).

Contrôles de production

navin-manager check (également lancé par navin-manager serve) refuse de démarrer en production sans : TLS sur les deux écoutes, certificats clients pour les agents, attribut Secure du cookie, jeton de métriques d'au moins 32 caractères, coût scrypt d'au moins 16384, clé maître, et URL de base avec sslmode=require, verify-ca ou verify-full.

En-têtes HTTP

La console est servie avec une politique de sécurité du contenu stricte (default-src 'self', aucun script en ligne, frame-ancestors 'none'), X-Content-Type-Options: nosniff, X-Frame-Options: DENY, Referrer-Policy: no-referrer et, avec TLS, Strict-Transport-Security. Les réponses de l'API ne sont jamais mises en cache.