🥇Cert-manager 1.0 llançat

Si preguntes a un enginyer experimentat i savi què pensa del cert-manager i per què l'utilitza tothom, l'especialista sospirarà, l'abraçarà confidencialment i dirà cansat: “Tothom ho fa servir, perquè no hi ha alternatives sensates. Els nostres ratolins ploren, es punxen, però continuen vivint amb aquest cactus. Per què estimem? Perquè funciona. Per què no estimem? Perquè constantment es publiquen noves versions que utilitzen noves funcions. I heu d'actualitzar el clúster una i altra vegada. I les versions antigues deixen de funcionar, perquè hi ha una conspiració i un gran xamanisme misteriós”.

Però els desenvolupadors afirmen que amb cert-manager 1.0 tot canviarà.

Ens ho creurem?

Cert-manager és un controlador natiu de gestió de certificats de Kubernetes. Es pot utilitzar per emetre certificats de diverses fonts: Let's Encrypt, HashiCorp Vault, Venafi, signatura i parells de claus autofirmats. També us permet mantenir les claus actualitzades i intentar renovar automàticament els certificats en un moment especificat abans que caduquin. Cert-manager es basa en kube-lego, i també utilitza algunes tècniques d'altres projectes similars, com ara kube-cert-manager.

Notes de la versió

Amb la versió 1.0 posem una mostra de confiança en els tres anys de desenvolupament del projecte cert-manager. Durant aquest temps, s'ha desenvolupat significativament en funcionalitat i estabilitat, però sobretot en la comunitat. Avui veiem que moltes persones l'utilitzen per protegir els seus clústers de Kubernetes, a més d'implementar-lo en diverses parts de l'ecosistema. S'han corregit un munt d'errors en els darrers 16 llançaments. I el que s'hauria d'haver trencat es va trencar. Diverses visites a l'API van millorar la seva interacció amb els usuaris. Hem resolt 1500 problemes a GitHub, amb encara més sol·licituds d'extracció de 253 membres de la comunitat.

En llançar la versió 1.0, declarem oficialment que cert-manager és un projecte madur. També ens comprometem a mantenir la nostra API compatible v1.

Moltes gràcies a tots els que ens heu ajudat a crear cert-manager durant aquests tres anys! Que la versió 1.0 sigui la primera de moltes coses fantàstiques que vindran.

La versió 1.0 és una versió estable amb diverses àrees prioritàries:

v1 API;
Equip kubectl cert-manager status, per ajudar a analitzar problemes;
Ús de les últimes API estables de Kubernetes;
Millora del registre;
Millores de l'ACME.

Assegureu-vos de llegir les notes d'actualització abans d'actualitzar.

API v1

La versió v0.16 funcionava amb l'API v1beta1. Això va afegir alguns canvis estructurals i també va millorar la documentació de camp de l'API. La versió 1.0 es basa en tot això amb una API v1. Aquesta API és la nostra primera estable, alhora que ja hem donat garanties de compatibilitat, però amb l'API v1 Ens comprometem a mantenir la compatibilitat durant els propers anys.

Canvis realitzats (nota: les nostres eines de conversió s'encarregaran de tot per vostè):

Certificat:

emailSANs ara anomenat emailAddresses
uriSANs - uris

Aquests canvis afegeixen compatibilitat amb altres SAN (noms alternatius dels temes, aprox. traductor), així com amb l'API Go. Estem eliminant aquest terme de la nostra API.

Actualitzar

Si utilitzeu Kubernetes 1.16+, la conversió de webhooks us permetrà treballar amb versions de l'API simultàniament i sense problemes. v1alpha2, v1alpha3, v1beta1 и v1. Amb ells, podeu utilitzar la nova versió de l'API sense canviar ni tornar a desplegar els vostres antics recursos. Us recomanem que actualitzeu els vostres manifests a l'API v1, ja que les versions anteriors aviat quedaran obsoletes. Usuaris legacy les versions de cert-manager només tindran accés v1, es poden trobar els passos d'actualització aquí.

Ordre d'estat del kubectl cert-manager

Amb noves millores a la nostra extensió a kubectl S'ha tornat més fàcil investigar els problemes associats a la no emissió de certificats. kubectl cert-manager status ara ofereix molta més informació sobre què passa amb els certificats i també mostra l'etapa en què s'emet el certificat.

Després d'instal·lar l'extensió, podeu executar-lo kubectl cert-manager status certificate <имя-сертификата>, que cercarà el certificat amb el nom especificat i qualsevol recurs associat, com ara CertificateRequest, Secret, Issuer i Order and Challenges en el cas dels certificats d'ACME.

Un exemple de depuració d'un certificat que encara no està preparat:

$ 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

L'equip també us pot ajudar a obtenir més informació sobre el contingut del certificat. Detalls d'exemple per a un certificat emès per 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
[...]

Aprofiteu les últimes API estables de Kubernetes

Cert-manager va ser un dels primers a implementar els CRD de Kubernetes. Això, juntament amb el nostre suport per a les versions de Kubernetes fins a la 1.11, significava que havíem de donar suport al llegat. apiextensions.k8s.io/v1beta1 també per als nostres CRD admissionregistration.k8s.io/v1beta1 per als nostres webhooks. Ara estan obsolets i s'eliminaran a Kubernetes a partir de la versió 1.22. Amb el nostre 1.0 ara oferim suport complet apiextensions.k8s.io/v1 и admissionregistration.k8s.io/v1 per a Kubernetes 1.16 (on es van afegir) i posteriors. Per als usuaris de versions anteriors, continuem oferint suport v1beta1 en la nostra legacy versions.

Registre millorat

En aquesta versió hem actualitzat la biblioteca de registre a klog/v2, utilitzat a Kubernetes 1.19. També revisem cada revista que escrivim per assegurar-nos que se'ls assigna el nivell adequat. Ens va guiar per això orientació de Kubernetes. N'hi ha cinc (de fet, sis, aprox. traductor) nivells de registre a partir de Error (nivell 0), que només imprimeix errors importants i acaba amb Trace (nivell 5), que us ajudarà a esbrinar exactament què està passant. Amb aquest canvi hem reduït el nombre de registres si no necessiteu informació de depuració quan executeu cert-manager.

Consell: de manera predeterminada, cert-manager s'executa al nivell 2 (Info), podeu anul·lar-ho utilitzant global.logLevel al gràfic Helm.

Nota: revisar els registres és l'últim recurs per resoldre problemes. Per a més informació consulteu el nostre lideratge.

Editor n.b.: Per obtenir més informació sobre com funciona tot sota el capó de Kubernetes, obtenir consells valuosos de professors en exercici, així com assistència tècnica d'alta qualitat, podeu participar en cursos intensius en línia Base Kubernetes, que se celebrarà del 28 al 30 de setembre, i Kubernetes Mega, que tindrà lloc del 14 al 16 d'octubre.

Millores de l'ACME

L'ús més comú de cert-manager probablement està relacionat amb l'emissió de certificats de Let's Encrypt mitjançant ACME. La versió 1.0 destaca per utilitzar els comentaris de la comunitat per afegir dues millores petites però importants al nostre emissor ACME.

Desactiva la generació de claus del compte

Si utilitzeu certificats ACME en grans volums, és probable que utilitzeu el mateix compte en diversos clústers, de manera que les restriccions d'emissió de certificats s'aplicaran a tots. Això ja era possible a cert-manager en copiar el secret especificat a privateKeySecretRef. Aquest cas d'ús va ser bastant defectuós perquè el gestor de certificats va intentar ser útil i va crear feliçment una nova clau de compte si no en trobava. Per això hem afegit disableAccountKeyGenerationper protegir-vos d'aquest comportament configurant aquesta opció a true - cert-manager no generarà cap clau i us avisarà que no se li ha donat cap clau de compte.

apiVersion: cert-manager.io/v1
kind: Issuer
metadata:
  name: letsencrypt
spec:
  acme:
    privateKeySecretRef:
      name: example-issuer-account-key
    disableAccountKeyGeneration: false

Cadena preferida

29 de setembre Anem a xifrar es mourà a la vostra pròpia autoritat de certificació arrel ISRG Root. Els certificats amb signatura creuada es substituiran per Identrust. Aquest canvi no requereix canvis a la configuració del gestor de certificats; tots els certificats actualitzats o nous emesos després d'aquesta data utilitzaran la nova CA arrel.

Let's Encrypt ja signa certificats amb aquesta CA i els ofereix com a "cadena de certificats alternativa" mitjançant ACME. Aquesta versió de cert-manager té la possibilitat d'establir l'accés a aquestes cadenes a la configuració de l'emissor. En el paràmetre preferredChain Podeu especificar el nom de la CA utilitzada per emetre el certificat. Si hi ha disponible un certificat CA que coincideixi amb la sol·licitud, us emetrà un certificat. Tingueu en compte que aquesta és l'opció preferida; si no es troba res, s'emetrà un certificat predeterminat. Això garantirà que encara renovareu el vostre certificat després d'eliminar la cadena alternativa del costat de l'emissor ACME.

Avui podeu rebre certificats signats ISRG Root, Tan:

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 prefereixes deixar la cadena IdenTrust — Establiu aquest paràmetre a 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"

Tingueu en compte que aquesta CA arrel quedarà obsoleta aviat, Let's Encrypt mantindrà aquesta cadena activa fins al 29 de setembre de 2021.

Font: www.habr.com

cert-manager 1.0 llançat