Kloak est un outil innovant conçu pour sécuriser les secrets dans Kubernetes en les injectant directement au niveau du noyau via eBPF, sans que l'application ne les manipule jamais en clair. L'idée centrale est d'intercepter le trafic TLS sortant à l'aide d'uprobes eBPF, remplaçant des placeholders par les vrais secrets juste avant le chiffrement, ce qui empêche leur exposition même en cas de compromission du conteneur. Contrairement aux solutions traditionnelles comme OpenBao ou les sidecars, Kloak évite que les secrets ne résident en mémoire de l'application, réduisant ainsi les risques d'exfiltration.
L'architecture de Kloak repose sur deux plans distincts : un control-plane qui gère les Shadow Secrets et synchronise les eBPF maps, et un data-plane qui intercepte les appels TLS via des hooks sur SSL_write et crypto/tls.(*Conn).Write. Le controller, déployé en tant que DaemonSet, surveille les secrets labellisés et réécrit les montages de pods via un Mutating Admission Webhook, garantissant une intégration transparente sans modification du code applicatif.
L'auteur présente un Proof of Concept (PoC) détaillant les défis rencontrés, notamment avec Flannel et Cilium, ainsi que des méthodes d'analyse via les logs et les compteurs eBPF. Bien que le projet soit récent et open-source, il offre une approche prometteuse pour renforcer la sécurité des secrets dans les environnements Kubernetes, en alignement avec les principes zero-trust.
L’auteur exprime une critique envers Tailwind CSS, qu’il compare à l’utilisation d’ingrédients industriels pour préparer une tarte à la citrouille, plutôt qu’à une version artisanale. Bien que Tailwind offre des avantages en termes de rapidité et d’efficacité, il estime que cette approche élimine la maîtrise du CSS, une compétence qu’il considère comme un artisanat à part entière.
Il souligne que le CSS bien écrit repose sur des principes comme la cascade, les variables personnalisées, les systèmes d’espacement cohérents et les sélecteurs adaptés, des aspects que Tailwind contourne au profit de classes utilitaires. Pour lui, cette méthode prive les développeurs de la compréhension profonde du langage, au profit d’une productivité immédiate.
Enfin, il met en avant des figures comme Kevin Powell, qui démontrent que le CSS natif permet des designs élégants et maintenables sans dépendre d’outils externes. Selon lui, l’adoption systématique de Tailwind freine l’apprentissage et la maîtrise du CSS, réduisant le développement à une simple "assemblage" plutôt qu’à une création réfléchie.
L’auteur, développeur depuis plus d’une décennie, défend l’idée que se former à un nouveau langage de programmation reste essentiel à l’ère de l’IA, malgré ses capacités croissantes à générer du code. Il souligne que l’utilisation excessive de l’IA risque d’éroder les compétences fondamentales en programmation, comme la modélisation des problèmes ou l’évaluation critique du code produit. Apprendre un nouveau langage permet de préserver ces bases tout en découvrant d’autres philosophies et pratiques, enrichissant ainsi sa vision du développement.
Pour cette année, il a choisi C#, un langage en constante évolution mais souvent associé à tort à l’écosystème Microsoft. Son objectif est de dépasser les préjugés et d’explorer la culture "craft" de sa communauté, qu’il juge dynamique et inspirante. Cette démarche reflète sa volonté de maintenir un esprit critique face aux outils automatisés, en s’appuyant sur une maîtrise solide des concepts fondamentaux.
L’article met en lumière l’importance de l’apprentissage continu pour rester pertinent dans un domaine en mutation rapide, où l’IA devient un allié plutôt qu’un substitut à l’expertise humaine.
La page propose sept stratégies pour renforcer la résilience mentale face aux défis de la vie. L’idée centrale est que la résilience n’est pas une qualité innée, mais une compétence qui se cultive, comme l’apprentissage d’une langue ou le développement physique. Elle permet de mieux gérer le stress, les échecs et les émotions négatives sans se laisser submerger, tout en favorisant une récupération plus rapide et une meilleure satisfaction de vie.
Parmi les stratégies détaillées, deux se distinguent : d’abord, la capacité à reconsidérer sa perception du stress (en le voyant comme un défi plutôt qu’une menace) et ensuite, l’importance de construire une routine quotidienne solide pour ancrer des habitudes saines. L’article souligne aussi que la résilience ne signifie pas affronter seul les difficultés, mais savoir s’appuyer sur un réseau de soutien.
Enfin, la page insiste sur le fait que la résilience repose sur l’adaptabilité et la gestion des émotions, et non sur une rigidité émotionnelle. Elle invite à voir ces stratégies comme un entraînement progressif, où l’échec et les émotions difficiles font partie du processus d’apprentissage.
Cette formation en ligne, intitulée Git par la pratique, s’adresse aux développeurs et administrateurs souhaitant maîtriser Git, un outil essentiel pour la gestion de versions. L’approche adoptée est résolument pratique, privilégiant l’apprentissage par la manipulation directe plutôt que la théorie, avec des ateliers conçus pour une installation minimale de Debian Linux.
Les prérequis sont modestes : une familiarité avec le shell Linux, les commandes de base et un éditeur de texte comme Vim ou Nano. Bien que des adaptations existent pour Windows et macOS, la formation recommande de commencer sous Linux pour éviter les complexités liées aux environnements propriétaires.
L’objectif principal est de permettre une gestion efficace de projets informatiques collaboratifs, en assurant un suivi des modifications, une coordination entre développeurs et une stabilité du code. Les concepts clés, comme les branches, les conflits ou les pull requests, sont abordés de manière progressive pour éviter les erreurs courantes.
Ce billet explique comment installer et configurer EasyAdmin sur Symfony pour créer rapidement un back-office efficace. L’auteur souligne que ce bundle est idéal pour administrer 2 à 30 entités Doctrine avec un CRUD générique, sans alourdir le projet, contrairement à des solutions comme Sonata ou API Platform Admin, plus complexes ou spécialisées.
L’installation se fait en une seule commande Composer, suivie de la génération automatique d’un DashboardController via une commande Symfony. Le bundle propose ensuite une configuration minimale pour accéder à l’interface d’administration dès le départ.
L’article met en avant la simplicité d’EasyAdmin, qui évite une configuration lourde tout en restant flexible pour des personnalisations basiques, ce qui en fait un choix pertinent pour les projets où l’admin est un outil et non un produit à part entière.
Scott H. Young, auteur du livre Ultralearning publié en 2019, revient sur les principes de son ouvrage à l’ère de l’IA. Bien que l’idée centrale – l’importance de l’apprentissage autodidacte et continu pour rester compétitif dans un monde saturé d’informations – reste valable, l’IA a profondément transformé les méthodes d’apprentissage. Elle n’a cependant pas réduit l’effort intrinsèque requis, ni modifié la tendance des individus à privilégier des activités moins exigeantes.
L’IA offre de nouvelles opportunités, notamment pour la méta-apprentissage (comprendre comment apprendre), en facilitant la recherche et la structuration des connaissances, même pour des compétences pratiques obscures. Young souligne que l’IA peut aider à décomposer un sujet en sous-parties, listes de concepts ou activités pratiques, réduisant ainsi les coûts de cette phase préparatoire. Cependant, elle ne remplace pas l’engagement et la discipline nécessaires pour maîtriser une compétence.
Cet article explore comment les habitudes façonnent l'identité, en s'appuyant sur des principes de neurosciences et de psychologie comportementale. L'idée centrale est que les changements durables passent par une transformation de l'image de soi plutôt que par la simple fixation d'objectifs externes. En adoptant des habitudes alignées sur l'identité souhaitée (comme se considérer comme "lecteur" plutôt que vouloir "lire plus"), chaque action renforce cette nouvelle perception, rendant les comportements automatiques et durables.
L'auteur explique que la clé réside dans la répétition de petits actes cohérents avec l'identité visée, qui finissent par réorganiser les circuits neuronaux. Le cerveau automatise ces comportements, les rendant naturels et sans effort, contrairement aux approches basées sur la volonté qui échouent souvent à long terme. Douze exemples concrets d'habitudes identitaires sont proposés pour illustrer cette méthode.
L'article souligne aussi que cette approche évite les pièges des objectifs temporaires, car elle crée une identité stable et motivante en soi, bien au-delà de la réalisation ponctuelle d'un but.
Proxmox Backup Server (PBS) est une solution de sauvegarde automatisée pour les machines virtuelles (VM) et conteneurs LXC, présentée comme une alternative fiable aux simples snapshots ZFS. L’auteur partage son expérience après avoir perdu des données faute de sauvegardes complètes, soulignant l’efficacité de PBS : sauvegardes incrémentielles rapides (2-3 minutes contre 20 pour un premier backup complet), déduplication des blocs identiques entre VMs, vérification d’intégrité via checksums et stockage distant possible. Un incident matériel (défaillance d’un NVMe) a permis de restaurer l’intégralité des VMs en moins de 10 minutes, illustrant l’avantage d’une solution dédiée.
L’architecture détaillée repose sur une VM PBS dédiée, hébergée sur un nœud distinct des VMs critiques, avec deux datastores NFS : l’un sur un NAS pour les VMs sensibles (rétention longue), l’autre sur un Synology pour les sauvegardes quotidiennes. La VM PBS elle-même est exclue de ses propres jobs de backup pour éviter des blocages, et les sauvegardes sont planifiées en dehors des pics de charge (2h du matin). La configuration inclut des règles de rétention différenciées (quotidiennes, hebdomadaires, mensuelles) selon les besoins.
L’installation de PBS suit celle de Proxmox VE, via une ISO dédiée, avec des prérequis matériels modestes (2 vCPU, 4 Go RAM, 32 Go de stockage système). L’intégration à Proxmox VE se fait via une connexion au serveur PBS, en spécifiant l’IP, les identifiants et le datastore cible. L’auteur détaille aussi le montage d’un partage NFS pour stocker les sauvegardes, étape clé pour une configuration robuste.
Ce dépôt GitHub recense une sélection d'outils axés sur la protection de la vie privée, couvrant divers besoins comme les messageries chiffrées, les emails anonymes, les VPN, le réseau Tor, les gestionnaires de mots de passe ou encore le partage sécurisé de fichiers. Il propose des alternatives open source ou auto-hébergées aux services traditionnels, avec des critères stricts pour évaluer leur fiabilité, leur transparence et leur utilité.
Les outils sont classés par catégories (navigation privée, stockage sécurisé, systèmes d'exploitation, etc.) et incluent des solutions pour particuliers, développeurs ou journalistes. Chaque recommandation est accompagnée d'une brève description et de liens vers leurs sources officielles.
Le projet met en avant des critères de sélection exigeants : amélioration concrète de la confidentialité, maintenance active, absence de téléchétrage ou de modèles économiques douteux, et priorité à l'open source. Aucune affiliation ou placement payant n'est toléré.
Ce tutoriel explique comment sauvegarder un Raspberry Pi pour éviter de perdre des mois de configuration en cas de corruption de la carte SD. L’auteur propose une solution combinant deux outils : rsync pour sauvegarder les fichiers vers un NAS via le réseau, et rpi-clone pour cloner le système vers un disque physique (clé USB, SSD, etc.) de manière bootable. La méthode permet ainsi de disposer à la fois d’une sauvegarde réseau avec historique et d’un clone immédiat pour une restauration rapide.
L’article détaille d’abord la configuration de rsync avec un partage NFS sur un NAS Synology, incluant les étapes de montage manuel et automatique via le fichier fstab. Il souligne l’importance des options comme soft et timeo pour éviter les blocages en cas de déconnexion réseau. Ensuite, il aborde rpi-clone, limité aux disques locaux, mais idéal pour une duplication exacte et bootable du système.
L’approche hybride vise à couvrir tous les scénarios de restauration, que ce soit pour récupérer des fichiers spécifiques ou relancer le système en quelques minutes.
L’article analyse les UserNamespaces dans Kubernetes, une fonctionnalité présentée comme révolutionnaire mais souvent mal comprise. L’auteur souligne que ces espaces de noms réduisent l’impact d’une évasion de container en mappant l’UID 0 (root dans le container) vers un utilisateur non privilégié sur l’hôte, limitant ainsi les dégâts en cas de compromission. Cependant, il critique les promesses exagérées des infographies, qui présentent cette fonctionnalité comme une solution miracle contre les risques de sécurité, alors qu’elle ne couvre qu’un scénario spécifique (l’escape de container).
L’auteur détaille les cas d’usage concrets des UserNamespaces, comme l’exécution de builds sans privilèges (Buildah, Podman rootless) ou la gestion de legacy systems (Postfix, Dovecot) nécessitant des UID fixes. Il rappelle aussi que cette fonctionnalité ne remplace pas les bonnes pratiques de sécurité, comme le multi-tenancy ou la gestion des vulnérabilités kernel, et que son efficacité dépend d’une configuration rigoureuse. Les UserNamespaces sont utiles, mais leur adoption doit s’inscrire dans une stratégie globale.
Enfin, l’article met en garde contre une confiance excessive dans cette fonctionnalité, soulignant que les risques de sécurité applicative (mauvaise configuration, secrets exposés) ou opérationnelle (mauvaise gestion des ressources) restent critiques. L’auteur conclut que les UserNamespaces sont une avancée, mais qu’ils ne doivent pas occulter les priorités réelles en matière de sécurité Kubernetes.
L'article aborde une troisième stratégie d'héritage dans Doctrine, souvent négligée au profit des approches binaires STI (Single Table Inheritance) et CTI (Class Table Inheritance). L'auteur propose la Mapped Superclass, une solution intermédiaire qui permet de partager des propriétés et méthodes entre classes PHP sans imposer de contrainte de stockage unique ou de jointures coûteuses. Contrairement à STI (une table commune avec un discriminant) ou CTI (tables séparées liées par clé primaire), cette méthode crée des entités autonomes tout en conservant une structure de code cohérente.
L'auteur illustre son propos avec un cas concret : une classe abstraite AbstractContent marquée comme #[ORM\MappedSuperclass], héritée par des entités comme Post, Page ou Category. Chaque enfant bénéficie des propriétés communes (titre, slug, statut, métadonnées SEO) sans partager une table physique, évitant ainsi les inconvénients des deux autres méthodes. STI aurait entraîné des colonnes inutiles ou nulles, tandis que CTI aurait alourdi les requêtes avec des jointures systématiques.
Enfin, l'article souligne que cette approche offre un équilibre entre modularité et performance, en s'affranchissant des compromis des stratégies classiques. La Mapped Superclass est présentée comme une solution pragmatique pour des hiérarchies de modèles complexes, où la réutilisation du code prime sur les contraintes de persistance.
Les Fibers, introduites dans PHP en novembre 2021, sont une primitive bas niveau permettant un mécanisme de stack switch coopératif, souvent comparé à une suspension d'appel téléphonique où l'état complet (variables, pile d'appels) est préservé. Contrairement aux generators, elles permettent à n'importe quelle fonction, à n'importe quelle profondeur d'appel, de suspendre l'exécution via Fiber::suspend(), sans nécessiter une propagation manuelle du yield. Cette caractéristique est cruciale pour les bibliothèques asynchrones comme Amphp ou ReactPHP, qui encapsulent les Fibers pour offrir une API synchrone à l'utilisateur final, évitant ainsi le problème des colored functions.
Bien que souvent associées à tort au multi-threading ou à l'asynchrone pur, les Fibers restent mono-threadées et ne gèrent pas elles-mêmes les opérations d'entrée/sortie. Leur rôle se limite à fournir un outil de contrôle d'exécution précis, laissant aux bibliothèques le soin de gérer les attentes (sockets, timers, etc.). Leur minimalisme et leur explicitement en font une solution puissante mais peu visible dans le code applicatif classique, où elles opèrent en coulisses.
L'API des Fibers, volontairement épurée, repose sur quelques méthodes clés : Fiber::__construct(), Fiber::start(), Fiber::suspend() et Fiber::resume(). Cette simplicité reflète leur nature de mécanisme brut, conçu pour être intégré dans des couches d'abstraction supérieures plutôt que directement utilisé par les développeurs. Leur adoption discrète dans des frameworks comme Symfony s'explique par cette philosophie de conception.
Le billet du Google Testing Blog explique comment optimiser l'accès aux structures de données comme les maps ou dictionnaires pour éviter des opérations redondantes. L'idée principale est de regrouper la vérification d'existence et la récupération de la valeur en une seule opération, plutôt que de les effectuer séparément. Par exemple, en Python, utiliser employees.get(employee_id) au lieu de employee_id in employees suivi de employees[employee_id] évite un double accès à la structure.
L'article illustre cette optimisation avec plusieurs langages, comme Go (via l'idiome comma ok), C++ (map.find()) ou Java (computeIfAbsent()), qui permettent de combiner vérification et récupération en une seule passe. Cela améliore non seulement les performances, mais réduit aussi les risques de conditions de course dans des environnements multithreads.
Enfin, le texte aborde des cas courants comme l'initialisation de valeurs par défaut ou l'incrémentation, en recommandant des approches idiomatiques propres à chaque langage (comme defaultdict en Python ou les default-constructed values en C++). L'objectif est d'écrire un code plus propre, efficace et robuste, surtout à grande échelle.
L’auteur, consultant Cloud Native Infra, partage son expérience avec Mise, un outil de gestion de versions d’outils, variables d’environnement et secrets pour plusieurs projets. Il explique comment Mise simplifie la gestion de contextes multiples (versions d’outils, configurations Kubernetes, secrets) en remplaçant un mélange d’outils comme asdf, direnv ou sdkman, avec une activation automatique par répertoire via des fichiers TOML.
Son setup repose sur une arborescence hiérarchique où chaque niveau (global, projet parent, environnement spécifique) définit des configurations adaptées. Par exemple, les variables globales gèrent des éléments comme un proxy WireGuard, tandis que les fichiers mise.toml des projets parents et environnements ciblent des paramètres comme les endpoints OVH ou les adresses de Vault pour les secrets.
L’outil, écrit en Rust et rapide, permet d’éviter les erreurs courantes (comme exécuter une commande sur le mauvais cluster) grâce à une activation contextuelle transparente. L’auteur mentionne aussi une présentation récente à Devoxx France 2026 et des slides disponibles pour approfondir.
Ce tutoriel explique comment publier un blog généré avec Hugo sur Gitlab Pages, en s’appuyant sur l’automatisation via Gitlab CI. L’auteur détaille les prérequis nécessaires, comme la maîtrise de Git, un compte Gitlab avec une clé SSH configurée, ainsi qu’une installation fonctionnelle de Hugo. Le processus commence par la création d’un dépôt Gitlab nommé selon des règles spécifiques pour obtenir une URL accessible, comme pseudo.gitlab.io, facilitant ainsi la publication du site statique.
L’article guide ensuite l’utilisateur dans la configuration minimale d’un site Hugo au sein du dépôt, puis aborde l’automatisation de la compilation et du déploiement via Gitlab CI. L’auteur souligne que, bien que le tutoriel puisse paraître long lors de la première utilisation, les étapes suivantes deviennent rapides et simplifiées, permettant une mise à jour en moins de dix minutes. Une attention particulière est portée au nommage du dépôt pour optimiser l’accès au site final.
L’article souligne l’importance pour les développeurs de tester eux-mêmes leurs fonctionnalités avant livraison, plutôt que de se reposer uniquement sur des tests automatisés ou des équipes QA. Il illustre ce point par un exemple concret où une page fonctionnait techniquement mais était inaccessible aux utilisateurs standards, révélant un problème de permissions non détecté par les tests. L’auteur insiste sur le fait que les tests automatisés valident le code, mais c’est l’usage réel du produit qui en valide la pertinence.
L’auteur met en lumière l’effort supplémentaire que représente ce test manuel, nécessitant de se mettre à la place de l’utilisateur, d’explorer des parcours complets et d’anticiper des scénarios inattendus. Il critique la tendance à déléguer ces vérifications à d’autres équipes, ce qui crée une distance nuisible entre le développeur et le produit final, et retarde la détection de problèmes évidents.
Enfin, l’article défend l’idée que le travail d’un développeur ne s’arrête pas à l’écriture du code : il doit s’assurer que ce qu’il livre fonctionne réellement pour le client. Tester soi-même permet d’améliorer l’empathie produit, d’accélérer les revues de code et de réduire les coûts liés aux bugs visibles plus tard dans le cycle de développement. Les tests automatisés restent essentiels, mais ne remplacent pas une validation fonctionnelle manuelle.
L’article met en garde contre la pratique dangereuse curl | bash, souvent présentée comme une méthode d’installation simple, notamment dans des documentations officielles. Cette méthode, qui consiste à télécharger et exécuter directement un script depuis Internet, expose à des risques de sécurité majeurs. En effet, le script exécuté peut différer de celui consulté, car le serveur peut adapter sa réponse en fonction du contexte (navigateur, curl, adresse IP, etc.), exploitant ainsi les particularités du pipeline Unix où bash commence à exécuter le script avant même qu’il ne soit entièrement téléchargé.
L’auteur souligne que même l’utilisation de HTTPS ne protège pas contre cette menace, car il garantit uniquement l’intégrité du transport et l’authenticité du serveur, mais pas l’honnêteté du contenu servi. Un serveur malveillant peut ainsi fournir un script inoffensif lors d’une visualisation directe, tout en injectant un code malicieux lors d’une exécution via curl | bash. Des techniques comme la détection du comportement typique d’un pipeline (par exemple, en insérant une commande lente comme sleep) permettent à un serveur de distinguer une exécution directe d’une exécution via curl | bash, renforçant ainsi le risque d’exécution de code non désiré.
L’auteur présente Zensical, un nouveau framework de documentation créé par Martin Donath, ancien développeur de Material for MkDocs, en réaction à l’attitude jugée hostile du projet MkDocs. Zensical se veut une alternative moderne, 100 % libre et bien documentée, remplaçant avantageusement la combinaison MkDocs + Material for MkDocs, tout en offrant une base solide malgré son statut alpha.
Le tutoriel détaille l’installation via un environnement virtuel Python, la création d’un projet et son initialisation, illustrant le processus pas à pas. L’auteur souligne la simplicité des commandes et la régularité des mises à jour, tout en précisant que Zensical est déjà fonctionnel pour des projets de documentation technique.
Enfin, l’article annonce une série de guides pratiques pour exploiter Zensical, notamment pour publier des HOWTOs sur GitLab Pages, avec des sections dédiées à la configuration, à l’ajout de logos ou d’icônes, et à l’organisation du menu.