🥇Cert-Manager 1.0 está fóra

Se lle preguntas a un enxeñeiro experimentado e sabio que pensa sobre cert-manager e por que o usan todos, o especialista suspirará, abrazará confidencialmente e dirá canso: "Todos o usan, porque non hai alternativas sensatas. Os nosos ratos choran, pinchan, pero seguen vivindo con este cacto. Por que amamos? Porque funciona. Por que non amamos? Porque constantemente se lanzan novas versións que usan novas funcións. E tes que actualizar o clúster unha e outra vez. E as versións antigas deixan de funcionar, porque hai unha conspiración e un gran chamanismo misterioso”.

Pero os desenvolvedores afirman que certificado-xestor 1.0 todo vai cambiar.

Creremos?

Cert-manager é o controlador nativo de xestión de certificados de Kubernetes. Pódese usar para emitir certificados de varias fontes: Let's Encrypt, HashiCorp Vault, Venafi, sinatura e pares de claves autoasinados. Tamén che permite manter as claves actualizadas pola data de caducidade e tamén tenta renovar automaticamente os certificados nun momento especificado antes de que caduquen. Cert-manager está baseado en kube-lego e tamén utilizou algúns trucos doutros proxectos similares como kube-cert-manager.

Notas de lanzamento

Coa versión 1.0, poñemos unha marca de confianza por tres anos de desenvolvemento do proxecto cert-manager. Durante este tempo, desenvolveuse significativamente en funcións e estabilidade, pero sobre todo na comunidade. Hoxe vemos que moitas persoas o utilizan para protexer os seus clústeres de Kubernetes, ademais de implementalo en varias partes do ecosistema. Arranxáronse moitos erros nas últimas 16 versións. E o que había que romper está roto. Varias visitas para traballar coa API melloraron a súa interacción cos usuarios. Resolvemos 1500 problemas en GitHub, con aínda máis solicitudes de extracción de 253 membros da comunidade.

Co lanzamento de 1.0, declaramos oficialmente que cert-manager é un proxecto maduro. Tamén prometemos manter a nosa API compatible v1.

Moitas grazas a todos os que nos axudaron a facer cert-manager durante estes tres anos! Deixa que a versión 1.0 sexa a primeira das moitas cousas importantes que veñen.

A versión 1.0 é unha versión estable con varias áreas prioritarias:

v1 LUME;
Equipo kubectl cert-manager status, para axudar na análise do problema;
Usando as últimas API estables de Kubernetes;
Rexistro mellorado;
Melloras da ACME.

Asegúrese de ler as notas de actualización antes de actualizar.

API v1

A versión v0.16 funcionou coa API v1beta1. Isto engadiu algúns cambios estruturais e tamén mellorou a documentación de campo da API. A versión 1.0 constrúe todo isto cunha API v1. Esta API é a nosa primeira estable, ao mesmo tempo que xa demos garantías de compatibilidade, pero coa API v1 Prometemos manter a compatibilidade durante os próximos anos.

Cambios realizados (nota: as nosas ferramentas de conversión encargaranse de todo por ti):

Certificado:

emailSANs agora chamado emailAddresses
uriSANs - uris

Estes cambios engaden compatibilidade con outras SAN (nomes alternativos do asunto, aprox. tradutor), así como coa API de Go. Eliminamos este termo da nosa API.

Actualizar

Se estás a usar Kubernetes 1.16+, a conversión de webhooks permitirache traballar con versións da API de forma simultánea e sen problemas v1alpha2, v1alpha3, v1beta1 и v1. Con eles, podes usar a nova versión da API sen cambiar nin volver implementar os teus recursos antigos. Recomendamos encarecidamente que actualices os teus manifestos á API v1, xa que as versións anteriores quedarán en desuso en breve. Usuarios legacy as versións de cert-manager só terán acceso a v1, pódense atopar os pasos de actualización aquí.

Comando de estado de kubectl cert-manager

Con novas melloras na nosa extensión a kubectl Fíxose máis doado investigar os problemas asociados á non emisión de certificados. kubectl cert-manager status agora ofrece moita máis información sobre o que está a suceder cos certificados e tamén mostra a fase na que se emite o certificado.

Despois de instalar a extensión, pode executar kubectl cert-manager status certificate <имя-сертификата>, que buscará o certificado co nome de pila e calquera recurso relacionado, como CertificateRequest, Secret, Issuer e Order and Challenges se utiliza certificados de ACME.

Un exemplo de depuración dun certificado que aínda non está listo:

$ 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

O equipo tamén pode axudarche a aprender máis sobre o contido do certificado. Detalles de exemplo para un certificado emitido por 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
[...]

Usando as últimas API estables de Kubernetes

Cert-Manager foi un dos primeiros en implementar os CRD de Kubernetes. Isto, unido á nosa compatibilidade con versións de Kubernetes ata a 1.11, significaba que necesitabamos admitir o legado. apiextensions.k8s.io/v1beta1 tamén para os nosos CRD admissionregistration.k8s.io/v1beta1 para os nosos webhooks. Agora están en desuso e eliminaranse en Kubernetes da versión 1.22. Co noso 1.0 agora ofrecemos soporte completo apiextensions.k8s.io/v1 и admissionregistration.k8s.io/v1 para Kubernetes 1.16 (onde se engadiron) e posteriores. Para os usuarios de versións anteriores, seguimos ofrecendo soporte v1beta1 no noso legacy versións.

Rexistro mellorado

Nesta versión, actualizamos a biblioteca de rexistro a klog/v2, usado en Kubernetes 1.19. Tamén revisamos cada revista que escribimos para asegurarnos de que se lle asigna o nivel adecuado. Nós guiámonos por isto orientación de Kubernetes. Hai cinco (de feito, seis, aprox. tradutor) niveis de rexistro a partir de Error (nivel 0), que só imprime erros importantes e remata con Trace (nivel 5), que che axudará a descubrir exactamente o que está a suceder. Con este cambio reducimos o número de rexistros se non precisa información de depuración ao executar cert-manager.

Consello: de forma predeterminada, cert-manager execútase no nivel 2 (Info), podes anular isto usando global.logLevel no cadro de Helm.

Nota: Ver os rexistros é o último recurso para solucionar problemas. Para máis información consulta o noso liderado.

Editor n.b.: Para obter máis información sobre como funciona todo baixo o capó de Kubernetes, obter valiosos consellos de profesores en exercicio, así como axuda de soporte técnico de calidade, podes participar en cursos intensivos en liña Base Kubernetes, que se celebrará do 28 ao 30 de setembro, e Kubernetes Mega, que terá lugar do 14 ao 16 de outubro.

Melloras da ACME

O uso máis común de cert-manager probablemente estea relacionado coa emisión de certificados de Let's Encrypt mediante ACME. A versión 1.0 destaca por usar comentarios da comunidade para engadir dúas pequenas pero importantes melloras ao noso emisor ACME.

Desactivar a xeración de claves da conta

Se usas certificados ACME en grandes volumes, é probable que esteas a usar a mesma conta en varios clústeres, polo que as restricións de emisión de certificados aplicaranse a todos eles. Isto xa era posible en cert-manager ao copiar o segredo especificado en privateKeySecretRef. Este caso de uso tivo bastantes erros porque o xestor de certificados intentou ser útil e creou felizmente unha nova clave de conta se non atopaba unha. Por iso engadimos disableAccountKeyGenerationpara protexelo deste comportamento configurando esta opción como true - cert-manager non xerará unha chave e avisará de que non se lle deu unha clave de conta.

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

Cadea preferida

29 de setembro Imos cifrar pasará á súa propia autoridade de certificación raíz ISRG Root. Os certificados asinados cruzados serán substituídos por Identrust. Este cambio non require cambios na configuración do xestor de certificados; todos os certificados actualizados ou novos emitidos despois desta data utilizarán a nova CA raíz.

Let's Encrypt xa asina certificados con esta CA e ofréceos como unha "cadea de certificados alternativa" a través de ACME. Esta versión de cert-manager ten a capacidade de configurar o acceso a estas cadeas na configuración do emisor. No parámetro preferredChain pode especificar o nome da CA en uso, coa que se emitirá o certificado. Se hai un certificado de CA dispoñible que coincida coa solicitude, emitiráche un certificado. Teña en conta que esta é a opción preferida; se non se atopa nada, emitirase un certificado predeterminado. Isto asegurarase de que aínda renovará o seu certificado despois de eliminar a cadea alternativa do emisor ACME.

Hoxe podes recibir certificados asinados ISRG Root, Entón:

apiVersion: cert-manager.io/v1
kind: Issuer
metadata:
  name: letsencrypt
spec:
  acme:
    server: https://acme-v02.api.letsencrypt.org/directory
    preferredChain: "ISRG Root X1"

Se prefires deixar a cadea IdenTrust — Establecer este parámetro en 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"

Ten en conta que esta CA raíz quedará en desuso en breve, Let's Encrypt manterá esta cadea activa ata o 29 de setembro de 2021.

Fonte: www.habr.com

cert-manager 1.0 lanzado