🥇Cert-manager 1.0 est sorti

Si vous demandez à un ingénieur expérimenté et avisé ce qu'il pense de cert-manager et pourquoi tout le monde l'utilise, alors le spécialiste soupirera, l'embrassera en toute confiance et dira avec lassitude : "Tout le monde l'utilise, car il n'y a pas d'alternative sensée. Nos souris pleurent, piquent, mais continuent de vivre avec ce cactus. Pourquoi aime-t-on ? Parce que ça marche. Pourquoi n'aimons-nous pas ? Parce que de nouvelles versions sortent constamment et utilisent de nouvelles fonctionnalités. Et vous devez mettre à jour le cluster encore et encore. Et les anciennes versions cessent de fonctionner, car il y a un complot et un grand chamanisme mystérieux.

Mais les développeurs affirment que gestionnaire de certificats 1.0 tout va changer.

Crois le?

Cert-manager est le contrôleur natif de gestion des certificats Kubernetes. Il peut être utilisé pour émettre des certificats à partir de diverses sources : Let's Encrypt, HashiCorp Vault, Venafi, signature et paires de clés auto-signées. Il vous permet également de garder les clés à jour par date d'expiration et essaie également de renouveler automatiquement les certificats à une heure spécifiée avant leur expiration. Cert-manager est basé sur kube-lego et a également utilisé quelques astuces d'autres projets similaires tels que kube-cert-manager.

Notes de version

Avec la version 1.0, nous mettons une marque de confiance pour trois années de développement du projet cert-manager. Pendant ce temps, il a considérablement évolué dans la fonctionnalité et la stabilité, mais surtout dans la communauté. Aujourd'hui, nous voyons de nombreuses personnes l'utiliser pour sécuriser leurs clusters Kubernetes ainsi que le déployer dans diverses parties de l'écosystème. De nombreux bugs ont été corrigés dans les 16 dernières versions. Et ce qui devait être brisé est brisé. Plusieurs visites pour travailler avec l'API ont amélioré son interaction avec les utilisateurs. Nous avons résolu 1500 253 problèmes sur GitHub avec plus de pull requests de XNUMX membres de la communauté.

Avec la sortie de la version 1.0, nous déclarons officiellement que cert-manager est un projet mature. Nous promettons également de garder notre API compatible v1.

Un grand merci à tous ceux qui nous ont aidés à faire de cert-manager pendant ces trois années ! Que la version 1.0 soit la première de nombreuses grandes choses à venir.

La version 1.0 est une version stable avec plusieurs domaines prioritaires :

v1 API ;
Équipe kubectl cert-manager status, pour aider à l'analyse des problèmes ;
Utilisation des dernières API Kubernetes stables ;
journalisation améliorée ;
Améliorations ACME.

Assurez-vous de lire les notes de mise à niveau avant la mise à niveau.

API v1

La version v0.16 fonctionnait avec l'API v1beta1. Cela a ajouté quelques changements structurels et a également amélioré la documentation du champ API. La version 1.0 s'appuie sur cela avec une API v1. Cette API est notre première stable, en même temps nous avons déjà donné des garanties de compatibilité, mais avec l'API v1 nous promettons de maintenir la compatibilité pour les années à venir.

Modifications apportées (note : nos outils de conversion s'occupent de tout pour vous) :

Certificat:

emailSANs maintenant appelé emailAddresses
uriSANs - uris

Ces modifications ajoutent la compatibilité avec d'autres SAN (noms alternatifs de sujet, environ. traducteur), ainsi qu'avec l'API Go. Nous supprimons ce terme de notre API.

Mettre à jour

Si vous utilisez Kubernetes 1.16+, la conversion des webhooks vous permettra de travailler simultanément et de manière transparente avec les versions d'API v1alpha2, v1alpha3, v1beta1 и v1. Avec ceux-ci, vous pourrez utiliser la nouvelle version de l'API sans modifier ou redéployer vos anciennes ressources. Nous vous recommandons vivement de mettre à niveau vos manifestes vers l'API v1, car les versions précédentes seront bientôt obsolètes. Utilisateurs legacy les versions de cert-manager n'auront toujours accès qu'à v1, les étapes de mise à niveau peuvent être trouvées ici.

commande d'état kubectl cert-manager

Avec de nouvelles améliorations dans notre extension à kubectl il est devenu plus facile d'enquêter sur les problèmes liés à la non-délivrance de certificats. kubectl cert-manager status donne maintenant beaucoup plus d'informations sur ce qui se passe avec les certificats et montre également l'étape de délivrance des certificats.

Après avoir installé l'extension, vous pouvez exécuter kubectl cert-manager status certificate <имя-сертификата>, qui recherchera le certificat avec le nom donné et toutes les ressources associées telles que CertificateRequest, Secret, Issuer et Order and Challenges si vous utilisez des certificats d'ACME.

Un exemple de débogage d'un certificat qui n'est pas encore prêt :

$ kubectl cert-manager status certificate acme-certificate

Name: acme-certificate
Namespace: default
Created at: 2020-08-21T16:44:13+02:00
Conditions:
  Ready: False, Reason: DoesNotExist, Message: Issuing certificate as Secret does not exist
  Issuing: True, Reason: DoesNotExist, Message: Issuing certificate as Secret does not exist
DNS Names:
- example.com
Events:
  Type    Reason     Age   From          Message
  ----    ------     ----  ----          -------
  Normal  Issuing    18m   cert-manager  Issuing certificate as Secret does not exist
  Normal  Generated  18m   cert-manager  Stored new private key in temporary Secret resource "acme-certificate-tr8b2"
  Normal  Requested  18m   cert-manager  Created new CertificateRequest resource "acme-certificate-qp5dm"
Issuer:
  Name: acme-issuer
  Kind: Issuer
  Conditions:
    Ready: True, Reason: ACMEAccountRegistered, Message: The ACME account was registered with the ACME server
error when finding Secret "acme-tls": secrets "acme-tls" not found
Not Before: <none>
Not After: <none>
Renewal Time: <none>
CertificateRequest:
  Name: acme-certificate-qp5dm
  Namespace: default
  Conditions:
    Ready: False, Reason: Pending, Message: Waiting on certificate issuance from order default/acme-certificate-qp5dm-1319513028: "pending"
  Events:
    Type    Reason        Age   From          Message
    ----    ------        ----  ----          -------
    Normal  OrderCreated  18m   cert-manager  Created Order resource default/acme-certificate-qp5dm-1319513028
Order:
  Name: acme-certificate-qp5dm-1319513028
  State: pending, Reason:
  Authorizations:
    URL: https://acme-staging-v02.api.letsencrypt.org/acme/authz-v3/97777571, Identifier: example.com, Initial State: pending, Wildcard: false
Challenges:
- Name: acme-certificate-qp5dm-1319513028-1825664779, Type: DNS-01, Token: J-lOZ39yNDQLZTtP_ZyrYojDqjutMAJOxCL1AkOEZWw, Key: U_W3gGV2KWgIUonlO2me3rvvEOTrfTb-L5s0V1TJMCw, State: pending, Reason: error getting clouddns service account: secret "clouddns-accoun" not found, Processing: true, Presented: false

La commande peut également vous aider à en savoir plus sur le contenu du certificat. Exemple détaillé pour un certificat émis par Letsencrypt :

$ kubectl cert-manager status certificate example
Name: example
[...]
Secret:
  Name: example
  Issuer Country: US
  Issuer Organisation: Let's Encrypt
  Issuer Common Name: Let's Encrypt Authority X3
  Key Usage: Digital Signature, Key Encipherment
  Extended Key Usages: Server Authentication, Client Authentication
  Public Key Algorithm: RSA
  Signature Algorithm: SHA256-RSA
  Subject Key ID: 65081d98a9870764590829b88c53240571997862
  Authority Key ID: a84a6a63047dddbae6d139b7a64565eff3a8eca1
  Serial Number: 0462ffaa887ea17797e0057ca81d7ba2a6fb
  Events:  <none>
Not Before: 2020-06-02T04:29:56+02:00
Not After: 2020-08-31T04:29:56+02:00
Renewal Time: 2020-08-01T04:29:56+02:00
[...]

Utilisation des dernières API Kubernetes stables

Cert-manager a été l'un des premiers à implémenter les CRD Kubernetes. Ceci, et notre prise en charge des versions Kubernetes jusqu'à 1.11, signifiait que nous devions prendre en charge l'héritage apiextensions.k8s.io/v1beta1 pour nos CRD aussi admissionregistration.k8s.io/v1beta1 pour nos webhooks. Ils sont désormais obsolètes et seront supprimés de Kubernetes à partir de la version 1.22. Avec notre 1.0, nous offrons désormais un support complet apiextensions.k8s.io/v1 и admissionregistration.k8s.io/v1 pour Kubernetes 1.16 (où ils ont été ajoutés) et versions ultérieures. Pour les utilisateurs des versions précédentes, nous continuons à offrir une assistance v1beta1 dans notre legacy version.

Journalisation améliorée

Dans cette version, nous avons mis à jour la bibliothèque de journalisation pour klog/v2, utilisé dans Kubernetes 1.19. Nous examinons également chaque journal que nous écrivons pour nous assurer qu'il est affecté au niveau approprié. Nous avons été guidés par ce conseils de Kubernetes. Il y en a cinq (en fait six, environ. traducteur) niveaux de journalisation à partir de Error (niveau 0), qui n'affiche que les erreurs importantes et se termine par Trace (niveau 5) qui vous aidera à savoir exactement ce qui se passe. Avec cette modification, nous avons réduit le nombre de journaux si vous n'avez pas besoin d'informations de débogage lors de l'exécution de cert-manager.

Astuce : cert-manager s'exécute au niveau 2 par défaut (Info), vous pouvez remplacer cela en utilisant global.logLevel à Helmchart.

Remarque : l'affichage des journaux est le dernier recours lors du dépannage. Pour plus d'informations consultez notre leadership.

N.b. de l'éditeur: Pour en savoir plus sur le fonctionnement sous le capot de Kubernetes, obtenir de précieux conseils d'enseignants en exercice, ainsi qu'un support technique de qualité, vous pouvez participer à des intensifs en ligne Base Kubernetes, qui se tiendra du 28 au 30 septembre, et Méga Kubernetesqui aura lieu du 14 au 16 octobre.

Améliorations ACME

L'utilisation la plus courante de cert-manager est probablement liée à l'émission de certificats de Let's Encrypt à l'aide d'ACME. La version 1.0 se distingue par l'utilisation des commentaires de la communauté pour ajouter deux améliorations mineures mais importantes à notre émetteur ACME.

Désactiver la génération de clé de compte

Si vous utilisez des certificats ACME en gros volumes, vous utiliserez probablement le même compte sur plusieurs clusters, de sorte que vos restrictions d'émission de certificats s'appliqueront à tous. Cela était déjà possible dans cert-manager lors de la copie du secret spécifié dans privateKeySecretRef. Ce cas d'utilisation était assez bogué, car cert-manager essayait d'être utile et créait avec plaisir une nouvelle clé de compte s'il n'en trouvait pas. C'est pourquoi nous avons ajouté disableAccountKeyGenerationpour vous protéger de ce comportement si vous définissez cette option sur true - cert-manager ne générera pas de clé et vous avertira qu'il ne lui a pas été fourni de clé de compte.

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 va passer à votre propre autorité de certification racine ISRG Root. Les certificats contresignés seront remplacés par Identrust. Cette modification ne nécessite pas de modifications des paramètres de cert-manager, tous les certificats mis à jour ou nouveaux émis après cette date utiliseront la nouvelle autorité de certification racine.

Let's Encrypt signe déjà des certificats avec cette autorité de certification et les propose comme "chaîne de certificats alternative" via ACME. Dans cette version de cert-manager, il est possible de définir l'accès à ces chaînes dans les paramètres de l'émetteur. En paramètre preferredChain vous pouvez spécifier le nom de l'autorité de certification utilisée, avec laquelle le certificat sera émis. Si un certificat CA correspondant à la demande est disponible, il vous délivrera un certificat. Veuillez noter qu'il s'agit de l'option préférée, si rien n'est trouvé, un certificat par défaut sera émis. Cela garantira que vous renouvellerez toujours votre certificat après avoir supprimé la chaîne alternative du côté de l'émetteur ACME.

Dès aujourd'hui, vous pouvez recevoir des certificats signés par ISRG Root, Alors:

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 tu préfères quitter la chaîne IdenTrust - définissez cette option 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 cette autorité de certification racine sera bientôt obsolète, Let's Encrypt maintiendra cette chaîne active jusqu'au 29 septembre 2021.

Source: habr.com

lancement de cert-manager 1.0