À propos

NAME

gke, ingénieur infrastructure et plateforme, qui construit en pensant à celui qui voudrait s’y infiltrer.

SYNOPSIS

gke [-industrialiser] [-securiser] [-debugger] [-detourner] [-transmettre] [-inferer] [-encadrer] probleme...

DESCRIPTION

gke prend en entrée ce qui ne se reproduit pas, un parc dont plus personne ne connaît l’histoire, un déploiement fait à la main un soir d’astreinte, une prod que personne n’ose plus toucher et le rend en sortie idempotent, puis immuable, rejouable par n’importe qui dans l’équipe. Il commence toujours par comprendre ce qui existe avant de le remplacer, parce qu’une prod qui tourne, même mal, porte des années de décisions que personne n’a jamais écrites. Il a pris les responsabilités une à une, du dépannage jusqu’à la conduite d’infrastructures entières, sans jamais lâcher le clavier en route et ne suppose jamais que le parc sera propre ni uniforme, ce qui est souvent le moment où l’on a le plus besoin de lui.

OPTIONS

-industrialiser

De l’objet IoT et du site edge au serveur physique qui démarre en PXE, de l’unikernel à la VM en passant par la microVM et le conteneur et du cloud privé au cloud public sans oublier l’hybride qui les relie, avec partout la même exigence, que la machine soit décrite dans git avant d’exister et qu’on puisse la détruire sans regret. Linux, BSD, Windows, macOS et équipements réseau y cohabitent dans la même chaîne, parce que la réalité d’un parc a rarement lu la documentation.

-securiser

Secure by design, de la recompilation du noyau au pinning des images de conteneurs par empreinte, en passant par les bastions SSH , une PKI interne qui parle ACME , des secrets qui ne traînent plus dans les dépôts et des images reconstruites depuis les sources pour savoir ce qu’elles embarquent vraiment. Le regard d’attaquant vient de loin, d’un Action Replay qui lisait la mémoire d’une Super Nintendo et il pose sur chaque plateforme les questions d’un intrus patient, non pas comment la casser mais comment s’y infiltrer, y rester, faire le ménage derrière soi et sortir les données par un canal que personne ne surveille, pour que la réponse soit chaque fois la même, nulle part.

-debugger

Du crackme des années 90 au pilotage, à distance, d’équipes de techniciens tiers sur une infrastructure hétérogène à l’autre bout du monde, il descend jusqu’à la couche où le problème se trouve vraiment, du strace au désassembleur , d’un .jar décompilé faute de sources au crash dump d’une JVM au fond duquel traîne la DLL d’un EDR, en passant par la cascade qu’un arrêt électrique sale laisse derrière lui. Il écrit ensuite le post-mortem, y compris quand le coupable est lui-même et il lui arrive même de débugger ses propres intuitions , avec la même méthode et un segfault à la clé quand elles se prennent pour des théories.

-detourner

Fait faire aux outils ce pour quoi ils n’avaient pas été prévus, un Action Replay pour lire la mémoire d’une console, un portail captif qui ne filtre que le HTTP mais résout n’importe quel nom et donne donc l’internet à qui sait parler DNS, des hooks git pour piloter des flottes de serveurs, une veilleuse de salle de réunion pour afficher l’état de la CI, parce que comprendre un système, c’est aussi savoir jusqu’où il se laisse plier.

-transmettre

Échange sur IRC depuis 1998, a passé ses soirées jusqu’à la fin des années 2000 sur des forums d’informatique à aider des inconnus à dépanner et optimiser leur machine, à apprendre à coder ou à débugger leur propre code, publie ce qu’il apprend depuis 2006 et contribue à l’open source, mais c’est ailleurs que la transmission aura le plus compté. Il a aidé des collègues à préparer leurs concours d’ingénieur, qu’ils ont obtenus, appris la programmation à des jeunes comme à des techniciens qui voulaient aller plus loin, accompagné des adultes en reconversion et transmis le virus à des stagiaires comme à des gamins croisés dans des communautés de jeux vidéo. Certains sont devenus ingénieurs, architectes ou développeurs et il arrive que l’un d’eux revienne le remercier dix, quinze ou vingt ans plus tard, ce qui reste sans doute la seule métrique dont il soit franchement fier.

-inferer

De l’inférence sur des GPU locaux ou mutualisés entre pairs, au partage des poids de modèles en pair à pair , en passant par des agents qui se relisent les uns les autres avant qu’on leur fasse confiance, avec toujours deux questions avant de brancher un modèle quelque part, est-ce que ça résout un problème ou est-ce que ça décore une slide et surtout quelles données partent où, par quel chemin et qui pourra les relire ensuite.

-encadrer

Option expérimentale, mais curieusement très stable. Il fut un temps où sa documentation ressemblait à un script, numérotée de 4.1.2 en 5.3.4, truffée de “si tel cas, se référer à 3.5.3”, parfaitement exécutable par une machine et à peu près illisible pour ses collègues, jusqu’au jour où il a compris qu’il valait souvent mieux leur écrire un mail, ou au pire leur parler ;) Il fonctionne de façon collégiale, avec une culture du remote forgée dans l’open source et c’est avec des juniors autonomes comme avec des profils très pointus qu’il aura toujours donné le meilleur, en guidant, en challengeant et en arbitrant selon sa perception des besoins du projet, que l’équipe se charge de remettre souvent à jour. Son autorité tient surtout à son argumentaire, ce qui deviendrait un défaut le jour où un junior n’oserait pas le remettre en question alors qu’il le devrait et c’est précisément ce jour-là qu’il faudrait le lui dire.

EXIT STATUS

0 quand la centième machine est identique à la première. Un post-mortem publié dans tous les autres cas.

HISTORY

Un VTech Laser 500 à cassettes, toujours rangé dans sa mallette. Un Action Replay sur Super Nintendo, puis sur PlayStation, pour figer le jeu, lire la mémoire, changer un octet et voir ce qui casse, du reverse avant d’en connaître le mot. DOOM, Quake, Warcraft, StarCraft, Unreal Tournament, Half-Life et Counter-Strike et les LAN parties qui allaient avec. Des stages chez des dépanneurs et en cybercafé, puis le dépannage chez les particuliers comme chez les pros, la meilleure école pour apprendre qu’une machine en panne a toujours un propriétaire pressé. Debian en 2001 et avec elle la conviction que tout doit pouvoir se scripter. Des nuits sur IRC, des sockets écrites en C avec les seules man pages et des paquets forgés à la main , pour voir ce que le réseau répond quand on lui parle autrement. Un harnais d’exploitation greffé sur GDB en 2006, parce que piloter son débogueur en Perl, c’est la base quand on est lazy. Repris en Prolog en 2009, parce qu’au fond, c’est mieux quand la machine écrit les scripts à sa place. Vingt ans plus tard, un pipeline neuro-symbolique, dont sont sortis augure et lictor . Des flottes de serveurs de jeu pilotées par git et ses hooks, du GitOps avant que le mot existe , puis Puppet, Ansible, Terraform et l’immuable. Et ce blog, ouvert en 2006, fermé et rouvert plusieurs fois, qui raconte aussi ce qui n’a pas marché.

BUGS

Publie ses propres erreurs, jusqu’à la RCE trouvée dans son propre gestionnaire de plugins Vim . Demande “pourquoi” avant “comment”, ce qui rallonge parfois les réunions et raccourcit toujours les post-mortems. Ne peut pas croiser une boîte noire sans chercher le tournevis, ce qui explique en partie tout ce qui précède. Allergique au théâtre, le :ro sur une socket qui parle en root, l’obscurité prise pour de la sécurité , la sauvegarde jamais restaurée . Se méfie d’une prod qui tourne trop bien, parce qu’un intrus soigneux l’optimiserait volontiers pour qu’on la regarde moins. Recompile son noyau pour le plaisir, ce qui n’est pas un bug mais inquiète parfois l’entourage.

REPORTING BUGS

gke@6admin.io