Cet article explique la mise en place d’un stockage persistant sur un cluster Kubernetes on-premise en utilisant Longhorn. L’auteur détaille les prérequis nécessaires, comme un cluster kubeadm sous Debian 13 avec trois nœuds équipés chacun d’un disque dédié de 100 Go, ainsi que la stack Traefik, cert-manager et MetalLB pour l’ingress. La préparation des nœuds inclut l’installation de paquets comme open-iscsi et nfs-common, et la configuration du disque dédié via mkfs.ext4 et fstab.
L’installation de Longhorn s’effectue via Helm, avec une configuration par défaut pointant vers le chemin /var/lib/longhorn-disk et une réplication des données sur trois nœuds. L’auteur vérifie ensuite le bon fonctionnement des pods et la création automatique d’une classe de stockage Longhorn. Un test de stockage persistant est réalisé avec un PersistentVolumeClaim, confirmant l’apparition du volume dans l’interface utilisateur de Longhorn avec trois réplicas.
Enfin, l’article couvre l’exposition sécurisée de l’interface utilisateur de Longhorn via HTTPS avec une authentification basique et un certificat Let’s Encrypt. La configuration inclut la création d’un secret pour l’authentification, un Middleware Traefik pour l’authentification basique, et un certificat TLS. La mise à jour de la Gateway Traefik permet d’accéder à l’interface Longhorn de manière sécurisée.
Let’s Encrypt a révolutionné la sécurisation du web en démocratisant les certificats HTTPS gratuits, rendant le chiffrement accessible à tous, notamment aux blogs et sites communautaires autrefois majoritairement en clair. L’article souligne que cette initiative a comblé un vide historique, où HTTPS était réservé aux sites commerciaux, laissant les données sensibles des utilisateurs vulnérables. Cependant, l’auteur critique l’absence de véritable alternative souveraine à Let’s Encrypt, malgré les discours sur l’autonomie numérique, soulignant que les rares solutions proposées restent limitées face à l’hégémonie du service.
L’article relate l’expérience de l’auteur avec Varnish 9 et son support natif du TLS, combiné à Let’s Encrypt pour sécuriser les connexions. Il détaille le déploiement d’une machine virtuelle Debian 13 sur Hetzner Cloud, où Varnish a été installé via un dépôt APT officiel, simplifiant ainsi le processus. L’auteur souligne l’absence de complications avec IPv6 et l’utilisation d’un sous-domaine dédié pour les tests.
Pour les tests, une application FastAPI minimaliste a été créée, simulant une réponse lente (2 secondes) pour évaluer les performances de mise en cache de Varnish. Les résultats montrent une réduction significative du temps de réponse après le premier appel, passant de 2,4 secondes à 230 millisecondes, illustrant l’efficacité du cache.
Enfin, l’auteur évoque brièvement le fichier de configuration VCL par défaut de Varnish, qui nécessite des ajustements pour une utilisation optimale, notamment pour la gestion du TLS et des certificats Let’s Encrypt, dont la configuration sera abordée dans un futur billet.
Ce tutoriel explique comment générer des certificats ECDSA Wildcard (par exemple, *.abyssproject.net) avec Let's Encrypt et l'API Infomaniak pour la gestion automatique des DNS, sous Debian 13. Il couvre l'installation des prérequis, la génération d'une clé API Infomaniak, la configuration de Certbot, l'émission d'un certificat, et le test du renouvellement automatique. Le processus utilise Certbot avec le plugin dns-infomaniak pour interagir avec les DNS Infomaniak.
Ce second article de la série détaille la configuration avancée d’un nœud Proxmox VE sur un serveur dédié Scaleway avec une seule IP publique. L’auteur explique comment exposer plusieurs services (comme Garage S3 et l’interface Proxmox) de manière sécurisée via HTTPS, en utilisant Caddy comme reverse proxy avec gestion automatique des certificats SSL via Let’s Encrypt. Le guide couvre la configuration d’un réseau privé avec NAT, la création de règles de pare-feu Proxmox à trois niveaux (datacenter, nœud, VM/conteneur), et le dépannage des problèmes courants (DNS, ports, certificats, erreurs 502). Une attention particulière est portée sur l’identification des flux réseau internes et l’adaptation des IPSET pour éviter les blocages involontaires. L’objectif est de centraliser et sécuriser l’accès aux services tout en automatisant la gestion des certificats.
L'article aborde l'utilisation des courbes elliptiques pour les certificats SSL, offrant une alternative robuste et légère aux clés RSA traditionnelles. Il explique comment générer un certificat auto-signé avec OpenSSL en utilisant des courbes elliptiques, en détaillant les étapes pour lister les courbes disponibles, créer une clé et un certificat. L'auteur partage également une méthode pour vérifier la correspondance entre une clé et un certificat, cruciale pour l'administration système. Enfin, il mentionne l'utilisation d'acme.sh pour générer des certificats avec Let's Encrypt, soulignant la simplicité et l'efficacité des courbes elliptiques dans la cryptographie moderne.
Un journal qui explique bien à quoi servait / sert OCSP et pourquoi Let's Encrypt arrête ce service
Si ça peut dépanner certains
Tout est dans le titre
Tout est dans le titre
Tout est dans le titre
Tout est dans le titre... sauf que ça concerne Ansible et nginx aussi
Tout est dans le titre
L'auteur explique la mise en place et le déploiement d'un site statique généré grâce à Hugo
Dans la partie précédente https://blog.blaisot.org/letsencrypt-wildcard-part1.html l'auteur montrait le process de génération le certificat wildcard. Il restait l'étape d'édition des DNS qu'il décrit ici (avec plusieurs cas pratiques)
Tout est dans le titre
Tout est dans le titre
Tout est dans le titre
Tout est dans le titre