Mais qu’est-ce que je fais de mon Raspberry ?

Puisqu’il y a en ce moment un hashtag #IUseMyRaspberryFor qui expose des usages du Raspberry plus ou moins intéressants, laissez-moi vous parler de mon infrastructure domestique. En préambule, mon Raspberry est branché en Ethernet à la freebox et alimenté par le port USB de la freebox. Parce que ce Rasbperry est uniquement un device réseau.

Qu’est-ce que j’héberge ?

Sur mon Raspberry, j’ai donc

  • Un serveur Apache qui sert
    • Une instance Shaarli dans laquelle j’ai migré mes liens delicious, et qui commence à être raisonnablement remplie (6367 liens à l’heure actuelle)
    • Une instance tweetledee pour lire Twitter en RSS (mais vous allez voir plus loin que je ne fais pas exactement ça).
    • Une instance rss-bridge pour récupérer encore plus de flux RSS depuis des sources diverses (GQMagazine, World of Tanks, Facebook)
  • Une instance mldonkey (ben oui, ça marche toujours, tant que je télécharge uniquement des « vieux » fichiers)
  • Un script rss2imap (et maintenant rrss2imap) pour envoyer mes flux RSS dans ma boîte IMAP.
  • Et deux-trois scripts shell pour faire des backups de configuration.

Je n’ai pas installé de pi-hole dessus (même si j’y ai souvent pensé). Je n’ai pas non plus de media-center qui tourne dessus (parce que je l’ai migré sur mon NAS – c’est plus rapide et plus fiable). Par contre, j’utilise régulièrement mon Raspberry en tant que machine de rebond SSH pour sortir de chez certains clients pénibles. Et pour ça, il ne me faut que le serveur SSH, qui est installé d’office par Raspbian.

Mais attends, comment ça s’intègre ?

Parce que bon, me contenter de dire j’ai ça, c’est mignon, mais il y a dans tout ça un but. Le but officiel, c’est que ce Raspberry, qui est exposé sur internet, me serve de mémoire et de noeud central dans ma méthode de collecte et d’organisation d’information. Je vous montre (ben oui, PlantUML, c’est quand même bien chouette pour présenter de l’information)

infos.png

Bon, évidement, le schéma n’est pas super super clair. Mais comme je crois aux qualités de PlantUML …​ je vais le laisser comme ça 😀. Et surtout, je n’ai pas mis dans ce schéma mldonkey (parce que ça aurait rajouté de la complexité inutile).

Donc, Shaarli mémorise tout, et IFTTT envoie ça dans ma timeline Twitter. A côté de ça, rss2imap lit les flux RSS depuis RSS-Bridge, Tweetledee, et tout un paquet de « vrais » flux RSS. Et évidement, le contenu de ces flux est envoyé dans ma boîte mail (ce qui m’offre grâce à l’IMAP une lecture synchronsiée sur tous mes devices à un coût dérisoire). Avec ça, j’ai enfin atteint à mon avis le graal de la lecture de flux RSS (en tout modestie, bien sûr) : j’utilise un protocole standard, optimisé pour du texte, afin de récupérer mon texte où que je sois, la lecture est synchronisée, et j’ai une interface de lecture vraiment top (parce que les clients mails sont conçus pour gérer un gros volume de messages)

Et comment je le maintiens ?

Cette question-là, je me la suis posée plusieurs fois …​ parce que mon Raspberry a déja mangé quelques cartes micro-SD (vous n’avez qu’à regarder dans les archives du blog). Et donc, j’ai maintenant un playbook Ansible qui me permet de reconstruire le Raspberry « presque » automatiquement. Ce script inclut (et c’est sans doute la meilleure partie) un cronjob qui, tous les jours, copie les fichiers de configuration de toutes ces applications sur mon NAS. Et ce script marche bien puisque j’ai réinstallé mon Raspberry il y a moins d’un mois à partir de ces fichiers de configuration. Donc, je sais qu’il me faut moins de deux heures d’exécution de script (et environ 10 minutes d’intervention manuelle) pour remettre mon Raspberry en état quand la carte mémoire claque (ce qui arrive beaucoup trop régulièrement).

Comment faire mieux ?

D’abord, ce serait peut-être bien d’exposer mon fichier OPML quelque part dans Apache, ça m’aiderait bien à communiquer sur mes sources. Ensuite, j’aimerai beaucoup remplacer IFTTT par Beehive, qui s’exécuterait sur le Raspberry. Et c’est, je crois, à peu près tout pour ce Raspberry. Parce que j’ai toujours dans un coin de ma tête ce projet de webradio …​

Je n’ai finalement rien compris à Consul

Depuis quelques temps, j’ai pris l’habitude de regarder des vidéos de conférence pendant ma séance hebdomadaire de repassage du dimanche matin. C’est cool, parce que je vois comme ça sans doute autant de conférences que ce que je vois « en live ».

Et cette semaine, j’ai regardé cette conférence sur Consul.

Et je vous la recommande si vous ne connaissez pas Consul.

Mais je vous la recommande aussi (et peut-être même surtout) si vous connaissez déja Consul. Je le dis d’autant plus franchement que c’est mon cas : j’ai mis en place une architecture à base de Consul + Traefik + Rancher (+ le petit Registrator, qui m’a bien fait transpirer). Donc j’ai déja mis des services avec des healthchecks dans Consul. Et ça marche bien.

Par contre, je n’avais jamais pensé à mettre des métadonnées dans mes services (enfin, si, mais c’était uniquement pour traefik). Je n’avais en fait pas pensé que ces métadonnées pourraient être utilisées de façon générique pour, par exemple, mettre à jour un API Manager ou pour gérer des ACLs. De ce point de vue, j’ai pris une baffe terrible. Et en fait, cette baffe vient d’un truc que je n’avais pas vu : consul watch. Avec cette commande, on peut notifier des services « techniques » qu’une nouvelle instance de service est apparue ou a disparu. Et c’est grâce à cette brique que le speaker déploie ces services complémentaires.

A ce sujet, il évoque même la possibilité de faire du load-balancing « intelligent », c’est-à-dire tenant compte de la charge des services. Mais j’ai bien noté qu’il n’enregistrait pas cette charge dans les métadonnées, ce que j’ai trouvé … un peu dommage.

N’empêche, ça me donne de très chouettes idées (en lien avec mon travail actuel sur l' »architecture as code »).

Le management visuel est une approche réactionnaire

Il y a des articles qu’on ne veut pas écrire.

Des choses où on se dit que non, vraiment, ça n’est pas bien d’écrire ça.

Mais quand même.

Laissez-moi vous expliquer. D’abord, réactionnaire, c’est facile (tout au moins d’après le wiktionnaire)

(Politique) Qui sert à opérer une réaction ; qui travaille à une réaction politique : à un mouvement d’opinion qui agit dans un sens contraire au mouvement qui a précédé.

Autrement dit, qui va contre les tendances précédentes.

Et le management visuel ? C’est tout aussi facile, c’est l’art de faire fleurir les tableaux de bords/les panneaux d’avancement agile dans les bureaux. Regardez donc ces belles images d’efficacité affichée.

Ce moment où tu remplaces ton feu de cheminée par des post-its …

Bon, maintenant que j’ai posé les mots, pourquoi c’est réactionnaire ?

Nous sommes en 2020, d’accord ?

Et à un moment où on sait que la visioconférence, le télétravail, c’est bien, on choisit de rassembler les gens dans le même bureau (idéalement assez serrés) pour les motiver par un tableau blanc/feu de camp sur lequel on va faire avancer des tâches d’une façon dix fois efficaces que l’infâme Trello (ou que des solutions intelligentes comme GitHub Project management). Alors pourquoi ça marche mieux ?

Sans doute à cause de « l’agile par la peur ». L’agile par la peur, c’est la méthode que suivent les organisations qui font de l’agile alors qu’elles n’en veulent pas, mais parce qu’elles meurent par perte de talents sans ça (genre CapGemini qui fait du Scrum, quoi). L’agile apr la peur, c’est aussi quand on fait des daily stand-up pour que le chef de projet devenu PO puisse suivre les tâches de l’équipe. Et donc,d ans l’agile par la peur, le management visuel est très apprécié, parce qu’il permet au manager d’avoir sous les yeux tout ce que fait l’équipe, mais aussi (et surtout) toute l’équipe. Parce qu’il ne faut pas se leurrer, si les entreprises investissent dans les tableaux blancs plutôt que dans des logiciels collaboratifs, c’est aussi parce que ça force les équipes à être colocalisées, c’est-à-dire au bureau.

Autrement dit, avec le management visuel, on peut dire aux gens qui font du télétravail « ok, mais tu viens pour le daily alors ? ». Et d’un coup, ça détruit le télétravail et ça remet l’agile dans les pas des méthodes de « command and control » les plus classiques.

Zéro autonomie

Zéro innovation

Tout ça grâce à un tableau et des post-its.

Gradle au chtijug

Louis est venu pour nous donner envie d’essayer Gradle. Il commence par un sondage facile qui montre (comme d’habitude) que Maven est bien plus utilisé que Gradle.

Gradle c’est quoi ?

C’est un outil de build et d’automatisation, implémenté à 80-90% en Java 😯. Évidement Gradle est gratuit. Mais il est aussi agnostique c’est-à-dire qu’il peut builder du Java, de l’Android, du natif, du go, de l’Asciidoctor). Grâce aux environnements de build temporaire, il y a 10 M de téléchargements par mois. Chez LinkedIn, il y aurait 300k builds par semaine.

Evidement, Gradle estd éveloppé par Gradle Inc, qui vend deux produits : Gradle enterprise et Gradle build scan.

Productivité du développeur

Aujourd’hui, la productivité du développeur est importante, avec les IDE, les langages, les frameworks (comme Micronaut et Quarkus), le matériel. Mais globalement, la productivité du développeur dépend des boucles de feedback rapide. Et c’est ce que veut offrir Gradle ! Et pour atteindre la productivité, il faut une performance maximale du build …​ de l’ensemble des composants. Et donc, Gradle mesure les builds sur les outils de CI, mais aussi sur les postes des développeurs.

Expérience personnelle

Louis a travaillé sur un projet Maven pour lequel le build le plus rapide prenait 20 minutes (avec 20 modules). Et en passant à Gradle, il obtient son résultat en quelques secondes.

Comment ?

Anatomie d’un projet Gradle

DOnc Gradle a des conventions, comme maven. Par exemple, le source est dans src/main/java, les resources de rest sont dans src/test/resources. Il y d’autres conventions spécifiques : le nom du projet est le nom du dossier le contenant (ce qui pose problème pour les projets de base).

Dans un projet simple, le build sera dans le dossier build plutôt que target. Vous aurez toujours un gradle/wrapper/gradle-wrapper.jar pour vous permettre d’utiliser la version de Gradle que vous voulez. Et il y a un build.gradle[.kts] définissant le build.

Dans un projet multimodule, il y a un dossier par module, et voilà.

Démo

Donc notre build.gradle est un fichier écrit dans un DSL Groovy. On y retrouve les dépendances, les plugins, la configuration. Et pour écrire des éléments spécifiques, on peut évidement faire des plugins, qui semblent plus simple à charger …​ Et là, j’ai l’impression que Louis part tout de suite sur un projet un peu complexe …​ (tout ehcache d’un coup, c’est peut-être un peu épais …​)

Par contre, ce qui est sympa avec gradle, c’est que gradle tasksliste l’ensemble des tâches disponibles. Mais en fait, on continue très vite à avoir un bon gros gradle, puisque fondamentalement, il y a des dépendances, des plugins, de la configuration.

Modèle de build

Dans Gradle, il y a un modèle complet pour chaque tâche. Louis prend l’exemple de la compilation : lors de celle-ci, on a juste besoin du CLASSPATH correspondant aux signatures des méthodes. En revanche, à l’exécution, il faut le CLASSPATH correspondant à tout le code (y compris celui utile dans le corps des méthodes). Du coup, quand une dépendance change de version Gradle ne recompile la dépendance qui si la signature des méthodes de la dépendance change. Ca accélère évidement beaucoup la compilation !

Comment vérifier que le build est incrémental ? Il suffit de lancer deux fois de suite le build. Si la deuxième fois des tâches s’exécutent, elles ne sont pas incrémentales, et c’est un problème.

Ce qui nous ramène aux plugins Gradle, pour lesquels il faut déclarer les entrées/sorties via des annotations. Parce que grâce à cette déclaration précise, il est possible de vérifier si la tâche doit être exécutée ou pas.

Cette mdoélisation a un autre avantage : si votre environnement d’intégration continue a déja construit le projet, il est possible grâce au build cache de récupérer le résultat de ce build plutôt que de reconstruire l’application. C’est génial ! Si la récupération du résultat par le réseau va plus vite que le build.

Ce build cache est stable pour les projets Java, Groovy, Scala. Et il y a une image Docker disponible : gradle/build-cache-node !

Gradle 6

Qu’est-ce que ça apporte ?

  • Le support Java 13. « Seulement » maintenant parce que Gradle utilise des bibliothèques externes qui ont dû elles aussi passer à Java 13.
  • Des améliorations autour de la JVM
    • L’optimisation de la compilation de Groovy (pour utiliser le cach autant que possible).
    • Une compilation incrémentale plus rapide pour le Java et le Groovy.
    • Le support du compilateur Zinc pour Scala

Mais surtout la gestion améliorée des dépendances. On change de mode de déclaration des dépendances avec des contraintes sur les versions. Et en fait, ces contraintes permettent de n’inclure les dépendances que si c’est nécessaire. C’est cool ! Et on peut aussi proposer, au sein d’un range de version, définir une version préférée. On peut également définir une version comme dans Maven de façon stricte. Ca a permis de créer un concept de plateforme (qui ressemble un peu au BOM Java).

Dans les travaux intéressants, Gradle a également ajouté la notion de capacité (« capability ») qui permet de garantir qu’il n’y a qu’une implémentation. C’est vraiment utile par exemple pour n’avoir qu’une implémentation de slf4j. Il y a également l’alignement de versions de dépendances qui « collaborent » (comme Jackson ou Spring).

Bon, en fait, Louis nous explique que tout ça n’est pas si nouveau (en fait, seul le strictly est nouveau). Par contre, ce qu’il y a en Gradle 6, c’est un fichier de métadonnées qui permet de publier ces éléments. A noter que ce manifeste liste les fichiers avec leurs signatures. Mais aussi la Javadoc. Ou le source. Ca permet aux consomateurs d’accéder précisément aux éléments utiles.

Et Louis rentre dans une liste de cas particuliers franchement hallucinants : guava, jackson, junit, tous ces projets ont en fait des modes de gestion bien foireux, qui obligent à bien des efforts pour être propre.

Conclusion

Gradle est chouette et plein de très bonnes idées. Mais. Ces idées, malgré leur performance évidente, sont d’un intérêt moindre quand on utilise des frameworks comme Quarkus ou autres, qui offrent un rechargement vraiment rapide. Par ailleurs, à l’époque des microservices, les builds semblent de mon expérience se simplifier « un peu ». Du coup, Gradle est un super produit rempli d’idées incroyablement chouettes. Mais je ne me sens pas la motivation de l’adopter. Pour être honnête, ça me donne même envie de commencer à regarder maven les yeux dans les yeux pour voir comment l’améliorer. Sans doute parce que j’ai une affection quasiment immorale pour cet outil honni par bien des développeurs (et je ne le nie pas).Last updated 2019-11-13 21:45:29 +0100

Ce qu’on a oublié de vous dire sur le sexe

Depuis … des années, je lis les articles de Maïa Mazaurette (à peu près quelquesoit l’endroit où elle écrit). Et c’est toujours très intéressant.

Alors, quand j’ai appris ça

J’ai mis sa vidéo dans ma liste d’attente Youtube, et je l’ai regardée tranquillement. Et franchement, c’est très bien : Maïa arrive à recentrer sur ces quinze minutes de vidéo l’essentiel de la réflexion qu’elle tient depuis quinze ans !

Autrement dit, c’est une vidéo très chouette, très intéressante et surtout très intelligente.

Regardez-la.

Exposer en HTTPS un conteneur Docker qui ne fait que du HTTP

La semaine dernière, j’ai eu droit à une colle « sympa ».

Chez mon client, on utilise de l’OpenID Connect pour sécuriser les services (et c’est cool).

Notre serveur OpenID Connect n’accepte que des urls de redirection en https (ce qui est bien aussi).

Seulement nos applications, qui sont déployées en HTTP, ne connaissent rien au HTTPS. Alors comment je fais pour transformer mon HTTP en HTTPS ?

A priori, c’est une question assez pénible. Mais j’ai lu il y a quelques temps un chouette article qui expliquait comment utiliser Traefik pour exposer du HTTPS à partir de services HTTPS. L’article est vraiment chouette. Mais n’ayant qu’un service HTTP, je me suis dit que Traefik était un poil complexe. Surtout qu’on peut trouver en farfouillant un peu un conteneur Docker fournissant le même service, mais basé sur nginx. Il s’appelle ssl-proxy. Et il marche vachement bien : avec un simple certificat, mon service peut faire du HTTPS (je ne vous montre pas, c’est dans la doc de ssl-proxy).

Bon, par contre il faut un certificat.

Et c’est là qu’entre en scène mkcert, qui est encore plus chouette. Parce que demander un certificat extérieur pour un pur service Docker, (sur une machine développement qui plus est) c’est un peu trop.

Donc avec mkcert, on génère un certificat (valable jusqu’en 2029, rien que ça), et ensuite on se lance un ssl-proxy, et c’est la fête !

La seule chose qui me manque là-dedans, c’est un « faux » seveur OpenID Connect qui tourne en local et qui me permette de créer des scénarios d’authentification « à la demande ». Mais ça, ça viendra …

GitHub Actions, c’est … assez bien

Vous le savez peut-être, j’ai un projet de réécriture Rust d’un vieux script Python … rrss2imap.

Au début, je buildais ce projet avec Travis CI (sur un compte gratuit). J’avais choisi ça à cause de la ferveur populaire (en l’occurrence une personne me l’avait conseillé). Et comme j’utilisais l’offre d’essai gratuite, au bout de 80 builds, j’ai cherché autre chose. Heureusement, GitHub a lancé au même moment GitHub Actions.

Je me suis donc lancé (parce que comme rrss2imap est open-source – et que le repository est ouvert – j’ai une offre illimitée).

Qu’est-ce que j’en pense ?

La première chose, c’est que c’est du YAML.

Au-dela de ça, on retrouve les forces et les faiblesses de tous les outils de « CI/CD » basés sur des conteneurs : chaque commande est un nouveau conteneur, lancé dans le même contexte. C’est pas follement interactif. Pour ne rien ajouter, passer du contenu d’un job à un autre requiert une action spécifique.

Alors oui ça marche, oui c’est fait par GitHub. Mais ça n’est pas mieux que TravisCI, ni CircleCI, ni GitlabCI. Et pour le dire franchement, c’est bien moins riche que Jenkins (mais Jenkins n’est pas tendance, lui …).

Bon, au moins, j’ai appris un nouveau truc …

Hacktoberfest, c’est cool !

Depuis 5 ans, GitHub et DigitalOcean font rimer Octobre et open-source. Et cette année, j’ai un peu participé.

En vérité, je ne comptais pas du tout travailler sur ces projets.

Si ça n’avait tenu qu’à moi, j’aurais contribué à un projet plus ambitieux, comme Logan le fait en ce moment sur Quarkus

Seulement voilà, RSS-Bridge et Tweetledee sont des projets que j’utilise quotidiennement, dans le cadre de mon système personnel d’ingestion de l’information (oui, c’est prétentieux, mais c’est ce que c’est – et j’ai l’impression que je n’ai pas d’article à ce sujet). Et je rencontrais certaines frustrations avec ces projets. Et j’ai en plus découvert en lisant le code de Tweetledee qu’il était … franchement antique. Du coup, je me suis retrouvé à écrire ces contributions en PHP (qui est loin d’être mon langage préféré). Heureusement, c’était un code raisonnablement simple, que j’ai pu mettre à jour simplement, pour arriver à ce résultat intéressant.

Et ça me rend vraiment content d’avoir participé à Hacktoberfest : parce que ça m’a donné la possibilité de contribuer à un projet que j’utilise tous les jours, et de partager mes compétences pour améliorer cet outil pour tous ses utilisateurs.

Double dose de chtijug !

Quarkus

Bon, j’ai déja vu cette présentation …​ plusieurs fois. Et comme Emmanuel est sympa, il a choisi de prendre des risques pour nous re-présenter Quarkus. Et comme je l’ai déja vu, je vais me contenter des nouveautés.

Emmanuel crée donc …​ une application de TODO, mais cette fois-ci à l’aide du générateur de projets qui permet d’ajouter facilement des extensions. Et donc ça génère un zip, qu’il faut télécharger …​ parce qu’il contient tout le code !

Une fois le zip téléchargé, on démarre en mode développement avec mvn compile quarkus:dev.

Et donc là, Emmanuel va créer ses ressources avec les snippets VSCode. Ca marche …​ assez bien. Sans doute parce que le plugin Quarkus utilise le plugin Java qui fournit l’ensemble des outils de compilation.

Et quand Emmanuel parle de JQL, il évoque cette de contribution de Loïc.

Emmanuel nous montre aussi l’implémentation d’OpenApi par Quarkus (et c’est bien pratique). Et dans l’écosystème, il y a aussi Kafka, Flyway, la compatibilité Spring, parmi tant d’autres …​

Open-source en recrutement

Shirley est recruteuse depuis dix ans, et indépendante depuis plus d’un an. Et il a y peu, l’un de ces employeurs a tenté de la poursuivre en justice.

Des recruteurs éclairés

Il y a maintenant des communautés de recruteurs : recruiter’s kitchen ou le cercle des recruteurs disparus qui permettent aux recruteurs de s’échanger les bonnes pratiques, de s’entraider. Il y a également une école du recrutement qui vise aussi à apporter des bonnes pratiques.

A titre personnel, Shirley a aussi profité de son nouveau statut d’indépendante pour changer sa méthode de recrutement : passer de la recherche des bons mots-clés à une expérience en immersion dans les équipes, pour mieux gérer le process en amont. Evidement, cette immersion lui permet de poser les bonnes questions (qui sont aussi les plus difficiles) : pourquoi les gens partent, est-ce que vous êtes sûrs de votre besoin, …​

Savoir défendre sa liberté

Ca ne s’applique évidement pas qu’au recruteur, mais à tout le monde. Cela dit, en particulier, chez les recruteurs, les questions sont plus directes (et douloureuses) : discrimination des minorités dans le processus de recrutement, par exemple. Ca implique de savoir dire non, de savoir dire stop, de poser les limites et de se faire respecter. Cette partie me fait furieusement penser à certaines collègues …​. Parce que clairement, les recruteurs ne sont pas dans une situation facile : coincés entre des exigences de recrutement et un vivier de talents pas toujours aussi vaste que ce que les recruteurs espèrent, ils sont soumis à une pression assez importante.

Un autre point commun, c’est que les recruteurs signent des contrats qui contiennent parfois difficiles des clauses …​ moralement difficiles.

Il faut aussi tenir compte des limites de la liberté d’expression. Typiquement, on peut se faire virer pour avoir trop parlé, ce qui est parfois dommage pour l’employé, mais aussi pour l’employeur qui perd un talent et qui sacrifie sa marque employeur pour rien.

Autrement dit, les entreprises doivent prendre conscience que favoriser la libre expression des employés rend globalement l’entreprise meilleure, parce que plus visible, plus attractive.

La question du choix

Chez les recruteurs, la question du choix s’aborde très peu. En particulier parce qu’il existe une forme de droit d’auteur ou même de propriété : les compétences que le développeur a acquis sont prétendues appartenir à l’employeur, alors que ça n’est pas tout à fait vrai.

Ca se sent bien dans le vocabulaire du recrutement : il y a de l’acquisition, de l’élevage, de la chasse, …​ Tout ça n’est pas très glorieux. Pour aller un tout peu plus loin, il ne faut pas oublier qu’il y a eu dans la Silicon Valley un accord illégal entre les GAFAM pour éviter la mobilité des développeurs.

Comment en sortir ?

D’abord en lançant des annonces open-source, c’est-à-dire en annoncant tous les détails : salaire, localisation, points positifs et négatifs.

Ensuite en transformant le travail de recruteur en celui d’agent de carrière, en proposant aux gens des offres intéressantes, en CDI ou en freelance, ou autre. Ou en changeant la relation, c’est-à-dire en proposant aux gens des interlocuteurs auxquels ils ont envie de parler.

S’allier avec les concurrents

Actuellement, le marché de l’emploi est un jeu à somme nulle, où on perd aussi souvent qu’on gagne (en tant que recruteur). Ca veut dire qu’il faut aussi le plagiat, qui est une forme de reconnaissance.

Conclusion

Les deux présentations étaient bien. J’ai un petit bémol sur celle de Shirley qui n’est peut-être pas encore complètement … focalisée : parler aux développeurs de recrutement, c’est (pour prendre une métaphore un poil douteuse) parler au mouton des nouveaux ciseaux pour le tondre. Et encore, je ne suis pas juste, parce que Shirley explique bien en quoi le recrutement ne doit pas être ça. Et je suis encore moins juste parce qu’en tant que consultant faisant aussi du recrutement, il y a un certain nombre d’aspects qui m’ont bien parlé. Autrement dit, c’était bien chouette.

Sécuriser son API au chtijug

Pour la rentrée, on va parler sécurisation des APIs. Jusqu’où ira-ton ? Ce sera avant tout un retour d’expérience de ce qui est arrivé chez Decathlon.

Il ya donc maintenant des API partout, parce que les entreprises ont pivoté pour ouvrir les systèmes via ces APIs. Du coup évidement la sécurité ne se passe plus de la même manière (on ne peut plus concevoir le SI comme une citadelle). Chez l’OWASP, ils mettent les API dans le futur top 10 des moyens d’attaque, pas parce que c’est dangereux, mais parce que c’est un bon moyen d’accès. Evidement, il y a tout un tas de risques typiques (déni de service, perte de réputation, …​)

Les basiques

Avant tout, pensez à exposer en HTTPS avec du TLS 1.2. Passez les données sensibles dans des headers, plutôt que dans les paramètres de requêtes (parce que les logs restent présents longtemps). Ne mettez pas les secrets dans le code source !

Dans le top 10 2017 de l’OWASP, on trouve évidement l’injection Javascript/SQL. Ne construisez donc pas vos requêtes SQL à la main. Bon, il faut bien noter que les frameworks actuels empêchent ça depuis longtemps. Hélas, ça réapparait dès que le développeur écrit un morceau de requête à la main. Le site de l’OWASP fournit par ailleurs des informations bien plus complètes sur les injections et les défauts de sécurité.

Outillage de base

Evidement, mettre en place un API manager est une bonne pratique, parce que facilite la gestion de la sécurité. De la même manière, utiliser un identity provider pour stocker l’identité, l’authentification, l’autorisation est vraiment bien.

Identity provider

Identification

Ne confondez pas l’authentification et l’autorisation (ou en HTTP le 401 et le 403) ! Sur ces sujets, il y a deux éléments faciles à prendre en compte

FIDO plus dédiée à l’authentification (qui fournit aussi les clés matérielles). Comme dans OAuth2, on trouve de plus en plus de diagrammes de séquences normalisant les processus d’authentification.

Et les captchas, qui limitent les attaques en force brute.

Autorisation

Ici, on va parler d’OAuth2, et son extension OpenId Connect (qui descend d’OpenId, dont la promesse était d’avoir un identifiant unique partout). Le but d’OAuth2, c’est de donner à l’utilisateur un token. Ce token se récupère à travers des flows, qui nécessitent différents rôles :

  • le client fait la requête (c’est l’application cliente)
  • le resource server expose les données
  • le resource owner est le propriétaire de la donnée exposée (qui n’est pas forcément le même que le resource server).
  • l’authorization server vérifie les credentials de l’utilisateur (Google, Facebook, Keycloak).

A partir de là, on définit différents flows

  • Le code flow : dans ce cas, c’est le resource server qui envoie le code (envoyé par le client) à l’authorization server pour que celui-ci envoie le token
  • Le code + PKCE, spécifique aux applications mobiles (et en particulier à Android) qui existe essentiellement parce que toute les applications peuvent écouter tous les ports en parallèle. On va ajouter au code un PKCE, généré par l’application cliente, qui permettra d’obtenir le token.
  • le flow implicit est déprécié. Il faut le remplacer par un code + PKCE.
  • Entre deux serveurs, on peut utiliser le client credentials. C’est un serveur qui va demander à l’authorization server des credentials directement.
  • Quand le code est totallement maîtrisé, on peut utiliser le resource owner password credential. Même si on maîtrise la production de l’application, il est assez risqué, puisque si un attaquant obtient l’application, il peut attaquer le serveur facilement.
  • Pour les matériels déployés chez le client (comme une freebox), il y a un device flow où un code à 4 chiffres est exposé par le matériel pour que l’utilisateur le saisisse dans son navigateur. C’est utilisé par exemple par Plex pour les applications externes (comme celle de la freebox).
  • Lorsqu’on utilise une borne, on peut utiliser le client initiated backchannel authentication.
  • Depuis un téléphone portable, on peut faire du SSO avec le Native SSO. La première application va demander un secret SSO, qui devra être déposé dans un espace sécurisé du mobile. Et les autres pourront réutiliser ce secret pour se connecter.

Pour une API, le token produit lors de ces flows sera passé en entête HTTP pour authentifier l’utilisateur.

Des faiblesses

L’aglorithme de chifrement

Pas dans OAuth2, mais plus dans certains éléments de base. Par exemple, choisissez des algorithmes de chiffrement asymétriques, parce que ça complique considérablement la vie aux attaquants.

La redirect URI

Le serveur d’autorisation doit valider les urls de redirection, afin d’éviter que les token fuitent vers d’autres applications.

Le state OAuth2

Le state est toujours annoncé comme optionnel. Considérez qu’il est obligatoire, parce qu’il permet de limiter les attaques. Par exemple, dans les librairies d’Auth0, c’est le cas.

Le logout

Lorsqu’on se déconnecte, le navigateur conserve un cookie de l’identity provider, ce qui limite évidement la capacité à se délogger réellement (sauf avec des extensions comme Cookie Autodelete).

Les scopes

Les scopes permettent à l’application cliente de demander à l’utilisateur le consentement pour l’accès à des données. A l’ère du RGPD, c’est indispensable ! En revanche, c’est une donnée personnelle, et pas une donnée partagée.

Les audiences

On peut aussi créer des tokens utilisables par plusieurs API, pour peu que le token définisse une audience plus large.

API Management

La brique d’autorisation est là pour gérer des audiences et des scopes, mais pas pour gérer le métier. Une mauvaise pratique est évidement de déporter le métier de l’application dans l’API Manager. En revanche, un API manager fournit un bon paquet de features

API key

La clé d’API n’est pas de la sécurité. En revanche, elle est très utile. On peut créer des analytics, des quotas, …​ mais pas authentifier.

Gestion des limites

L’API Manager permet de créer des rate limit (nombres de requêtes/secondes) ou des quotas (nombre de requêtes/jour ou par mois) qui évitent au client d’effondrer le serveur.

CORS

L’API Manager va faciliter l’implémentation de la fameuse « same origin policy » implémentée par les navigateurs. Pour ça, aussi bien l’appel à l’API qu’au front-end proviendra de la même URL, par exemple, mais des règles plus fines sont possibles.

Circuit breaker

Encore un truc qui est portable par l’API Manager, pour peu que l’API dispose d’un endpoint de healthcheck.

Routage dynamique

On peut faire du routage dynmaique, ce qui permet par exemple de porter de l’A/B Testing, ou d’autres fonctionnalités de routage (par exemple du routage géographique).

Observabilité

Puisque l’API Manager voit les différentes requêtes, il peut aussi permettre de mesurer les appels, et de fournir le top 10 des requêtes, etc, …​

Conclusion

Alexandre nous a présenté ces slides

Et vous pouvez trouver les exemples dans ce repository GitHub.

Je ne m’attendais pas à avoir une présentation généraliste sur l’écosystème autour des API. C’est intéressant, évidement, mais ça n’adresse pas à mon avis le sujet d’une manière complète : qu’est-ce qui fait une API sûre ? quels sont les risques ? Je n’ai aps eu de réponse à ces questions.