🥇Cert-manager 1.0 ya está disponible

Si le pregunta a un ingeniero sabio y experimentado qué piensa sobre cert-manager y por qué todos lo usan, entonces el especialista suspirará, lo abrazará en confianza y dirá con cansancio: “Todos lo usan, porque no hay alternativas sensatas. Nuestros ratones lloran, pinchan, pero siguen conviviendo con este cactus. ¿Por qué amamos? Porque funciona. ¿Por qué no amamos? Porque constantemente salen nuevas versiones que utilizan nuevas funciones. Y tienes que actualizar el clúster una y otra vez. Y las versiones antiguas dejan de funcionar, porque hay una conspiración y un gran chamanismo misterioso.

Pero los desarrolladores afirman que administrador de certificados 1.0 todo va a cambiar.

Creer?

Cert-manager es el controlador de gestión de certificados nativo de Kubernetes. Se puede utilizar para emitir certificados de varias fuentes: Let's Encrypt, HashiCorp Vault, Venafi, firma y pares de claves autofirmadas. También le permite mantener las claves actualizadas por fecha de vencimiento y también intenta renovar automáticamente los certificados en un momento específico antes de que caduquen. Cert-manager se basa en kube-lego y también ha utilizado algunos trucos de otros proyectos similares, como kube-cert-manager.

Notas de lanzamiento

Con la versión 1.0, ponemos una marca de confianza por tres años de desarrollo del proyecto cert-manager. Durante este tiempo, ha evolucionado significativamente en funcionalidad y estabilidad, pero sobre todo en la comunidad. Hoy en día, vemos a muchas personas usándolo para proteger sus clústeres de Kubernetes, así como para implementarlo en varias partes del ecosistema. Se han solucionado muchos errores en las últimas 16 versiones. Y lo que necesitaba ser roto está roto. Varias visitas para trabajar con la API han mejorado su interacción con los usuarios. Hemos resuelto 1500 problemas en GitHub con más solicitudes de extracción de 253 miembros de la comunidad.

Con el lanzamiento de 1.0, declaramos oficialmente que cert-manager es un proyecto maduro. También prometemos mantener nuestra API compatible v1.

¡Muchas gracias a todos los que nos ayudaron a hacer cert-manager durante estos tres años! Deje que la versión 1.0 sea la primera de muchas cosas importantes por venir.

La versión 1.0 es una versión estable con varias áreas prioritarias:

v1 FUEGO;
Equipo kubectl cert-manager status, para ayudar con el análisis de problemas;
Usando las últimas API estables de Kubernetes;
registro mejorado;
Mejoras ACME.

Asegúrese de leer las notas de actualización antes de actualizar.

API v1

La versión v0.16 funcionó con la API v1beta1. Esto agregó algunos cambios estructurales y también mejoró la documentación del campo API. La versión 1.0 se basa en esto con una API v1. Esta API es nuestra primera estable, a su vez ya hemos dado garantías de compatibilidad, pero con la API v1 Prometemos mantener la compatibilidad en los años venideros.

Cambios realizados (nota: nuestras herramientas de conversión se encargan de todo por usted):

Certificado:

emailSANs ahora llamado emailAddresses
uriSANs - uris

Estos cambios agregan compatibilidad con otras SAN (nombres alternativos de sujeto, aprox. traductor), así como con la API de Go. Estamos eliminando este término de nuestra API.

Actualizar

Si está utilizando Kubernetes 1.16+, la conversión de webhooks le permitirá trabajar simultáneamente y sin problemas con versiones de API v1alpha2, v1alpha3, v1beta1 и v1. Con estos, podrá usar la nueva versión de la API sin cambiar o volver a implementar sus recursos anteriores. Recomendamos enfáticamente actualizar sus manifiestos a la API v1, ya que las versiones anteriores quedarán obsoletas pronto. Usuarios legacy las versiones de cert-manager solo tendrán acceso a v1, se pueden encontrar los pasos de actualización aquí.

Comando de estado de kubectl cert-manager

Con nuevas mejoras en nuestra extensión a kubectl se hizo más fácil investigar los problemas asociados con la no emisión de certificados. kubectl cert-manager status ahora brinda mucha más información sobre lo que sucede con los certificados y también muestra la etapa de emisión del certificado.

Después de instalar la extensión, puede ejecutar kubectl cert-manager status certificate <имя-сертификата>, que buscará el certificado con el nombre dado y cualquier recurso relacionado, como CertificateRequest, Secret, Issuer y Order and Challenges si usa certificados de ACME.

Un ejemplo de depuración de un certificado que aún no 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

El comando también puede ayudarlo a obtener más información sobre el contenido del certificado. Ejemplo detallado de 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
[...]

Uso de las últimas API estables de Kubernetes

Cert-manager fue uno de los primeros en implementar los CRD de Kubernetes. Esto, y nuestra compatibilidad con las versiones de Kubernetes hasta la 1.11, significaba que necesitábamos admitir el legado apiextensions.k8s.io/v1beta1 para nuestros CRD también admissionregistration.k8s.io/v1beta1 para nuestros webhooks. Ahora están en desuso y se eliminarán en Kubernetes a partir de la versión 1.22. Con nuestro 1.0 ahora ofrecemos soporte completo apiextensions.k8s.io/v1 и admissionregistration.k8s.io/v1 para Kubernetes 1.16 (donde se agregaron) y posteriores. Para usuarios de versiones anteriores, seguimos ofreciendo soporte v1beta1 en nuestro legacy versiones.

Registro mejorado

En esta versión, hemos actualizado la biblioteca de registro para klog/v2, utilizado en Kubernetes 1.19. También revisamos cada diario que escribimos para asegurarnos de que se le asigna el nivel adecuado. Nos guiamos por esto orientación de Kubernetes. Hay cinco (en realidad seis, aprox. traductor) niveles de registro a partir de Error (nivel 0), que imprime solo errores importantes y termina con Trace (nivel 5) que te ayudará a saber exactamente lo que está pasando. Con este cambio, hemos reducido la cantidad de registros si no necesita información de depuración al ejecutar cert-manager.

Sugerencia: cert-manager se ejecuta en el nivel 2 de forma predeterminada (Info), puede anular esto usando global.logLevel en Helmchart.

Nota: Ver los registros es el último recurso para solucionar problemas. Para obtener más información, consulte nuestro liderazgo.

Nota del editor: Para obtener más información sobre cómo funciona todo bajo el capó de Kubernetes, obtenga valiosos consejos de profesores en ejercicio, así como ayuda de soporte técnico de calidad, puede participar en cursos intensivos en línea. Base de Kubernetes, que se llevará a cabo del 28 al 30 de septiembre, y Mega de Kubernetesque se llevará a cabo del 14 al 16 de octubre.

Mejoras ACME

El uso más común de cert-manager probablemente esté relacionado con la emisión de certificados de Let's Encrypt usando ACME. La versión 1.0 se destaca por utilizar los comentarios de la comunidad para agregar dos mejoras pequeñas pero importantes a nuestro emisor ACME.

Deshabilitar la generación de claves de cuenta

Si usa certificados ACME en grandes volúmenes, es probable que use la misma cuenta en varios clústeres, por lo que las restricciones de emisión de su certificado se aplicarán a todos ellos. Esto ya era posible en cert-manager al copiar el secreto especificado en privateKeySecretRef. Este caso de uso tuvo bastantes errores, ya que cert-manager trató de ser útil y felizmente creó una nueva clave de cuenta si no encontraba una. Por eso agregamos disableAccountKeyGenerationpara protegerlo de este comportamiento si establece esta opción en true - cert-manager no generará una clave y le advertirá que no se le ha proporcionado una clave de cuenta.

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

Cadena preferida

29 de septiembre Vamos a cifrar pasará a su propia CA raíz ISRG Root. Los certificados con firma cruzada serán reemplazados por Identrust. Este cambio no requiere cambios en la configuración del administrador de certificados, todos los certificados nuevos o actualizados emitidos después de esta fecha utilizarán la nueva CA raíz.

Let's Encrypt ya firma certificados con esta CA y los ofrece como una "cadena de certificados alternativos" a través de ACME. En esta versión de cert-manager, es posible configurar el acceso a estas cadenas en la configuración del emisor. en parámetro preferredChain puede especificar el nombre de la CA en uso, con la que se emitirá el certificado. Si hay disponible un certificado de CA que coincida con la solicitud, se le emitirá un certificado. Tenga en cuenta que esta es la opción preferida; si no se encuentra nada, se emitirá un certificado predeterminado. Esto garantizará que seguirá renovando su certificado después de eliminar la cadena alternativa en el lado del emisor de ACME.

Ya hoy puede recibir certificados firmados por ISRG Root, Asi que:

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 prefieres salir de la cadena IdenTrust - establezca esta opción 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"

Tenga en cuenta que esta CA raíz quedará obsoleta pronto, Let's Encrypt mantendrá esta cadena activa hasta el 29 de septiembre de 2021.

Fuente: habr.com

Lanzamiento de cert-manager 1.0