La autenticación y autorización al servicio de consulta N1QL en Couchbase funciona de múltiples maneras -
- Pasar credenciales a través de una petición rest - curl http://localhost:8093/query/service?pretty=true -d "statement=select * from system:keyspaces" -u Admin:pwd
- Pasar credenciales utilizando el parámetro con nombre creds y/o el parámetro de consulta - curl http://localhost:8093/query/service?pretty=true -d "statement=select * from system:keyspaces&creds=[{user: "Administrator", "password": "pass"}]"
- Uso de autenticación básica en la solicitud
- Solicitud de cbq (similar a 1,2) utilizando las opciones -u -p -creds y el comando \SET.
- Certificados X.509 para TLS
- Cifrado de nodo a nodo
Con la adición de RBAC, el parámetro de consulta creds se hizo redundante, pero todavía se admite por compatibilidad con versiones anteriores.
El objetivo de añadir compatibilidad con certificados X509 es mejorar el cifrado cliente-servidor mediante un certificado en el que confíe la autoridad de certificación.
Los certificados X.509 permiten la autenticación del servidor y la encriptación de las comunicaciones cliente-servidor. Couchbase soporta tanto autenticación de servidor como de cliente usando certificados X509 y tienes que ser un Administrador completo o un Administrador de Seguridad para gestionar certificados. Este artículo habla sobre el soporte de certificados X.509 del lado del servidor para la autorización en Couchbase. Los clientes también pueden verificar la identidad del servidor de Couchbase, pero eso será discutido en otro artículo.
Los escenarios más comunes para los que se utilizan certificados X509 son cuando los clientes tienen que pasar por Internet, cuando se transfieren datos confidenciales por cable entre la aplicación y Couchbase Server, o entre centros de datos (XDCR) o cuando así lo exigen las normativas de cumplimiento.
¿Qué es un certificado X.509?
Es un certificado de clave pública que se utiliza para distribuir una clave pública, firmada por una autoridad de certificación de confianza que verifica la identidad del servidor. Utilizándolo, un cliente se asegura de que la solicitud no se está enviando a un servidor desconocido. Estos certificados están firmados por un tercero, también conocido como autoridad de certificación. Las CA son entidades que emiten certificados digitales. En realidad, una CA está formada por una serie de CA denominadas jerarquía de CA. Esta jerarquía de CA construye una cadena de confianza en la que se basan todos los certificados de nodos o entidades finales. La cadena no contiene la clave pública de la CA raíz.
En una infraestructura jerárquica de clave pública (PKI) suele haber 3 tipos de jerarquía. De un nivel, de dos niveles y de N niveles. La CA situada en la parte superior de la jerarquía se denomina CA raíz. Todas las CA siguientes son CA intermedias, y la enésima (última) se denomina CA de nodo.
Un punto importante a tener en cuenta es que para confiar en un certificado utilizado para establecer una conexión segura debe haber sido emitido por una CA que esté incluida en el almacén de confianza del dispositivo que se está conectando.
Autoridad de certificación de un solo nivel
Consiste en una única CA es la forma más sencilla de jerarquía de CA, pero no suele utilizarse en producción como una Si se compromete esta CA raíz, se compromete toda la PKI. Aquí la CA raíz es también la CA emisora y todos los certificados inmediatamente inferiores al certificado raíz heredan su fiabilidad.
Autoridad CA de dos niveles
Consiste en una CA Raíz que ha emitido un certificado para una subordinada conocida como CA Intermedia. La diferencia es que los certificados emitidos son de confianza, ya que proceden de una autoridad de confianza a través de la CA intermedia.
Signos de CA raíz-> Signos intermedios de CA -> CA emisora / CA de clúster
Autoridad CA N-Tier
En la mayoría de los despliegues de producción, una jerarquía tiene varias CA. La CA raíz emite certificados a las CA intermedias, que a su vez generan certificados intermedios: se utilizan para firmar certificados de cliente, como un certificado de clúster:
- CA raíz de confianza > CA intermedia > Certificado de clúster
- CA raíz de confianza > CA intermedia 1 > CA intermedia 2.... > CA intermedia n > Certificado de clúster
La jerarquía de dos niveles es un subtipo de la jerarquía de N niveles.
En todos los casos anteriores, la cadena de certificados debe verificarse hasta la CA raíz. La cadena de confianza contiene su certificado, concatenado con todos los certificados intermedios.
Nota aquí - Todos los certificados intermedios deben estar instalados en su servidor: de lo contrario, algunos clientes supondrán que la conexión no es segura. Esto da lugar a advertencias de "no fiable".
Configuración de X.509 en un clúster couchbase
Algunos requisitos previos antes de configurar los certificados -
- El certificado debe ser un certificado de clave RSA en un formato .pem válido
- El certificado no debe ser inválido - La hora actual debe estar comprendida entre válido a partir de y válido para según lo establecido en el cert.
- Utilice una longitud de clave RSA de 2048 bits o superior. (A medida que aumentan las capacidades informáticas, las claves RSA más largas proporcionan mayor seguridad).
- Con un clúster de un solo nodo tendrá 1 directorio correspondiente a los certificados de los nodos. Con un clúster de varios nodos, cree varios directorios correspondientes a cada nodo del clúster: nodo1, nodo2, etc.
- Si tiene varias CA intermedias, asegúrese de apilarlas en el orden correcto en la cadena de certificados.
- La clave privada del nodo y la cadena deben colocarse en ../var/lib/couchbase/inbox relativo al directorio bin de su sistema operativo desde donde se despliegan los exes de servicio/cluster.
Convenciones de denominación
ca.pem - Clave pública de la CA raíz
int1.pem - Clave pública de la CA intermedia (no 1. Si tiene varias CA intermedias, nómbrelas adecuadamente para añadirlas a la cadena en el orden correcto. Esto muestra qué CA intermedia está más cerca del nodo)
nodo1.pem - Clave pública de la CA del Nodo 1 ( nodo2.pem - Clave pública de la CA del Nodo 2 y así sucesivamente )
nodo1.key - Nodo 1 Clave privada de la AC
cadena.pem - Cadena de certificados que contiene la clave pública del nodo y las claves públicas intermedias que firmaron la clave pública del nodo.
Utilizamos la herramienta openssl para crear nuestros certificados. Consulte su documentación para obtener más detalles sobre los propios comandos.
Pasos para configurar certificados X.509
Primer paso - Crear la clave privada raíz
openssl genrsa -out ca.key 2048 2>/dev/null
Generar una clave privada RSA llamada clave.ca (-out nombrearchivo) que son los 2048 bits.
Al generar la clave, se verá el símbolo . o +. Esto indica el progreso en la generación de la clave. El . representa cada número que pasa la prueba y + significa que un número ha pasado una sola ronda de la prueba de primalidad de Miller-Rabin. Cuando se ve la nueva línea significa que la clave se ha generado con éxito y el número (2 números primos) ha pasado todas las pruebas de primalidad. Consulte la documentación de openssl-genrsa para más detalles.
Paso 2 - Generar la clave pública raíz utilizada como CA del clúster
openssl req -new -x509 -days 365 -sha256 -key ca.key -out ca.pem -subj '/C=US/O=Couchbase/CN=Couchbase Root CA' 2>/dev/null
Genera una nueva solicitud de certificado raíz autofirmado (opción -x509) con una firma sha256 (-sha256. Esto significa mayor seguridad) que tiene una validez de 1 año (-days 365 en días). La clave pública ca.pem (-out) se deriva de la clave privada utilizando la opción -key para especificar la clave privada.
Los certificados X.509 tienen un campo Subject Distinguished Name (DN) y también pueden tener varios nombres en la extensión Subject Alternative Name. Se compone de DN relativos.
CN = Nombre común, O = Organización, C = Nombre del país
Se especifica que el emisor del certificado tiene el CN (Common Name) de Couchbase Root CA: como este nombre indica, el certificado será el certificado raíz para Couchbase
Paso 3 - Generar la clave privada intermedia (o claves si se utiliza una jerarquía de N niveles como la descrita anteriormente )
openssl genrsa -out int1.key 2048 2>/dev/null
Paso 4 - Generar la solicitud de firma de certificado intermedio
openssl req -new -key int1.key -out int1.csr -subj '/C=US/O=Couchbase/CN=Couchbase Intermediate CA' 2>/dev/null
Una CSR o solicitud de firma de certificado es una petición enviada por un solicitante a una CA para solicitar un certificado. Puede personalizar: añadir o limitar las capacidades del certificado X.509 mediante un archivo de extensión. Esta información se utilizará en todos los nodos del clúster. Por ejemplo.
cat > v3.ext <<EOF
basicConstraints = CA:FALSE
subjectKeyIdentifier = hash
authorityKeyIdentifier = keyid,emisor:siempre
EOF
Para obtener una lista exhaustiva de todas las extensiones estándar, consulte la sección 4.2 del RFC 5280 sobre X509 PKI y el perfil CRL. - https://tools.ietf.org/html/rfc5280
Paso 5 - Crear el certificado intermedio
openssl x509 -req -in int1.csr -CA ca.pem -CAkey ca.key -CAcreateserial -CAserial rootCA.srl -extfile v3.ext -out int1.pem -days 365 2>/dev/null
Leer del archivo csr y pasar las claves de la CA Raíz a establecer la autoridad del certificado raíz. La clave cifrada de la CA raíz se utiliza para firmar la CSR intermedia. Antes de firmar nada, es necesario configurar un archivo de número de serie para la CA raíz. Esto es para que cada certificado pueda tener un número de serie único. Esto se hace utilizando las opciones -CAcreateserial -CAserial . rootCA.srl es el archivo de número de serie. Es un simple archivo de texto con números ASCII. El certificado se personaliza utilizando las extensiones que definimos anteriormente y es válido durante un año. En se le pedirá una frase de contraseña para el certificado. Introduzca una frase adecuada en respuesta a las preguntas. Recuerda esta frase.
Finalmente tenemos los certificados de CA raíz e intermedia. Ahora es el momento de configurar el certificado de nodo y firmarlo con la CA raíz y la clave intermedia.
Paso 6 - Configurar clave de nodo y CSR
openssl genrsa -out nodo1.key 2048 2>/dev/null
Una vez generada la clave cifrada para el nodo, configure el csr del nodo.
openssl req -new -key nodo1.key -out nodo1.csr -subj "/C=US/O=Couchbase/CN=server1_linux" 2>/dev/null
En este caso, el nombre común definido en el asunto del certificado es el nombre de nodo definido y asignado en /etc/hosts.
Al configurar el nodo csr utilice el nombre del nodo (preferible), la dirección IP o URI con un certificado SAN (nombre alternativo del sujeto).
La forma habitual de especificar la identidad del certificado es a través del nombre común (CN) en el DN de asunto del certificado. Si despliega un certificado en un host multi-homed, es necesario definir un certificado con identidades alternativas utilizando la opción subjectAltName extensión del certificado.
"subjectAltName = IP:172.23.99.49"
Paso 7 - Genere el certificado de nodo utilizando las extensiones adecuadas
openssl x509 -req -in nodo1.csr -CA int1.pem -CAkey int1.key -CAcreateserial \
-CAserial intermedioCA.srl -out nodo1.pem -days 365
Esto es similar a los pasos anteriores para generar el certificado intermedio.
Paso 8 – Generar la cadena de certificados
cat nodo1.pem int1.pem > cadena.pem
Concatene todos los certificados intermedios y de nodo en el orden correcto. El certificado raíz nunca se incluye en la cadena. Esta cadena permitirá al cliente verificar el certificado intermedio contra el certificado raíz.
Paso 9 - Implantar los certificados
- Copie el certificado cifrado de nodo y el certificado de cadena en la carpeta de entrada dentro de ../var/lib/couchbase/inbox en relación con el lugar desde el que se ejecutan los binarios para su sistema operativo y darles los permisos adecuados mediante chmod a+x
- node1.key y chain.pem se copian en ../inbox
- chmod a+x nodo1.key
- chmod a+x chain.pem
- Cárgalos en el servidor
- curl -X POST -data-binary ca.pem http://Administrator:password@172.23.99.49:8091/controller/uploadClusterCA
- curl -X POST http://Administrator:password@172.23.99.49:8091/node/controller/reloadCertificate
Cuando cargas el certificado del cluster en Couchbase, primero se comprueba que es un certificado X.509 válido. A continuación, si los certificados por nodo no están firmados por el certificado de clúster, se muestra una advertencia para cada nodo durante la configuración. A medida que se actualizan los certificados por nodo, de forma que estén firmados por el certificado de clúster, la advertencia para cada nodo desaparece.
Uso de certificados en la consulta CURL() de N1QL o en el shell cbq
Para verificar certificados que han sido firmados por terceros, la librería utiliza los certificados almacenados en la máquina local. Para cada nodo de consulta en un cluster Couchbase, la carpeta ..//var/lib/couchbase/n1qlcerts contiene los certificados necesarios para CURL(). Si los certificados no se encuentran en esta carpeta se produce un error. La opción cacert se utiliza para pasar un nombre de certificado a la función. Si se introduce una ruta, se producirá un error.
select CURL("https://127.0.0.1:18091/pools",{"request": "GET"usuario": "Bucketuser:contraseña", "cacert": "ca.pem"})
Para conectarse mediante el shell, utilice las opciones cacert, cert y key.
./cbq -cacert ca.pem -cert chain.pem -key nodo1.key -engine https://172.23.99.49:18091
Con este artículo, ya sabemos cómo configurar certificados X509 en nuestro servidor y utilizarlos con la consulta N1QL y el shell CBQ. En el próximo artículo profundizaremos en los certificados del lado del cliente.
