InfraRiver Collector — Config (mTLS)
/admin/collector-tls/ — page centrale pour tout ce qui concerne InfraRiver Collector
(voir InfraRiver Collector — principe pour l'architecture complète).
La page a trois volets :
- Jetons d'ingestion ;
- Activité des canaux ;
- mTLS et bundles.
Jetons d'ingestion
Le volet Tokens d'ingestion (Bearer) configure directement le token partagé par chaque plugin qui reçoit des données du collecteur : champ éditable + Générer/Sauvegarder.
| Plugin | Données reçues du collecteur |
|---|---|
| LinuxRiver | posture / sockets / logiciels |
| CertRiver | certificats |
Chaque page de plugin (/admin/plugins/linuxriver, /admin/plugins/certriver) garde un
statut lecture-seule + lien vers cette page — toute l'édition se fait ici. Ce token est un
prérequis avant même le certificat mTLS.
Le token s'affiche une seule fois
Le token n'est jamais conservé en clair : seules son empreinte et ses quatre derniers caractères sont enregistrés. Il s'affiche une seule fois, à sa génération : notez-le alors.
Règles de fonctionnement :
- les collecteurs déjà déployés continuent de fonctionner : ils envoient le token, le serveur le compare à l'empreinte ;
- un token enregistré avant ce changement est converti en empreinte au démarrage ;
- un token saisi à la main doit faire 20 caractères au moins.
Activité des canaux
Le volet Activité des canaux d'ingestion affiche, par canal, le nombre de lignes, le nombre de serveurs distincts et la dernière activité. Canaux :
- posture ;
- logiciels ;
- certificats ;
- sockets, ventilés par transport SSH/NRPE/Zabbix/SNMP.
Note
Vue par canal, pas par collecteur physique : aucune requête d'ingestion ne porte aujourd'hui d'identité de collecteur précise.
mTLS et bundles
Le volet mTLS montre le statut de l'autorité de certification interne : générée automatiquement, propre à cette instance, jamais partagée entre plusieurs installations.
Le formulaire de génération d'un bundle par collecteur demande :
| Champ | Rôle |
|---|---|
| Nom commun / CN | Identifiant unique du collecteur, ex. collector-site-nantes |
| URL InfraRiver | Pré-remplie — à corriger si le collecteur joint l'instance par un autre nom d'hôte |
| Jeton d'ingestion (facultatif) | Recopié dans le fichier de configuration si vous le collez ; il n'est plus recopiable automatiquement |
Le bundle (.tar.gz) contient :
- le certificat client mTLS (
client.crt/client.key/ca.crt) ; - un
infrariver_collector.ymldéjà rempli : URL, mTLS, jeton propre au collecteur, compte et port SSH, modules, et le jeton d'ingestion si vous l'avez collé (vide, le fichier contientREPLACE_WITH_LINUXRIVER_INGEST_TOKENà remplacer) ; - un
install.shqui dépose le tout aux bons emplacements sur le collecteur — voir Installer le collecteur.
Téléchargement unique
Le bundle n'est généré et téléchargeable qu'une seule fois : la clé privée n'est jamais conservée côté serveur.
Le volet propose aussi le téléchargement du certificat de la CA seule et la liste des collecteurs enrôlés.
Chaque collecteur enrôlé a sa propre page fiche (clic sur sa ligne dans la liste). Elle montre son historique complet d'émissions et permet de réémettre un certificat pour ce même collecteur.
Authentifier la passerelle côté collecteur
Le bundle contient aussi mtls/server-ca.crt quand le certificat du serveur est celui, auto-signé, qu'InfraRiver génère : c'est ce fichier — et non ca.crt, qui
ne sert qu'à vérifier les certificats clients — que le collecteur utilise pour s'assurer qu'il envoie ses jetons à votre serveur. Si vous installez un certificat émis
par une autorité sur /admin/web-tls/, générez de nouveaux bundles : ca_cert y est alors vide et le magasin de confiance du système fait foi.
Avec INGEST_MTLS_ONLY=true (Fichier de configuration du serveur), l'adresse pré-remplie du formulaire est celle de la passerelle (port 8443) ; c'est le cas de tous les collecteurs fournis (collecteur InfraRiver, collecteur Windows Active Directory, collecteur PKI, agent CertManager). Une installation neuve active cette option à son premier démarrage ; une mise à jour ne la modifie pas.