Le serveur ne répond plus. SSH dans le vide, ping muet, l'hyperviseur a planté quelque part entre le noyau et l'enfer. Et pourtant vous reprenez la main, vous lisez la température des CPU, vous montez une ISO de secours, vous forcez un redémarrage propre, sans bouger de votre bureau. C'est le rôle du BMC, ce petit ordinateur dans l'ordinateur qui vit même quand le reste est mort. La vraie question n'est pas s'il faut un BMC, c'est comment on lui parle. Et la réponse a changé.
Pendant vingt ans, on lui parlait en IPMI. Aujourd'hui, on lui parle en Redfish, une API REST que n'importe quel script curl comprend. Le passage de l'un à l'autre n'est pas cosmétique : c'est la différence entre un protocole binaire troué qu'on tolérait faute de mieux, et une interface qu'on automatise vraiment.
Le BMC, l'admin hors-bande qui survit à tout
Le BMC, pour Baseboard Management Controller, est un microcontrôleur soudé sur la carte mère, avec son propre processeur, sa propre RAM, sa propre pile réseau, son alimentation indépendante. Tant que le serveur est branché au secteur, le BMC tourne, même carte mère éteinte, même OS effondré. C'est ce qu'on appelle l'administration hors-bande : on agit sur la machine sans passer par le système qu'elle héberge.
Chaque constructeur a sa marque. iDRAC chez Dell, iLO chez HPE, le BMC générique chez Supermicro et beaucoup d'autres. Le matériel diffère, la fonction est identique : allumer, éteindre, redémarrer, lire les capteurs (température, ventilateurs, tensions, alimentations), accéder à la console comme si on était physiquement devant l'écran, monter un média virtuel pour réinstaller, mettre à jour le firmware. Sans BMC, chaque intervention sur un serveur planté exige une présence physique dans le datacenter. Avec, on opère un parc entier à distance.
Le piège classique : croire que le BMC est un détail. C'est au contraire la porte d'entrée la plus puissante du serveur, et la plus dangereuse si elle traîne sur un réseau ouvert. D'où l'importance de ce qu'on raconte à cette porte.
IPMI, le vieux protocole qu'on éteint
IPMI, c'est le langage historique du BMC, né dans les années 1990. Un protocole binaire, sur UDP/623, conçu à une époque où la sécurité réseau était une note de bas de page. Il a rendu service. Il doit partir.
Le problème n'est pas l'âge, c'est l'état. IPMI v2.0 traîne des faiblesses connues et structurelles. Le « cipher 0 » accepte une authentification sans aucun chiffrement quand il est activé, autrement dit l'accès root au BMC sans mot de passe. Le protocole expose aussi des mécanismes de récupération de hash qui rendent les attaques par dictionnaire triviales sur un BMC accessible. Sur le terrain, on découvre encore des parcs entiers où l'interface IPMI répond sur un VLAN mal cloisonné, avec le mot de passe constructeur d'usine. C'est la définition d'un point d'entrée gratuit pour un attaquant.
Surtout, les constructeurs eux-mêmes ont tranché. Intel, qui a porté IPMI à l'origine, indique sur sa page officielle qu'aucune nouvelle évolution n'est prévue pour la spécification. Traduction ops : le protocole est gelé, il ne recevra plus de corrections fonctionnelles, l'avenir de l'administration serveur est ailleurs. Quand le créateur d'un protocole annonce qu'il arrête de le faire vivre, on planifie la sortie, on ne mise pas dessus.
Redfish, REST sur le BMC
Redfish est la réponse, standardisée par le DMTF (dmtf.org/standards/redfish), l'organisme qui fait converger les constructeurs sur une interface commune. Le principe : une API REST sur HTTPS, des ressources adressables par URI, des réponses en JSON. Tout ce qu'on sait déjà faire sur une API web, on le fait sur le serveur physique.
Concrètement, l'arborescence Redfish expose le serveur comme un ensemble de ressources navigables. /redfish/v1/Systems liste les systèmes, /redfish/v1/Chassis décrit le châssis et ses capteurs, /redfish/v1/Managers représente le BMC lui-même. Chaque ressource se lit en GET, se modifie en PATCH, déclenche des actions en POST. Lire l'état d'alimentation d'un serveur Dell tient en une requête :
curl -sk -u admin:password \
https://192.168.10.5/redfish/v1/Systems/System.Embedded.1 \
| jq '.PowerState'
Forcer un redémarrage propre se fait par une action POST :
curl -sk -u admin:password -X POST \
-H 'Content-Type: application/json' \
-d '{"ResetType": "GracefulRestart"}' \
https://192.168.10.5/redfish/v1/Systems/System.Embedded.1/Actions/ComputerSystem.Reset
Le périmètre couvert va bien au-delà de l'allumage. On lit la télémétrie (capteurs thermiques, consommation électrique, état des alimentations), on configure le BIOS à distance, on met à jour le firmware du BMC et des composants, on monte un média virtuel pour provisionner, on s'abonne aux événements pour recevoir une alerte quand une barrette mémoire commence à corriger trop d'erreurs. Tout ça en JSON, versionné, documenté. Le Redfish Developer Hub (redfish.dmtf.org) publie les schémas, ce qui rend l'API explorable sans deviner.
L'écart avec IPMI n'est pas qu'esthétique. IPMI exige des outils dédiés, des commandes ésotériques, un parsing fragile de sorties binaires. Redfish s'intègre dans tout ce qui parle HTTP, donc dans toute la chaîne d'automatisation moderne. Côté ops, ça change la vie : un parc se pilote en scripts, pas à la souris dans dix interfaces web différentes.
Automatiser : Ansible, sushy, et le parc entier
L'intérêt de Redfish se révèle à l'échelle. Piloter un serveur en curl, c'est mignon. Piloter cent serveurs sans toucher une seule interface graphique, c'est le but.
Ansible parle Redfish nativement via la collection community.general. Le module redfish_command exécute les actions, redfish_info collecte l'inventaire et la télémétrie. Un playbook qui éteint proprement un groupe de serveurs avant une coupure électrique planifiée se résume à quelques lignes :
- name: Arret propre avant maintenance electrique
hosts: localhost
tasks:
- name: Graceful shutdown des serveurs
community.general.redfish_command:
category: Systems
command: PowerGracefulShutdown
baseuri: '{{ item }}'
username: '{{ bmc_user }}'
password: '{{ bmc_password }}'
loop: '{{ bmc_hosts }}'
Pour du code Python, la bibliothèque sushy (docs.openstack.org/sushy), maintenue par la communauté OpenStack, fournit un client Redfish propre. C'est elle qui sous-tend une partie du provisioning bare-metal d'OpenStack Ironic, donc du code éprouvé sur des parcs réels, pas un script de démonstration. On l'utilise pour scripter des opérations complexes, enchaîner configuration BIOS, montage d'ISO et boot dans un ordre maîtrisé.
Et pour qui veut sortir totalement des firmwares propriétaires, OpenBMC (github.com/openbmc/openbmc) propose un firmware BMC libre, basé sur Linux, qui expose Redfish nativement. Adopté par les hyperscalers pour leurs serveurs sur mesure, il rend l'administration hors-bande auditable jusqu'au code. Tout le monde n'en a pas besoin, mais l'existence d'une implémentation ouverte tire l'écosystème vers le haut.
Cette mécanique s'inscrit dans une chaîne plus large. Le BMC sert à démarrer la machine, mais c'est ensuite le démarrage réseau en PXE et DHCP qui charge le système, puis cloud-init qui provisionne la configuration au premier boot. Redfish déclenche, le reste enchaîne, et le serveur sort de l'usine prêt sans qu'une main l'ait touché.
Surveiller et diagnostiquer par la même porte
Redfish ne sert pas qu'à agir, il sert à voir. Les ressources de télémétrie exposent en continu l'état physique du serveur, ce qui en fait une source de données pour la supervision indépendante de l'OS. Même si le système est planté, le BMC continue de remonter la température, la consommation, l'état des disques et des alimentations.
C'est précieux pour le diagnostic. Une alimentation qui faiblit, un ventilateur qui ralentit, une barrette qui multiplie les erreurs corrigées : ces signaux précèdent souvent la panne franche, et Redfish les expose avant que l'OS ne s'en rende compte. Brancher ces métriques sur la supervision matérielle d'un parc permet d'agir sur un composant fatigué avant qu'il ne lâche en production. Et quand la panne survient quand même, le diagnostic matériel commence par interroger le BMC, seul témoin encore vivant de ce qui s'est passé.
La règle qu'on applique : la supervision matérielle passe par le BMC en Redfish, jamais par l'OS seul. Un OS qui plante emporte sa propre supervision avec lui. Le BMC, non.
Verdict ops
Sur un parc neuf, le choix ne se discute pas. Tout se pilote en Redfish, l'API REST devient la couche d'administration unique, et l'automatisation passe par Ansible ou sushy plutôt que par des clics dans dix interfaces web. C'est plus sûr, plus scriptable, et c'est la direction que les constructeurs ont eux-mêmes prise.
IPMI ? On l'éteint dès que c'est possible. Quand un firmware le permet, on désactive purement l'interface IPMI/LAN pour ne garder que Redfish sur HTTPS, et on coupe l'accès réseau du BMC derrière un VLAN d'administration dédié, jamais routable depuis Internet. Le cipher 0 activé, le mot de passe constructeur d'usine, l'IPMI exposé : ce sont les trois trous qu'on trouve en audit, et les trois qu'on ferme en premier. Un BMC mal protégé, c'est un accès root physique offert à qui le trouve.
Quand on reprend l'infogérance d'un parc, l'inventaire des BMC et leur durcissement font partie de la première passe : remettre chaque carte dans l'état décrit plus haut. C'est ce qu'on fait sur les infrastructures qu'on opère. Si vous ne savez pas dans quel état sont les BMC de vos serveurs, on peut auditer le parc et le remettre au niveau.
Sources
- DMTF Redfish : la page officielle de la spécification, l'organisme qui standardise l'interface entre constructeurs.
- Redfish Developer Hub : les schémas, la documentation développeur et les outils pour explorer l'API.
- OpenBMC : le firmware BMC libre basé sur Linux, qui expose Redfish nativement, adopté par les hyperscalers.
- Sushy : la bibliothèque Python cliente Redfish maintenue par OpenStack, socle du provisioning bare-metal d'Ironic.
- Module Ansible redfish_command : le module officiel pour piloter le BMC hors-bande depuis un playbook.
- Intel IPMI : la page Intel confirmant qu'aucune évolution future de la spécification IPMI n'est prévue.
