Si le preguntas a un experimentado ingeniero sabio qué piensa sobre cert-manager y por qué todos lo utilizan, seguramente suspirará, te abrazará amistosamente y dirá cansadamente: «Todos lo utilizan porque no hay alternativas razonables. Nuestros ratones lloran, se pinchan, pero siguen viviendo con este cactus. ¿Por qué lo amamos? Porque funciona. ¿Por qué no lo amamos? Porque constantemente salen nuevas versiones que utilizan nuevas características. Y hay que actualizar el clúster una y otra vez. Las versiones antiguas dejan de funcionar, porque hay un complot y un gran y misterioso chamanismo».
Pero los desarrolladores aseguran que con cert-manager 1.0 todo cambiará.
¿Creeremos?
Cert-manager es el controlador nativo para la gestión de certificados en Kubernetes. Con él, se pueden emitir certificados desde diversas fuentes: Let’s Encrypt, HashiCorp Vault, Venafi, pares de claves para firmar y autoconvocados. También permite mantener las claves actualizadas en cuanto a su validez, así como intenta actualizar automáticamente los certificados en el tiempo establecido antes de su vencimiento. Cert-manager se basa en kube-lego y ha utilizado algunas técnicas de otros proyectos similares, como kube-cert-manager.
Notas de la versión
Con la versión 1.0, depositamos nuestra confianza tras tres años de desarrollo del proyecto cert-manager. Durante este tiempo, ha evolucionado significativamente en funcionalidad y estabilidad, pero sobre todo, en comunidad. Hoy vemos cómo muchas personas lo utilizan para proteger sus clústeres de Kubernetes, así como lo implementan en diversas partes del ecosistema. En las últimas 16 versiones se han corregido un montón de errores. Y lo que había que romper, se rompió. Varios enfoques en el trabajo con la API han mejorado su interacción con los usuarios. Hemos solucionado 1500 problemas en GitHub, con un número aún mayor de solicitudes de fusión de 253 miembros de la comunidad.
Con el lanzamiento de la 1.0, afirmamos oficialmente que cert-manager es un proyecto maduro. También prometemos mantener la compatibilidad de nuestra API. v1.
Un enorme agradecimiento a todos los que nos ayudaron a hacer de cert-manager lo que es durante estos tres años. Que la versión 1.0 sea el primero de muchos grandes logros por venir.
El lanzamiento 1.0 es una versión estable con varias áreas priorizadas:
v1API;Comando
kubectl cert-manager status, para ayudar en el análisis de problemas;Utilización de las API estables más recientes de Kubernetes;
Mejoras en el registro;
Mejoras en ACME.
Antes de actualizar, asegúrese de leer las notas de la actualización.
API v1
La versión v0.16 trabajaba con el API v1beta1. Esto añadió algunos cambios estructurales, así como mejoró la documentación de los campos del API. La versión 1.0 se basa en todo esto a través del API v1. Este API es nuestra primera versión estable, al mismo tiempo que ya hemos dado garantías de compatibilidad, pero con el API v1 prometemos mantener la compatibilidad durante años.
Los cambios introducidos (nota: nuestras herramientas de conversión se encargarán de todo por usted):
Certificado:
emailSANsahora se llamaemailAddressesuriSANs—uris
Estos cambios añaden compatibilidad con otros SAN (nombres alternativos de sujeto, nota del traductor), así como con el API de Go. Estamos eliminando este término de nuestro API.
Actualización
Si está utilizando Kubernetes 1.16 o superior, los webhooks de conversión le permitirán trabajar de manera simultánea y fluida con las versiones del API v1alpha2, v1alpha3, v1beta1 y v1. Con ellos podrá utilizar la nueva versión del API sin necesidad de modificar o volver a implementar sus recursos antiguos. Recomendamos encarecidamente actualizar los manifiestos al API v1, ya que las versiones anteriores pronto serán declaradas obsoletas. Los usuarios legacy de la versión cert-manager seguirán teniendo acceso solo a v1, los pasos para la actualización se pueden encontrar .
Comando kubectl cert-manager status
Con las nuevas mejoras en nuestra extensión a kubectl es más fácil investigar problemas relacionados con la no emisión de certificados. kubectl cert-manager status ahora proporciona mucha más información sobre lo que está ocurriendo con los certificados, así como muestra la etapa de emisión del certificado.
Después de instalar la extensión, puede ejecutar kubectl cert-manager status certificate, lo que llevará a buscar el certificado con el nombre especificado y cualquier recurso relacionado, como CertificateRequest, Secret, Issuer, así como Order y Challenges en caso de usar certificados de ACME.
Ejemplo de depuración de un certificado aún no listo:
$ kubectl cert-manager status certificate acme-certificate
Nombre: acme-certificate
Namespace: default
Creado en: 2020-08-21T16:44:13+02:00
Condiciones:
Listo: Falso, Razón: NoExiste, Mensaje: Emisión de certificado ya que el Secret no existe
Emisión: Verdadero, Razón: NoExiste, Mensaje: Emisión de certificado ya que el Secret no existe
Nombres DNS:
- example.com
Eventos:
Tipo Razón Edad De Mensaje
---- ------ ---- ---- -------
Normal Emisión 18m cert-manager Emisión de certificado ya que el Secret no existe
Normal Generado 18m cert-manager Almacenada nueva clave privada en el recurso Secret temporal "acme-certificate-tr8b2"
Normal Solicitado 18m cert-manager Creado nuevo recurso CertificateRequest "acme-certificate-qp5dm"
Emisor:
Nombre: acme-issuer
Tipo: Emisor
Condiciones:
Listo: Verdadero, Razón: ACMEAccountRegistered, Mensaje: La cuenta de ACME fue registrada con el servidor ACME
error al encontrar el Secret "acme-tls": secretos "acme-tls" no encontrados
No Antes:
No Después:
Tiempo de Renovación:
CertificateRequest:
Nombre: acme-certificate-qp5dm
Namespace: default
Condiciones:
Listo: Falso, Razón: Pendiente, Mensaje: Esperando la emisión del certificado de la orden default/acme-certificate-qp5dm-1319513028: "pendiente"
Eventos:
Tipo Razón Edad De Mensaje
---- ------ ---- ---- -------
Normal OrdenCreada 18m cert-manager Creado recurso Order default/acme-certificate-qp5dm-1319513028
Orden:
Nombre: acme-certificate-qp5dm-1319513028
Estado: pendiente, Razón:
Autorizaciones:
URL: https://acme-staging-v02.api.letsencrypt.org/acme/authz-v3/97777571, Identificador: example.com, Estado Inicial: pendiente, Wildcard: falso
Desafíos:
- Nombre: acme-certificate-qp5dm-1319513028-1825664779, Tipo: DNS-01, Token: J-lOZ39yNDQLZTtP_ZyrYojDqjutMAJOxCL1AkOEZWw, Clave: U_W3gGV2KWgIUonlO2me3rvvEOTrfTb-L5s0V1TJMCw, Estado: pendiente, Razón: error al obtener la cuenta de servicio de clouddns: secret "clouddns-accoun" no encontrado, Procesando: verdadero, Presentado: falso
El comando también puede ayudar a obtener más información sobre el contenido del certificado. Ejemplo de detalle para un certificado emitido por Letsencrypt:
$ kubectl cert-manager status certificate example
Nombre: example
[...]
Secret:
Nombre: example
País del Emisor: US
Organización del Emisor: Let's Encrypt
Nombre Común del Emisor: Let's Encrypt Authority X3
Uso de Clave: Firma Digital, Cifrado de Clave
Usos de Clave Extendidos: Autenticación del Servidor, Autenticación del Cliente
Algoritmo de Clave Pública: RSA
Algoritmo de Firma: SHA256-RSA
ID de Clave del Sujeto: 65081d98a9870764590829b88c53240571997862
ID de Clave de Autoridad: a84a6a63047dddbae6d139b7a64565eff3a8eca1
Número de Serie: 0462ffaa887ea17797e0057ca81d7ba2a6fb
Eventos:
No Antes: 2020-06-02T04:29:56+02:00
No Después: 2020-08-31T04:29:56+02:00
Tiempo de Renovación: 2020-08-01T04:29:56+02:00
[...]
Uso de las últimas API estables de Kubernetes
Cert-manager fue uno de los primeros en implementar CRDs de Kubernetes. Esto, además de nuestro soporte para versiones de Kubernetes hasta la 1.11, ha llevado a que tuviéramos que mantener obsoleto apiextensions.k8s.io/v1beta1 para nuestros CRD, así como admissionregistration.k8s.io/v1beta1 para nuestros webhooks. Actualmente están obsoletos y serán eliminados en Kubernetes desde la versión 1.22. Con nuestra 1.0 ahora ofrecemos soporte completo apiextensions.k8s.io/v1 y admissionregistration.k8s.io/v1 para Kubernetes 1.16 (donde fueron añadidos) y versiones más recientes. Para los usuarios de versiones anteriores, continuamos ofreciendo soporte v1beta1 en nuestra legacy versión.
Mejorado el registro
En esta versión hemos actualizado la biblioteca de registro a klog/v2, utilizada en Kubernetes 1.19. También estamos verificando cada registro que escribimos para asignarle el nivel correspondiente. Nos guiamos por . Hay cinco (de hecho, seis, nota del traductor) niveles de registro, comenzando desde Error (nivel 0), que solo muestra errores críticos, y terminando con Trace (nivel 5), que ayudará a entender exactamente qué está sucediendo. Con este cambio hemos reducido la cantidad de registros si no necesitas información de depuración al trabajar con cert-manager.
Consejo: por defecto, cert-manager opera en el nivel 2 (Info), puedes sobrescribirlo usando global.logLevel en el gráfico de Helm.
Nota: ver registros es el último recurso para solucionar problemas. Para más información, consulta nuestro .
N.B. del editor: Para aprender más sobre cómo funciona todo esto bajo el capó de Kubernetes, obtener valiosos consejos de practicantes-teóricos y recibir asistencia técnica de calidad, puedes participar en los intensivos en línea , que se llevará a cabo del 28 al 30 de septiembre, y , que se llevará a cabo del 14 al 16 de octubre.
Mejoras ACME
El uso más común de cert-manager probablemente esté asociado con la emisión de certificados de Let’s Encrypt usando ACME. La versión 1.0 destaca por el uso de comentarios de la comunidad para añadir dos mejoras pequeñas pero importantes en nuestro emisor ACME.
Desactivación de la creación de claves de cuenta
Si usas certificados ACME a gran escala, es probable que estés utilizando la misma cuenta en varios clústeres, por lo que tus límites de emisión de certificados afectarán a todos ellos. Esto ya era posible en cert-manager al copiar el secreto especificado en privateKeySecretRef. Este caso de uso era bastante problemático, ya que cert-manager intentaba ser útil y alegremente generaba una nueva clave de cuenta si no la encontraba. Por eso añadimos disableAccountKeyGeneration, para protegerte de este comportamiento; al establecer este parámetro en true — cert-manager no generará la clave y te 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 Let's Encrypt a su propio centro raíz de certificación ISRG Root. Los certificados con firmas cruzadas serán reemplazados por Identrust. Este cambio no requiere modificaciones en la configuración de cert-manager; todos los certificados actualizados o nuevos emitidos después de esta fecha utilizarán la nueva CA raíz.
Let's Encrypt ya está firmando certificados con esta CA y los ofrece como "cadena de certificados alternativa" a través de ACME. En esta versión de cert-manager, existe la posibilidad de especificar el acceso a estas cadenas en la configuración del emisor. En el parámetro preferredChain se puede indicar el nombre de la CA utilizada para emitir el certificado. Si hay un certificado CA disponible que corresponda a 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 por defecto. Esto garantizará que aún así se actualice su certificado después de eliminar la cadena alternativa del lado del emisor ACME.
Ya se pueden obtener certificados firmados ISRG Root, de la siguiente manera:
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 prefiere mantener la cadena IdenTrust — establezca 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"
Tenga en cuenta que esta CA raíz pronto se desaprobará; Let's Encrypt mantendrá esta cadena activa hasta el 29 de septiembre de 2021.
Fuente: habr.com
