Ouvrir la console d'administration

La console d’administration est l’interface web depuis laquelle vous pilotez la passerelle : déclarer ce qu’elle sert, écrire la politique, lire les actes des sessions, révoquer une session ou un utilisateur. Cette page décrit comment y entrer, ce que vous y trouvez, et les situations qui ressemblent à une panne sans en être une.

La console est réservée aux administrateurs. Elle n’est pas une interface pour les postes des développeurs, dont la seule interface est la passerelle, et vous pouvez la restreindre à votre réseau d’administration. Ses échanges sont chiffrés en TLS, comme tous les flux entre composants (livre blanc sécurité V3, section 6.2).

Qui entre dans la console

Lemniscate ne gère pas d’identités : il s’appuie sur les vôtres. La console délègue l’authentification à votre annuaire d’entreprise (OpenID Connect). Elle ne vérifie aucun mot de passe et n’en détient aucun. Des comptes locaux n’existent que pour les environnements isolés, où aucun annuaire n’est joignable (livre blanc sécurité V3, section 6.1).

Quatre rôles humains se partagent les droits (livre blanc sécurité V3, section 6.1) :

Rôle	Ce qu’il fait
Administrateur sécurité	définit les politiques globales et les exports de journaux ; ne voit pas le code
Administrateur de projet	définit les outils actifs, les commandes libres ou à valider, les budgets, les membres du projet
Développeur	lance des sessions dans les projets dont il est membre ; valide les différences et les commandes
Auditeur	lit les journaux et les politiques, en lecture seule

L’agent n’a aucun compte et n’entre pas dans la console.

Être authentifié ne suffit pas : chaque chemin de la console exige une permission nommée, et chaque permission est portée par un seul rôle. Un sujet authentifié sans rôle attribué n’obtient rien. Les noms exacts des rôles et des permissions que la console connaît sont dans la référence de la console d’administration.

Sans annuaire configuré

Sans annuaire déclaré, personne n’entre : une installation qui n’a pas encore déclaré son annuaire n’a aucune identité valide à opposer.

Trois réglages d’environnement portent cette déclaration : l’émetteur de l’annuaire, l’identifiant de client, et l’adresse de retour du flux de connexion. Leurs noms exacts et leur effet sont dans la référence de la console. Ils se posent dans l’environnement du conteneur, pas depuis la console.

L’adresse de retour est celle de cette console, et l’annuaire doit la connaître : déclarez-la aussi du côté de l’annuaire, sans quoi il refuse de vous renvoyer vers elle.

La première ouverture chez un client, en trois gestes

Une installation neuve n’a pas d’écran de déblocage : tout se fait avant, dans l’environnement du conteneur et par une commande d’exploitation. Les trois gestes, dans cet ordre.

1. Déclarer l’annuaire, puis redémarrer la console

Les trois réglages ci-dessus se posent dans l’environnement du conteneur. Ils sont lus au démarrage : un changement ne prend effet qu’au redémarrage suivant.

La deuxième ligne du journal de démarrage nomme l’émetteur auquel la console délègue. Si elle dit qu’aucun annuaire n’est configuré, ou qu’il en manque une partie, le motif exact est écrit là.

2. Se connecter une première fois, et être refusé

Ouvrez l’adresse de la console. Elle vous renvoie vers votre annuaire, qui vous authentifie et vous ramène. Vous êtes alors refusé : le message dit que votre identité est reconnue, mais qu’aucun rôle qui vous est attribué ne porte ce droit.

Ce refus fait partie du chemin : la table des rôles d’une installation neuve est vide, et le geste suivant a besoin du nom sous lequel votre annuaire vous a présenté. C’est ce nom, l’identifiant que votre annuaire porte et non votre adresse électronique s’il en distingue deux, que la commande suivante attend.

3. Attribuer le premier rôle

Ce geste ouvre l’instance, et il ne passe pas par la console : le droit d’attribuer des rôles est lui-même un droit, que personne ne porte encore.

Depuis le conteneur de la passerelle, qui a la connexion à la base :

node dist/authz/attribuerRole.js <identifiant-annuaire> administrateur-d-instance "<qui attribue>"

Trois choses à savoir sur cette ligne :

• administrateur-d-instance est le rôle qui ouvre la console. Attribuer un autre rôle authentifie sans rien ouvrir.
• Le troisième argument est conservé avec l’attribution, dans le journal des actes d’administration. Il est déclaré, non vérifié : écrivez-y un nom de personne, pas admin.
• La commande ne crée ni compte ni secret. Elle écrit un nom dans une table. Votre annuaire doit toujours authentifier ce nom : l’attribuer à quelqu’un que l’annuaire ne connaît pas n’ouvre rien.

Rechargez la console : elle s’ouvre.

Le rôle d’auditeur

Un même sujet ne peut pas cumuler un rôle d’administration et le rôle d’audit : c’est la séparation qui donne son sens au journal, qu’un administrateur ne doit pas pouvoir relire. Sur une instance neuve, personne ne lit le journal tant que le rôle d’auditeur n’est attribué à personne, et il ne peut pas l’être à vous.

Attribuez-le à quelqu’un d’autre, avec la même commande.

Lire les trois lignes du démarrage

Quand elle commence à écouter, la console écrit trois lignes dans son journal :

1. l’adresse et le port sur lesquels elle écoute ;
2. ce qui l’authentifie : le mécanisme, et, s’il manque quelque chose pour que quiconque puisse entrer, ce qui manque. C’est le seul endroit où le motif complet est dit : les réponses HTTP n’annoncent qu’une classe de refus, pour ne pas renseigner un attaquant sur l’état du déploiement ;
3. le référentiel de comptes dont elle dispose : un référentiel local, ou aucun.

Ce que vous trouvez à l’écran

Le profil de construction décide des onglets présents. C’est un paramètre de construction, pas un réglage : un artefact n’en change pas, et le profil fermé est celui que la construction produit sans paramètre.

Une page unique, une barre latérale à gauche, et jusqu’à sept onglets dans un ordre fixe : Users, Plans, Endpoints, Usage, Caps, Policy, Audit. Le pied de la barre latérale porte le réglage d’apparence (thème clair ou sombre), et rien d’autre : ni l’identité connectée, ni bouton de déconnexion, ni numéro de version.

Les onglets du profil fermé

En profil fermé, trois onglets existent : Endpoints, Policy et Audit. Les quatre autres (Users, Plans, Usage, Caps) ne sont pas cachés : leurs libellés, leurs formulaires et leurs appels ne sont pas dans le paquet livré, et les chemins correspondants répondent 404.

Ces quatre onglets n’ont pas d’objet dans l’architecture de référence, où la passerelle parle à votre propre moteur d’inférence : toutes les identités viennent de votre annuaire, et aucune consommation n’est à facturer. Ils ne sont présents que dans les consoles construites en profil hébergé.

Endpoints est le seul onglet dont une installation ait besoin pour servir quoi que ce soit. Voir Déclarer un modèle servi par la passerelle.

Le bandeau ambre en haut de page

Un bandeau peut apparaître au-dessus du titre, sur tous les onglets. Il annonce ce que la passerelle fait des sessions d’agent, et il ne s’affiche que lorsqu’il y a quelque chose à dire :

• soit la passerelle n’a pas annoncé ce qu’elle fait (elle est antérieure à cette version, ou n’a pas été redémarrée depuis). La console ne peut alors pas dire si les commandes d’agent tournent sur le serveur ou sur les postes ;
• soit la garantie de confinement du référentiel de sécurité ne tient pas pour ce déploiement, et le bandeau liste ce qu’elle ne vous donne pas.

Ce bandeau décrit la passerelle, pas chaque poste : un poste configuré pour exécuter localement ne l’interroge pas.

Il est réservé au rôle d’administration d’instance. Un auditeur ne le voit pas.

Le conteneur

L’image expose le port 6002, qui est aussi le port d’écoute par défaut, et se lance sous un utilisateur non privilégié. Elle ne contient que le nécessaire à l’exécution : le paquet construit et ses dépendances de production, sans le code source ni l’outillage de développement.

Sans paramètre de construction explicite, l’image obtenue est celle du profil fermé. Un oubli produit l’artefact restreint, pas l’inverse.

Le fichier de composition

Le dépôt ne livre pas de fichier de composition qui monte la console avec sa base pour un déploiement. Le seul qui assemble les trois conteneurs (base, passerelle, console) est le banc d’attaque sous scripts/redteam/, avec un fournisseur simulé ; il ne sert pas à déployer. Lancez donc les deux conteneurs et reliez-les vous-même : la console a besoin d’une chaîne de connexion vers une base dont les migrations sont appliquées. Voir Appliquer les migrations de base.

Le réglage de base de données oublié

Sans chaîne de connexion dans son environnement, la console ne refuse pas de démarrer : elle se rabat sur une base de développement locale. Un déploiement qui oublie ce réglage ne rougit pas ; il se connecte ailleurs, et vous voyez une console vide au lieu d’une erreur.

Si la console s’ouvre sur des listes vides alors que votre base contient des données, vérifiez ce réglage avant tout le reste.

La page de démonstration des composants d’interface

Le dépôt contient une seconde interface, servie sur le port 6003 par une commande distincte, qui affiche les composants graphiques de la console pour qui la développe.

Elle ne pose aucune authentification. Elle n’affiche aucune donnée de la base et n’appelle aucun chemin de service. Ne la lancez pas sur un hôte de production ; le paquet construit pour la production ne la contient pas.

Ce que la console ne fait pas

• Elle n’a aucun écran de première configuration. Tout se pose dans l’environnement du conteneur avant le premier démarrage.
• Elle ne détient aucun mot de passe et n’a aucun écran pour en changer : l’authentification appartient à votre annuaire.
• Elle n’est pas joignable depuis les postes des développeurs quand vous la restreignez à votre réseau d’administration, et elle n’a aucune destination sortante (livre blanc sécurité V3, section 6.2).