{"id":13232,"date":"2022-05-18T11:32:28","date_gmt":"2022-05-18T18:32:28","guid":{"rendered":"https:\/\/www.couchbase.com\/blog\/?p=13232"},"modified":"2025-06-13T23:06:11","modified_gmt":"2025-06-14T06:06:11","slug":"cloud-native-certificates-standard-kubernetes","status":"publish","type":"post","link":"https:\/\/www.couchbase.com\/blog\/es\/cloud-native-certificates-standard-kubernetes\/","title":{"rendered":"Certificados nativos de la nube: est\u00e1ndares de facto para Kubernetes"},"content":{"rendered":"

Couchbase utiliza TLS para garantizar que la comunicaci\u00f3n a trav\u00e9s 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\u00fasteres (cifrado de nodo a nodo) y las solicitudes entre cl\u00fasteres (replicaci\u00f3n entre centros de datos - XDCR). La \u00faltima versi\u00f3n de Couchbase Autonomous Operator (CAO) 2.3, nativo de la nube, ofrece soporte de primera clase para la tecnolog\u00eda de facto <\/span>kubernetes.io\/tls<\/span><\/i> Tipo de secreto para almacenar certificados y la clave asociada.<\/span><\/p>\n

\u00bfQu\u00e9 es TLS?<\/span><\/h2>\n

TLS (transport layer security) es la norma m\u00e1s com\u00fan para proteger la comunicaci\u00f3n entre dos partes a trav\u00e9s de una red. Incluye autenticaci\u00f3n, cifrado e integridad. Su uso m\u00e1s com\u00fan es para asegurar una conexi\u00f3n HTTP. Probablemente se haya topado con \u00e9l al visitar un sitio web HTTPS. El sitio <\/span>S <\/span><\/i>significa seguro. Se representa con un peque\u00f1o candado en la barra de direcciones de algunos navegadores web.<\/span><\/p>\n

Si visualizas el certificado del sitio web, puedes ver campos como: qui\u00e9n lo emiti\u00f3 y cu\u00e1ndo son sus fechas de inicio y fin de validez. En un mundo sencillo, el emisor se conoce como autoridad de certificaci\u00f3n (CA).<\/span><\/p>\n

Una CA es una organizaci\u00f3n de confianza cuya funci\u00f3n es emitir certificados digitales. El sistema operativo de tu ordenador viene con una lista de CAs ya instaladas. Sin embargo, tambi\u00e9n es posible a\u00f1adir nuevas CA en las que conf\u00edes, ya sea porque una CA anterior ha quedado obsoleta y necesita actualizarse o porque quieres autofirmar algo.<\/span><\/p>\n

Encadenamiento de certificados<\/h3>\n

Al confiar en la CA, conf\u00edas en todos los certificados que ha firmado. Siendo realistas, es demasiado peligroso poner a la CA directamente en la l\u00ednea de esa manera, por lo que es m\u00e1s com\u00fan que una CA haya firmado un certificado intermedio y delegue dominios de seguridad separados a los certificados intermedios. Este certificado intermedio tambi\u00e9n puede pasar a crear certificados firmados. Estos certificados finales tienden a ser utilizados por los servidores para presentar a su navegador para conexiones HTTPS.\u00a0<\/span><\/p>\n

Esta firma consecutiva forma lo que se conoce como <\/span>cadena de certificados<\/span><\/i>. Tu navegador recibe un certificado y sube por la cadena hasta llegar a una CA. Si la CA est\u00e1 en tu lista de CAs de confianza, el handshake contin\u00faa y obtienes una conexi\u00f3n segura. Supongamos que la CA no aparece en el almac\u00e9n de confianza. En ese caso, aparece un error en el navegador an\u00e1logo a \"<\/span>autoridad de certificaci\u00f3n no v\u00e1lida<\/span><\/i>“.\u00a0<\/span><\/p>\n

Para comprobar la validez del certificado de un servidor, se puede descodificar la firma del certificado utilizando la clave p\u00fablica de la CA (que est\u00e1 disponible en su certificado) y validarla. El \u00e9xito en este proceso demuestra que efectivamente firmaron el certificado y no un tercero malintencionado.<\/span><\/p>\n

Esto significa que cualquiera con la clave privada podr\u00eda hacerse pasar por la CA original, raz\u00f3n por la que se tiende a utilizar certificados intermedios. En lugar de que todos los certificados emitidos sean inv\u00e1lidos por una CA comprometida, s\u00f3lo lo es una parte de la cadena.\u00a0<\/span><\/p>\n

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\u00fablica complementaria de la clave privada que se incluye en el certificado final firmado. Siguiendo la misma l\u00f3gica, esta clave privada demuestra que el servidor est\u00e1 utilizando un certificado que realmente posee, ya que la informaci\u00f3n est\u00e1 firmada digitalmente y es verificable utilizando la clave p\u00fablica del certificado.<\/span><\/p>\n

TLS, Kubernetes y Couchbase Cloud-Native CAO<\/span><\/h2>\n

Kubernetes proporciona un est\u00e1ndar para almacenar estos certificados y claves privadas con un <\/span>kubernetes.io\/tls<\/span><\/i> spec. Al establecer un est\u00e1ndar, significa que todos los sistemas generar\u00e1n y consumir\u00e1n certificados y claves TLS en un formato coherente, lo que permitir\u00e1 una mejor interoperabilidad. Con la \u00faltima versi\u00f3n de CAO 2.3, se recomienda a los usuarios que utilicen secretos conformes a esta especificaci\u00f3n.<\/span><\/p>\n

Anteriormente, en CAO 2.1, los secretos TLS se proporcionaban con la opci\u00f3n <\/span>pkey.key<\/span><\/i> y <\/span>cadena.pem <\/span><\/i>esto es un artefacto de las rutas codificadas en el servidor Couchbase:<\/span><\/p>\n

apiVersion: v1\r\ndata:\r\n\u00a0\u00a0chain.pem: LS0tL\u2026\r\n\u00a0\u00a0pkey.key: LS0tL\u2026\r\nkind: Secret\r\ntype: Opaque<\/pre>\n
El inconveniente de este formato era que no ofrec\u00eda una interoperabilidad muy buena con sistemas de gesti\u00f3n de certificados de terceros.<\/span><\/p>\n
A continuaci\u00f3n se public\u00f3 CAO 2.2 con soporte para <\/span>cert-manager<\/span><\/i>. <\/span>La compatibilidad se consigui\u00f3 creando una capa de traducci\u00f3n que renombr\u00f3 los archivos y tambi\u00e9n reescribi\u00f3 la clave del <\/span>PKCS#8<\/span><\/i> al formato PKCS#1 requerido si es necesario, ampliando as\u00ed el soporte TLS que proporciona Couchbase Server.<\/span><\/p>\n
Los secretos del TLS <\/span>proporcionado por cert-manager<\/em> son una ligera extensi\u00f3n de los nativos <\/span>kubernetes.io\/tls<\/span><\/i> espec.<\/span><\/p>\n
\"TLS<\/p>\n
Esta especificaci\u00f3n ampliada utiliza un <\/span>ca.crt<\/span><\/i> para proporcionar el certificado CA ra\u00edz responsable de la firma del certificado TLS correspondiente almacenado en el campo <\/span>tls.crt<\/span><\/i> campo.<\/span><\/p>\n
\"Cloud-native<\/p>\n
Se consigue una mejor conformidad separando el <\/span>ca.crt<\/span><\/i> en un secreto de CA independiente. Esto proporciona una integraci\u00f3n directa con un mayor alcance de<\/span> sistemas de gesti\u00f3n TLS de terceros, permitiendo a los sistemas de gesti\u00f3n TLS gestionar la generaci\u00f3n y rotaci\u00f3n de certificados.<\/span><\/p>\n
Adem\u00e1s, los servidores que ejecutan Couchbase Server 7.1 y CAO 2.3 pueden utilizar la funci\u00f3n <\/span>spec.networking.tls.rootCAs<\/span><\/i> para crear un trust pool. Los grupos de confianza permiten al Servidor Couchbase validar certificados contra m\u00faltiples CAs. Couchbase Server puede usar una CA, mientras valida certificados de cliente contra una cantidad arbitraria de CAs separadas.\u00a0<\/span><\/p>\n
Esto permite que los certificados de cliente se actualicen poco a poco seg\u00fan sea necesario, en lugar de requerir una rotaci\u00f3n de todos los certificados de cliente simult\u00e1neamente. Dado que el secreto que almacena la informaci\u00f3n de CA es del est\u00e1ndar TLS de Kubernetes, los secretos de CA pueden ser importados directamente por CAO sin necesidad de intervenci\u00f3n manual.<\/span><\/p>\n