Certificados nativos de la nube: estándares de facto para Kubernetes

Couchbase utiliza TLS para garantizar que la comunicación a través de la red sea segura, evitando que terceros malintencionados escuchen o manipulen las solicitudes, por ejemplo, las solicitudes de los clientes, las solicitudes entre clústeres (cifrado de nodo a nodo) y las solicitudes entre clústeres (replicación entre centros de datos - XDCR). La última versión de Couchbase Autonomous Operator (CAO) 2.3, nativo de la nube, ofrece soporte de primera clase para la tecnología de facto kubernetes.io/tls Tipo de secreto para almacenar certificados y la clave asociada.

¿Qué es TLS?

TLS (transport layer security) es la norma más común para proteger la comunicación entre dos partes a través de una red. Incluye autenticación, cifrado e integridad. Su uso más común es para asegurar una conexión HTTP. Probablemente se haya topado con él al visitar un sitio web HTTPS. El sitio S significa seguro. Se representa con un pequeño candado en la barra de direcciones de algunos navegadores web.

Si visualizas el certificado del sitio web, puedes ver campos como: quién lo emitió y cuándo son sus fechas de inicio y fin de validez. En un mundo sencillo, el emisor se conoce como autoridad de certificación (CA).

Una CA es una organización de confianza cuya función es emitir certificados digitales. El sistema operativo de tu ordenador viene con una lista de CAs ya instaladas. Sin embargo, también es posible añadir nuevas CA en las que confíes, ya sea porque una CA anterior ha quedado obsoleta y necesita actualizarse o porque quieres autofirmar algo.

Encadenamiento de certificados

Al confiar en la CA, confías en todos los certificados que ha firmado. Siendo realistas, es demasiado peligroso poner a la CA directamente en la línea de esa manera, por lo que es más común que una CA haya firmado un certificado intermedio y delegue dominios de seguridad separados a los certificados intermedios. Este certificado intermedio también puede pasar a crear certificados firmados. Estos certificados finales tienden a ser utilizados por los servidores para presentar a su navegador para conexiones HTTPS. 

Esta firma consecutiva forma lo que se conoce como cadena de certificados. Tu navegador recibe un certificado y sube por la cadena hasta llegar a una CA. Si la CA está en tu lista de CAs de confianza, el handshake continúa y obtienes una conexión segura. Supongamos que la CA no aparece en el almacén de confianza. En ese caso, aparece un error en el navegador análogo a "autoridad de certificación no válida“. 

Para comprobar la validez del certificado de un servidor, se puede descodificar la firma del certificado utilizando la clave pública de la CA (que está disponible en su certificado) y validarla. El éxito en este proceso demuestra que efectivamente firmaron el certificado y no un tercero malintencionado.

Esto significa que cualquiera con la clave privada podría hacerse pasar por la CA original, razón por la que se tiende a utilizar certificados intermedios. En lugar de que todos los certificados emitidos sean inválidos por una CA comprometida, sólo lo es una parte de la cadena. 

Para solicitar un certificado firmado, el usuario final crea una clave privada y una solicitud de firma de certificado (CSR). La CSR contiene la clave pública complementaria de la clave privada que se incluye en el certificado final firmado. Siguiendo la misma lógica, esta clave privada demuestra que el servidor está utilizando un certificado que realmente posee, ya que la información está firmada digitalmente y es verificable utilizando la clave pública del certificado.

TLS, Kubernetes y Couchbase Cloud-Native CAO

Kubernetes proporciona un estándar para almacenar estos certificados y claves privadas con un kubernetes.io/tls spec. Al establecer un estándar, significa que todos los sistemas generarán y consumirán certificados y claves TLS en un formato coherente, lo que permitirá una mejor interoperabilidad. Con la última versión de CAO 2.3, se recomienda a los usuarios que utilicen secretos conformes a esta especificación.

Anteriormente, en CAO 2.1, los secretos TLS se proporcionaban con la opción pkey.key y cadena.pem esto es un artefacto de las rutas codificadas en el servidor Couchbase:

El inconveniente de este formato era que no ofrecía una interoperabilidad muy buena con sistemas de gestión de certificados de terceros.

A continuación se publicó CAO 2.2 con soporte para cert-manager. La compatibilidad se consiguió creando una capa de traducción que renombró los archivos y también reescribió la clave del PKCS#8 al formato PKCS#1 requerido si es necesario, ampliando así el soporte TLS que proporciona Couchbase Server.

Los secretos del TLS proporcionado por cert-manager son una ligera extensión de los nativos kubernetes.io/tls espec.

Esta especificación ampliada utiliza un ca.crt para proporcionar el certificado CA raíz responsable de la firma del certificado TLS correspondiente almacenado en el campo tls.crt campo.

Se consigue una mejor conformidad separando el ca.crt en un secreto de CA independiente. Esto proporciona una integración directa con un mayor alcance de sistemas de gestión TLS de terceros, permitiendo a los sistemas de gestión TLS gestionar la generación y rotación de certificados.

Además, los servidores que ejecutan Couchbase Server 7.1 y CAO 2.3 pueden utilizar la función spec.networking.tls.rootCAs para crear un trust pool. Los grupos de confianza permiten al Servidor Couchbase validar certificados contra múltiples CAs. Couchbase Server puede usar una CA, mientras valida certificados de cliente contra una cantidad arbitraria de CAs separadas. 

Esto permite que los certificados de cliente se actualicen poco a poco según sea necesario, en lugar de requerir una rotación de todos los certificados de cliente simultáneamente. Dado que el secreto que almacena la información de CA es del estándar TLS de Kubernetes, los secretos de CA pueden ser importados directamente por CAO sin necesidad de intervención manual.

• Leer CAO 2.3 Conceptos en la documentación de Couchbase para más información.