Si vous demandez à un ingénieur expérimenté et sage ce qu'il pense de cert-manager et pourquoi tout le monde l'utilise, il soupirera, vous prendra dans ses bras et dira avec fatigue : « Tout le monde l'utilise parce qu'il n'y a pas d'alternatives raisonnables. Nos souris pleurent, se piquent, mais continuent à vivre avec ce cactus. Pourquoi l'aimons-nous ? Parce que ça fonctionne. Pourquoi ne l'aimons-nous pas ? Parce que de nouvelles versions sortent en permanence, qui utilisent de nouvelles fonctionnalités. Et il faut constamment mettre à jour le cluster. Les anciennes versions cessent de fonctionner car il y a un complot et un grand chamanisme mystérieux. »
Mais les développeurs assurent qu'avec cert-manager 1.0 , tout changera.
Croire ?
Cert-manager est le contrôleur de gestion des certificats Kubernetes « natif ». Grâce à lui, il est possible de délivrer des certificats depuis différentes sources : Let’s Encrypt, HashiCorp Vault, Venafi, des paires de clés pour signer et des auto-signés. Il permet également de garder les clés à jour dans le temps, et essaie d'actualiser automatiquement les certificats à un moment donné avant leur expiration. Cert-manager est basé sur kube-lego et a également utilisé certaines techniques d'autres projets similaires, comme kube-cert-manager.
Remarques sur la version
Avec la version 1.0, nous déposons un signe de confiance après trois ans de développement du projet cert-manager. Durant cette période, il a considérablement évolué en fonctionnalités et en stabilité, mais surtout en communauté. Aujourd'hui, nous voyons comment de nombreuses personnes l'utilisent pour protéger leurs clusters Kubernetes, et l'intègrent dans différentes parties de l'écosystème. Dans les 16 dernières versions, une multitude de bogues ont été corrigés. Et ce qu'il fallait casser a été cassé. Plusieurs tentatives de travail avec l'API ont amélioré son interaction avec les utilisateurs. Nous avons résolu 1500 problèmes sur GitHub avec un nombre encore plus grand de demandes de fusion de 253 contributeurs de la communauté.
En lançant 1.0, nous déclarons officiellement que cert-manager est un projet mature. Nous promettons également de maintenir la compatibilité de notre API. v1.
Un immense merci à tous ceux qui nous ont aidés à faire de cert-manager ce qu'il est depuis trois ans ! Que la version 1.0 soit la première d'un grand nombre de futurs accomplissements.
La version 1.0 est une version stable avec plusieurs axes prioritaires :
v1API ;Commande
kubectl cert-manager status, pour aider à analyser les problèmes ;Utilisation des dernières API stables de Kubernetes ;
Journalisation améliorée ;
Améliorations ACME.
Avant la mise à jour, veuillez lire les notes de mise à jour.
API v1
La version v0.16 fonctionnait avec l'API v1beta1. Cela a ajouté certains changements structurels ainsi qu'amélioré la documentation des champs de l'API. La version 1.0 s'appuie sur tout cela via l'API v1. Cette API est notre première version stable, tout en garantissant déjà la compatibilité, mais avec l'API v1 nous promettons de maintenir la compatibilité pendant des années à venir.
Modifications apportées (remarque : nos outils de conversion s'occuperont de tout pour vous) :
Certificat :
emailSANss'appelle maintenantemailAddressesuriSANs—uris
Ces changements ajoutent la compatibilité avec d'autres SAN (noms alternatifs de sujet, note du traducteur), ainsi qu'avec l'API Go. Nous retirons ce terme de notre API.
Mise à jour
Si vous utilisez Kubernetes 1.16+ — les webhooks de conversion vous permettront de travailler de manière transparente avec les versions de l'API v1alpha2, v1alpha3, v1beta1 et v1. Grâce à cela, vous pourrez utiliser la nouvelle version de l'API sans modifier ou redéployer vos anciennes ressources. Nous vous recommandons vivement de mettre à jour les manifestes vers l'API v1, car les versions précédentes seront bientôt déclarées obsolètes. Les utilisateurs legacy de la version cert-manager continueront d'avoir accès uniquement à v1, les étapes de mise à jour peuvent être trouvées .
Commande kubectl cert-manager status
Avec les nouvelles améliorations dans notre extension à kubectl il est devenu plus facile d'explorer les problèmes liés à l'émission de certificats. kubectl cert-manager status fournit maintenant beaucoup plus d'informations sur ce qui se passe avec les certificats et affiche également l'étape d'émission du certificat.
Après avoir installé l'extension, vous pouvez exécuter kubectl cert-manager status certificate, ce qui recherchera le certificat avec ce nom ainsi que toute ressource associée, comme CertificateRequest, Secret, Issuer, ainsi que Order et Challenges dans le cas de l'utilisation de certificats ACME.
Exemple de débogage d'un certificat non prêt :
$ kubectl cert-manager status certificate acme-certificate
Nom : acme-certificate
Namespace : default
Créé le : 2020-08-21T16:44:13+02:00
Conditions :
Prêt : False, Raison : DoesNotExist, Message : Délivrance du certificat en tant que Secret n'existe pas
Délivrance : True, Raison : DoesNotExist, Message : Délivrance du certificat en tant que Secret n'existe pas
Noms DNS :
- example.com
Événements :
Type Raison Âge De Message
---- ------ ---- ---- -------
Normal Délivrance 18m cert-manager Délivrance du certificat en tant que Secret n'existe pas
Normal Généré 18m cert-manager Clé privée nouvelle stockée dans la ressource Secret temporaire "acme-certificate-tr8b2"
Normal Demandé 18m cert-manager Ressource CertificateRequest nouvelle créée "acme-certificate-qp5dm"
Émetteur :
Nom : acme-issuer
Type : Issuer
Conditions :
Prêt : True, Raison : ACMEAccountRegistered, Message : Le compte ACME a été enregistré avec le serveur ACME
Erreur lors de la recherche du Secret "acme-tls" : secret "acme-tls" non trouvé
Pas Avant :
Pas Après :
Temps de Renouvellement :
CertificateRequest :
Nom : acme-certificate-qp5dm
Namespace : default
Conditions :
Prêt : False, Raison : Pending, Message : En attente de la délivrance du certificat de la commande default/acme-certificate-qp5dm-1319513028 : "pending"
Événements :
Type Raison Âge De Message
---- ------ ---- ---- -------
Normal OrderCreated 18m cert-manager Ressource Order créée default/acme-certificate-qp5dm-1319513028
Commande :
Nom : acme-certificate-qp5dm-1319513028
État : pending, Raison :
Autorisations :
URL : https://acme-staging-v02.api.letsencrypt.org/acme/authz-v3/97777571, Identifiant : example.com, État Initial : pending, Wildcard : false
Défis :
- Nom : acme-certificate-qp5dm-1319513028-1825664779, Type : DNS-01, Token : J-lOZ39yNDQLZTtP_ZyrYojDqjutMAJOxCL1AkOEZWw, Clé : U_W3gGV2KWgIUonlO2me3rvvEOTrfTb-L5s0V1TJMCw, État : pending, Raison : erreur lors de l'obtention du compte de service clouddns : secret "clouddns-accoun" non trouvé, Traitement : true, Présenté : false
La commande peut également aider à en savoir plus sur le contenu du certificat. Exemple de détails pour un certificat émis par Letsencrypt :
$ kubectl cert-manager status certificate example
Nom : example
[...]
Secret :
Nom : example
Pays de l'Émetteur : US
Organisation de l'Émetteur : Let's Encrypt
Nom Commun de l'Émetteur : Let's Encrypt Authority X3
Utilisation de la Clé : Signature Numérique, Chiffrement de Clé
Utilisations de Clé Élargies : Authentification du Serveur, Authentification du Client
Algorithme de Clé Publique : RSA
Algorithme de Signature : SHA256-RSA
ID de Clé du Sujet : 65081d98a9870764590829b88c53240571997862
ID de Clé d'Autorité : a84a6a63047dddbae6d139b7a64565eff3a8eca1
Numéro de Série : 0462ffaa887ea17797e0057ca81d7ba2a6fb
Événements :
Pas Avant : 2020-06-02T04:29:56+02:00
Pas Après : 2020-08-31T04:29:56+02:00
Temps de Renouvellement : 2020-08-01T04:29:56+02:00
[...]
Utilisation des API Kubernetes stables les plus récentes
Cert-manager a été l'un des premiers à implémenter les CRDs Kubernetes. Cela, ainsi que notre support des versions de Kubernetes jusqu'à 1.11, a conduit à la nécessité de soutenir les versions obsolètes apiextensions.k8s.io/v1beta1 pour nos CRD, ainsi que admissionregistration.k8s.io/v1beta1 pour nos webhooks. Ils sont désormais obsolètes et seront supprimés dans Kubernetes à partir de la version 1.22. Avec notre version 1.0, nous offrons désormais un support complet apiextensions.k8s.io/v1 et admissionregistration.k8s.io/v1 pour Kubernetes 1.16 (où ils ont été ajoutés) et plus. Pour les utilisateurs des versions précédentes, nous continuons à offrir un support v1beta1 dans notre legacy version.
Journalisation améliorée
Dans cette version, nous avons mis à jour la bibliothèque de journalisation vers klog/v2, utilisée dans Kubernetes 1.19. Nous vérifions également chaque journal que nous écrivons pour lui attribuer le niveau correspondant. Nous nous sommes basés sur . Il existe cinq (en réalité six, note du traducteur) niveaux de journalisation, allant de Error (niveau 0), qui n'affiche que les erreurs majeures, jusqu'à Trace (niveau 5), qui aide à comprendre exactement ce qui se passe. Grâce à ce changement, nous avons réduit la quantité de journaux si vous n'avez pas besoin d'informations de débogage lors de l'utilisation de cert-manager.
Conseil : par défaut, cert-manager fonctionne au niveau 2 (Info), vous pouvez le remplacer en utilisant global.logLevel dans le Helm chart.
Remarque : consulter les journaux est le dernier recours en cas de dépannage. Pour plus d'informations, consultez notre .
N.B. éditeur: Pour en savoir plus sur le fonctionnement interne de Kubernetes, obtenir de précieux conseils de praticiens-enseignants, ainsi qu’une assistance de qualité, vous pouvez participer aux intensifs en ligne , qui se déroulera du 28 au 30 septembre, et , qui se déroulera du 14 au 16 octobre.
Améliorations ACME
L'utilisation la plus courante de cert-manager est probablement liée à l'émission de certificats Let's Encrypt en utilisant ACME. La version 1.0 se distingue par l'utilisation des retours de la communauté pour ajouter deux petites mais importantes améliorations à notre émetteur ACME.
Désactivation de la création de la clé du compte
Si vous utilisez des certificats ACME à grande échelle, vous utilisez probablement le même compte sur plusieurs clusters, donc vos limites d'émission de certificats affecteront tous ces clusters. Cela était déjà possible dans cert-manager en copiant le secret spécifié dans privateKeySecretRef. Ce cas d'utilisation était plutôt bogué, car cert-manager voulait être utile et créait joyeusement une nouvelle clé de compte s'il ne la trouvait pas. C'est pourquoi nous avons ajouté disableAccountKeyGeneration, pour vous protéger de ce comportement ; en définissant cette option sur true , cert-manager ne créera pas de clé et vous avertira qu'aucune clé de compte ne lui a été fournie.
apiVersion: cert-manager.io/v1
kind: Issuer
metadata:
name: letsencrypt
spec:
acme:
privateKeySecretRef:
name: example-issuer-account-key
disableAccountKeyGeneration: false
Chaîne préférée
29 septembre Let’s Encrypt à son propre centre de certification racine ISRG Root. Les certificats avec des signatures croisées seront remplacés par Identrust. Ce changement ne nécessite aucune modification des paramètres du cert-manager, tous les certificats mis à jour ou nouveaux émis après cette date utiliseront le nouveau CA racine.
Let’s Encrypt signe déjà des certificats avec ce CA et les propose comme « chaîne de certificats alternative » via ACME. Dans cette version du cert-manager, il est possible de spécifier l'accès à ces chaînes dans les paramètres de l'émetteur. Dans le paramètre preferredChain vous pouvez indiquer le nom du CA utilisé pour émettre le certificat. Si un certificat CA correspondant à la demande est disponible, il vous délivrera le certificat. Notez que c'est l'option préférée, si rien n'est trouvé, un certificat par défaut sera délivré. Cela garantira que vous mettrez quand même à jour votre certificat après la suppression de la chaîne alternative côté émetteur ACME.
Aujourd'hui déjà, il est possible d'obtenir des certificats signés ISRG Root, ainsi :
apiVersion: cert-manager.io/v1
kind: Issuer
metadata:
name: letsencrypt
spec:
acme:
server: https://acme-v02.api.letsencrypt.org/directory
preferredChain: "ISRG Root X1"
Si vous préférez conserver la chaîne IdenTrust — définissez ce paramètre sur DST Root CA X3:
apiVersion: cert-manager.io/v1
kind: Issuer
metadata:
name: letsencrypt
spec:
acme:
server: https://acme-v02.api.letsencrypt.org/directory
preferredChain: "DST Root CA X3"
Veuillez noter que ce centre de certification racine sera bientôt obsolète, Let’s Encrypt continuera de soutenir cette chaîne active jusqu'au 29 septembre 2021.
Source : habr.com
