Journal Publication d'acme-dns-tiny et du RFC 8555

Posté par  (site Web personnel) . Licence CC By‑SA.
32
15
juin
2020

Hello,

Ce weekend, j'ai pris le temps de sortir une nouvelle version de mon projet acme-dns-tiny dont je vous avais parlé il y a presque 4 ans déjà.

Cette version 2.2 est une sortie mineure, mais elle a été l'occasion de mettre à jour le site du projet, de publier quelques correctifs mineurs déjà publiés dans la branche master et d'intégrer des correctifs du projet original ACME tiny.

Ce qui m'a motivé à reprendre le développement du projet, c'était que j'ai récemment appris à utiliser de manière plus avancée l'intégration continue de Gitlab.

Maintenant, dès que je fais une Merge Request, des images Docker pour Debian Jessie, Stretch et Buster sont fraîchement préparées et elles sont utilisées pour exécuter les tests du projet.

C'est assez cool d'avoir les images Docker toujours à jour, parce que, avant, je devais le faire manuellement. C'était clairement un frein pour reprendre le développement du projet (il fallait que je me replonge dans les commandes Docker, que je me rappelle pourquoi j'avais fait comme ça les builds…).

Grâce à l'intégration continue de Gitlab, j'ai aussi ajouté des contrôles sur le style du code pour suivre au mieux les directives de la PEP 8. Ces directives me semblent avoir du sens et elles me permettent d'unifier le style du code des 3 scripts proposés par le projet.

Vous noterez que dans le script acme-dns-tiny.py, j'ai choisi de désactiver les règles de pylint au sujet du nombre d'instructions et du nombre de variables utilisées dans un bloc.

Comme l'idée du script est de pouvoir être lu par un maximum de personnes, j'ai préféré garder un grand bloc d'instruction pour qu'il puisse être lu de haut en bas sans avoir besoin de rechercher des fonctions éparpillées au début du code. En effet, le but est que les administrateurs systèmes puissent aussi auditer le code pour être sûr que les clés privées ne soient pas divulguées.

Finalement, quitte à sortir une nouvelle version pour ces améliorations mineures, j'ai également profité de vérifier si le projet est compatible avec la version définitive du standard Automatic Certificate Management Environment (ACME) définie dans la RFC 8555.

En effet, la version précédente d'acme-dns-tiny a été publiée pour être compatible avec le 16ème brouillon du standard.

Heureusement, le texte de la RFC n'a pas beaucoup changé depuis ce brouillon et le code d'acme-dns-tiny n'avait quasiment pas besoin d'être adapté.

À propos de cette RFC 8555, elle a été publiée en mars 2019 et je n'ai pas vu de nouvelle sur LinuxFr après une rapide recherche.

Ce standard est au cœur du projet Let's Encrypt et il permet de fournir des certificats X.509 à moindre coût.

Ces certificats sont très utiles pour sécuriser le transfert des données entre client et serveur et pour s'assurer que le serveur appartient bien au propriétaire du nom de domaine. Ils sont typiquement utilisés pour le web avec le protocole HTTPS, mais également tous les protocoles qui permettent d'utiliser TLS, comme SMTP, IMAP, XMPP, LDAP, les connexions aux bases de données MariaDb, Postgresql…

Pour vérifier que la personne qui demande un certificat possède bien un nom de domaine, l'autorité de certification devait jusqu'à la publication de ce standard définir lui même le moyen utilisé.

Pour les certificats gratuits ou bon marché, souvent, l'identité était déjà vérifiée de manière automatique par l'autorité de certification.

Cependant, elle demandait au propriétaire du nom de domaine des actions manuelles comme: cliquer sur un lien unique publié dans un mail adressé, par exemple, à hostmaster@example.com, ou de créer une ressource DNS unique le temps de la vérification de l'identité, ou encore d'installer un fichier unique sur un site web à une adresse précise…

L'avantage du RFC 8555, c'est qu'il définisse clairement différent moyens sécurisés de vérifier que le demandeur de certificat possède bien un nom de domaine (soit en installant un fichier sur un serveur web, soit en installant une ressource DNS).

En plus d'être sécurisés, ces vérifications sont non seulement automatisable pour les autorités de certifications, mais aussi pour les demandeurs de certificat.

Dorénavant, il n'y a plus besoin d'intervention humaine pour demander et recevoir des certificats X.509 et c'est pour ça que je disais plus haut que ce RFC permet de les fournir à moindre coût.

Non seulement, Let's Encrypt a développé le standard ACME dans le RFC8555, mais en plus, le projet fournit une implémentation logicielle libre nommée boulder pour le serveur de l'autorité de confiance.

Côté client pour les demandeurs de certificats, Let's Encrypt avait débuté le développement de certbot, puis le projet a laissé le maintient du client à l'Electronic Frontier Foundation (EFF). Let's Encrypt tient à jour une liste de tous les clients disponibles (dont, acme-dns-tiny de votre serviteur 😊)

Comme le standard et boulder ont évolué en même temps, boulder connaît quelques divergences par rapport au RFC. Heureusement, aujourd'hui la liste des divergences est courte :)

  • # bravo !

    Posté par  . Évalué à 4 (+2/-0).

    merci pour ce retour, même si ce qui m'a le plus intéressé c'est la partie sur l’intégration continue avec gitlab.

  • # Docker et GitLab CI

    Posté par  (site Web personnel) . Évalué à 3 (+1/-0).

    Question, pourquoi utiliser une image Debian puis installer Python, plutôt que d’utiliser directement l’image python ?

    Autre question, pourquoi créer des images Docker pour les utiliser ensuite dans GitLab CI plutôt que de faire les actions de ton Dockerfile (installer python et ses dépendances) en before_script ?

    Par exemple :

    .check:
      stage: check
      image: python:3.8-slim
      before_script:
        - pip install -r requirements-ci.txt
      only:
        - merge_requests
        - master
    

    Aussi, pourquoi faire tourner les tests unitaires sur plusieurs distributions ? Un des principes des test unitaires, c’est pas justement que tu peux « mocker » ce que tu ne contrôle pas ?

    • [^] # Re: Docker et GitLab CI

      Posté par  (site Web personnel) . Évalué à 5 (+3/-0).

      Hello,

      L'idée de créer les images à partir de Debian est de se rapprocher au plus près de la situation réelle pour l'administrateur système : il a un serveur sous Debian, il installe les modules python nécessaire grâce à apt et il exécute le script.

      Pour être proche de cette situation, j'utilise les images de Debian, puis j'installe les dépendances via apt.

      Mon but est aussi de s'assurer que tout se déroule correctement sans l'accès à pip, car, pour une production, je préfère ne pas utiliser un gestionnaire de dépendance externe à ma distribution.

      Je n'utilise pas "before_script" aussi pour éviter de télécharger à nouveau les dépendances à chaque stage. Docker a l'avantage en plus de faire automatiquement un snapshot à chaque instruction et d'ainsi éviter de télécharger les dépendances entre plusieurs Merge Request :-)

      Notez que gitlab sait aussi optimiser le téléchargement pour before_script si on lui dit de conserver le cache de pip/apt/npm/… Donc, Docker n'est pas nécessaire, mais j'en profite puisque je les construit de toute manière.

      Enfin,l'unique test unitaire, n'est pas vraiment un test unitaire, car il n'y a aucun mock. C'est plutôt dans le sens "opposé aux autres tests qui nécessitent de se connecter au staging de Let's Encrypt". C'est pour ça que je l'exécute sur les 3 environnements.

Envoyer un commentaire

Suivre le flux des commentaires

Note : les commentaires appartiennent à ceux qui les ont postés. Nous n’en sommes pas responsables.