Qui n’a jamais vu de site web avec une belle alerte de sécurité à cause d’un certificat expiré ?
Je vous propose un blogpost ceinture… et bretelles pour ne pas vous retrouver dans cette situation, le tout sur Kubernetes !
Certificat X.509, kézako ?
Les certificats X.509 participent à la sécurité de diverses actions dans notre monde Cloud Native. Ils sont très largement utlisés pour garantir la sécurité des échanges via HTTPS. Les APIs que nous utilisons tous en dépendent donc également.
Si vous souhaitez creuser le sujet, savoir dans quel cadre utiliser un certificat de ce type, je vous invite à regarder ce qu’une PKI peut vous apporter. Aujourd’hui, je vais me concentrer sur l’utilisation qui en est faite dans le cadre d’un cluster Kubernetes.
Les certificats X.509 contiennent principalement des informations d’identification. Ils utilisent une signature basée sur un chiffrement RSA ou ECDSA pour garantir leur authenticité et intégrité.
Pour parfaire le concept, les certificats ne doivent pas rester valables indéfiniment. Chacun d’entre eux possède une période de validité, qui une fois dépassée rend le certificat complètement obsolète. Vous voyez venir le problème : l’expiration d’un certificat peut mettre à mal n’importe quelle application, n’importe quel service. Ils doivent donc être minutieusement surveillés et renouvelés au besoin, sous peine de passer un très mauvais moment…
La sécurité d’un certificat repose sur celle de l’organisme qui le signe. Historiquement, les certificats étaient émis par des organisations connues et de confiance (Verisign, DigiCert, …). Les entreprises facturaient la signature selon la durée de validité du certificat et le niveau de vérification attendu.
A l’ère du Cloud Native, la demande en certificats a explosé et ce mécanisme est vite devenu obsolète. C’est pour répondre à ce problème qu’est né Let’s Encrypt, une plateforme permettant d’obtenir automatiquement et gratuitement des certificats, sans pour antant en altérer la sécurité (tout un programme quoi !).
Le résultat, ce sont des certificats de courte durée… à renouveler… très souvent !
Renouveler ses certificats très souvent
Avec Let’s Encrypt donc, les certificats signés ne sont valables que 3 mois. Mais comme moi vous adorez Kubernetes, et il doit y avoir une solution pour automatiser ca ?
Ne cherchez pas plus loin, Cert Manager est là pour vous. Il automatise complètement la création des certificats et les renouvelle au besoin.
Pour les spécialistes, quelques informations à ajouter dans votre objet Ingress et roulez jeunesse…
En plus de pouvoir être utilisés pour des applications qui tournent sur le cluster, les certificats X.509 sont aussi utilisés en interne par Kubernetes, afin d’authentifier les communications avec le serveur API ou entre ses différents composants. Ces certificats sont répartis un peu partout sur le cluster : certains sont sur les noeud principaux (nommés master, ou control plane), certains sur tous les noeuds et d’autres directement dans la base de donnée de Kubernetes (sous forme de Secret).
En plus de ne pas être centralisés, ces certificats ne sont pas tous renouvelés automatiquement, cela dépend de l’applicatif qui les gère. Dans le cas de Kubernetes, cela dépend de la façon dont il a été installé :
- Un cluster créé avec
kubeadmne renouvelle aucun certificat par défaut. Par conséquent, après la période de validité initiale (variant de 6 mois à un an), le cluster ne sera plus en état de fonctionner sans intervention humaine. Il faut donc les mettre à jour régulièrement ! - Si vous utlisez une distribution Kubernetes comme Rancher ou OpenShift, tout est fait pour vous automatiquement.
Bref, ça dépend du capitaine ! Une tâche non automatisée ou une automatisation mal configurée et c’est l'indisponibilité assurée !
Je résume : afin de garantir la disponibilité d’une infrastructure, il est primordial de s’assurer qu’aucun de ses certificats ne soit proche d’expirer !
Superviser le renouvellement des certificats dans une infrastructure sous Kubernetes
La majorité des infrastructures Cloud Native utilisent la métrologie pour superviser, notamment via Prometheus. Il serait intéressant d’y exposer les informations des certificats du cluster, afin de déclencher une alerte en cas d’expiration proche.
C’est là ou je dis tada !!! : l'exporteur de certificats X.509 est la solution open-source en Go pour faire face a ces problèmes. Bon ok je suis un gros contributeur donc pas tout à fait impartial ;) Jugez par vous même !
Il permet d’exposer à Prometheus des informations sur les certificats :
- Présents dans des fichiers sur un noeud : l’utilisateur peut renseigner les chemins vers les fichiers qui contiennent un ou plusieurs certificats au format PEM. Avec la configuration appropriée, il est donc possible de superviser n’importe quel système basé sur des certificats dans des fichiers.
- Embarqués dans des fichiers de configuration YAML : l’outil a été pensé pour le monitoring de clusters Kubernetes, qui utilisent des certificats embarqués en base64 dans des fichers de configuration YAML. Il arrive aussi que ces fichiers YAML continennent un chemin vers un fichier au format PEM : l’exporteur s’occupe de tout.
- Stockés sous forme d’un Secret Kubernetes : cela inclut, entre autres, tous les certificats d’applications (présents et futurs) gérés par Cert Manager, et également tous les Secret de type TLS.
En plus de leur expiration, l’exporteur collecte les informations contenues dans le distinguished name du certificat (ex: le nom de domaine dans le cas d’un certificat HTTPS), permettant de faire du filtrage avancé sur les métriques. Il est possible de les afficher sur un dashboard Grafana, afin de visualiser l’état de tous les certificats en un clein d’oeil.
Mais la fonctionnalité numéro 1 reste de mettre en place des alertes afin d’être notifié à l’avance d’une expiration non prévue de certificat !
Comment installer x.509 Certificate Exporter ?
L’installation peut se faire en deux commandes via Helm.
# add our charts repository
helm repo add enix https://charts.enix.io
# install for TLS Secrets monitoring with prometheus-operator support
helm install x509-certificate-exporter enix/x509-certificate-exporter
Par défaut seul les Secrets sont supervisés, mais le Helm chart est configurable, et si compiler du Go ne vous fait pas peur, le code source est disponible ici.
Le projet est déjà utilisé en production sur plusieurs clusters de tous types, notamment sur nos infrastructures Enix et celles de nos clients et partenaires.
Votre retour est toujours apprécié et écouté. Venez nous faire part de vos idées d’amélioration dans les issues du projet !
Si vous appréciez le logiciel, votre star sur GitHub et Artifact Hub est la bienvenue aussi ;)
Au fait ! On travaille aussi sur d’autres projets Cloud Native, ici chez Enix.
Ne ratez pas nos prochains articles DevOps et Cloud Native! Suivez Enix sur Twitter!