Clustering¶
Nota
Esta función es actualmente una vista previa técnica con las siguientes limitaciones temporales:
Si se pierde un clúster (se pierde el quórum), el único medio de recuperación es el restablecimiento de fábrica + restauración. Asegúrate de hacer copias de seguridad a menudo. Futuras versiones incluirán medios para recuperar datos en disco.
La configuración activa/pasiva para soportar clusters de dos nodos, ya sea utilizando etcd Learner o Mirror, aún no está disponible.
La hora del sistema entre nodos debe sincronizarse manualmente por ahora. Una futura versión incluirá la sincronización automática del reloj.
NetHSM 4.0 en adelante admite la agrupación en clústeres para sincronizar datos entre varios NetHSM directamente. Esto permite una alta frecuencia de generación de claves, alta disponibilidad y equilibrio de carga. Un clúster NetHSM se basa en etcd que utiliza el algoritmo de consenso Raft para una fuerte consistencia. Esto garantiza que los datos (por ejemplo, las claves) sean correctos en todas las NetHSM en todo momento.
Antes de configurar un clúster NetHSM, familiarícese con esta tecnología y sus limitaciones para evitar interrupciones accidentales y pérdidas de datos. Además de este documento, puede consultar la documentación de etcd.
Operational Redundancy¶
Llamaremos «nodo» a una NetHSM que se espera que forme parte de un clúster. Un clúster de nodos N seguirá funcionando mientras al menos (N/2)+1 nodos estén sanos y accesibles. Esa cantidad mínima de nodos sanos y accesibles se denomina quórum **** .
Esto implica los siguientes escenarios.
Un nodo se cae y sigue habiendo quórum¶
En un clúster de 3 nodos, si uno de ellos falla (se bloquea o se vuelve inalcanzable debido a las condiciones de la red), los otros dos nodos seguirán funcionando y sirviendo peticiones.
Si el nodo que ha fallado aún está sano (por ejemplo, sólo ha sido un problema de red), no podrá funcionar mientras esté aislado (ni siquiera será de sólo lectura).
Sin embargo, si el nodo se recupera, se resincronizará limpiamente con el resto del clúster y volverá a estar operativo, sin perder datos.
Si nunca se recupera, hay que retirarlo del clúster (véase la sección siguiente), restablecerlo a los valores de fábrica y volver a realizar el proceso de unión desde cero.
Se produce una partición de la red y sigue habiendo quórum¶
Esto no es más que una generalización del escenario anterior. En un clúster de 5 nodos en el que, por ejemplo, 3 nodos están en una ubicación física A y 2 nodos están en otra ubicación B, un problema de red que aísle A y B significaría lo siguiente:
Los 3 nodos de la ubicación A cumplen el quórum (3 en este caso), por lo que siguen funcionando.
Los 2 nodos en la ubicación B son no cumplir con el quórum (todavía 3), por lo que dejará de funcionar (incluso de sólo lectura).
Si se resuelve el problema de la red, los 2 nodos volverán a unirse limpiamente a los otros 3.
El Quórum se pierde de forma duradera¶
Un fallo que provoque que todos los subconjuntos del clúster pierdan el quórum hará que el clúster y sus datos se pierdan por completo, a menos que se resuelva el fallo. En este caso, los nodos deben restablecerse de fábrica y debe restaurarse una copia de seguridad.
Esto puede ocurrir, por ejemplo, si falla un único nodo en un clúster de 2 nodos (donde el quórum es 2). En esta situación, el nodo que ha fallado no puede eliminarse limpiamente del clúster a posteriori, porque el nodo sano restante ya está inoperativo al haber perdido el quórum.
De ahí que se aconseje tener siempre un número impar de nodos en un clúster y realizar copias de seguridad con frecuencia.
Para ser claros, temporalmente perder el quórum (por ejemplo, si está reiniciando todos los nodos de un clúster juntos, o un fallo de red temporal aísla los nodos) no es un problema: una vez que suficientes nodos se reconectan (sin tener que volver a unirse manualmente) para alcanzar el quórum, el clúster reanudará su funcionamiento normal. Sólo los fallos permanentes, como particiones de red, desconfiguraciones de red, problemas de autenticación o fallos de hardware, requerirán una acción manual.
Para más información, consulte las PREGUNTAS FRECUENTES de etcd.
Clúster de 2 nodos¶
Un cluster activo/pasivo de dos nodos no está soportado todavía y será añadido en una versión futura. Recomendamos introducir un tercer nodo, ya sea un tercer NetHSM o un «testigo» etcd que podría funcionar en cualquier host. Consulte la siguiente sección «Testigo».
Testigo¶
La naturaleza del clustering con etcd hace que sea más fiable cuantos más nodos haya en el cluster. Como se explica en la sección Redundancia operativa, lo ideal es que los clústeres tengan al menos 3 nodos para tener espacio para fallar, ya que un clúster de 2 nodos fallará por completo si sólo falla uno.
Sin embargo, el diseño de la función es tal que no es necesario añadir un dispositivo NetHSM completo y real a su clúster para alcanzar un número estable de nodos. En su lugar, puede desplegar y añadir un nodo «testigo» usted mismo. Este nodo no es más que una instancia de etcd ejecutándose en la máquina de su elección (o en un contenedor), y conectado al clúster. Los dispositivos reales del clúster lo reconocerán como un nodo normal, y recibirá todos los datos y actualizaciones de los dispositivos (pero, por supuesto, no podrás realizar ninguna operación HSM con él: sólo almacena datos).
Security Considerations¶
El nodo testigo (o cualquiera con acceso a él) tiene acceso directo al backend de almacenamiento de todos los nodos del clúster (por ejemplo, puede volcar todas las entradas y los valores correspondientes con etcdctl get "/" "0").
Sin embargo, con la excepción de la versión de configuración (/config/version, que siempre debe ser «1»), estrictamente todos los valores están encriptados (con una clave de dispositivo para los valores específicos del nodo o las claves de dominio para los demás), lo que garantiza la confidencialidad de los datos sensibles.
Tenga en cuenta, sin embargo, que un nodo malicioso puede:
escribir basura como valor para cualquier entrada del almacén, lo que hará que los nodos fallen al descifrarlo (lo que puede provocar fallos en algunas entradas del sistema).
nombres de entradas de la lista, como usuarios, espacios de nombres y claves, que puede considerar sensibles.
Creating a Cluster¶
Cualquier clúster partirá inicialmente de un único nodo. Los nuevos nodos se unirán al clúster uno a uno.
Preparing Nodes¶
El tráfico de red entre nodos se cifra y autentica mediante su certificado TLS.
Todos los nodos que vayan a formar parte del mismo clúster deben instalar primero una Autoridad de Certificación (CA) común que les permita verificar que los demás nodos son legítimos.
A continuación, supondremos que todos los nodos están recién aprovisionados y operativos.
Networking¶
Nodes must first be reconfigured with their expected final network configuration using the /config/network endpoint (refer to the API documentation).
Creación e instalación de una CA¶
Los usuarios deben crear una CA por sus propios medios y de acuerdo con sus propias limitaciones operativas, asegurándose de que permite al menos el uso de la clave keyCertSign.
Por ejemplo, se puede crear una CA mínima con openssl:
$ openssl genrsa -out CA.key 2048 # create a key
$ openssl req -x509 -new -nodes -key CA.key -sha256 -days 1825 -out CA.pem -addext keyUsage=critical,keyCertSign
Esta CA debe instalarse ahora en cada nodo.
To do this, first generate a Certificate Signing Request (CSR) from the node with the /config/tls/csr.pem endpoint (refer to the API documentation).
Nota
Para autenticar correctamente los nodos, el backend de clustering (etcd) espera que cada nodo tenga un certificado con un campo Subject Alt Names (SAN) correctamente rellenado. En particular, los nodos a los que se espera llegar sólo a través de su IP necesitan tener un SAN de IP adecuado en su certificado. Los SAN de IP pueden solicitarse para el CSR anteponiendo «IP:» a los nombres, como en openssl:
"subjectAltNames": [ "normalname.org", "IP:192.168.1.1" ]
Dado el CSR obtenido (llamémoslo nethsm.csr), podemos entonces generar un certificado para él, listo para ser instalado. Por ejemplo con openssl:
$ openssl x509 -req -days 1825 -in nethsm.csr -CA CA.pem -copy_extensions copy \
-CAkey CA.key -out new_cert.pem -set_serial 01 -sha256
Then install the obtained new_cert.pem with the /config/tls/cert.pem endpoint (refer to the API documentation).
Por último, la CA (CA.pem) ya puede instalarse con el endpoint /config/tls/cluster-ca.pem (consulte la documentación de la API ` <https://nethsmdemo.nitrokey.com/api_docs/index.html>` __). Esto sólo es posible una vez que el certificado TLS instalado esté firmado por ella. En caso contrario, la operación será rechazada.
Nota
Este proceso debe repetirse para cada nodo.
Sincronización del reloj¶
Asegúrese de que cada nodo ha sido aprovisionado con una hora exacta del sistema. Si no es así, ajuste sus relojes con el punto final /config/time.
Adding a New Node¶
Añadir un nodo a un clúster se hace en dos pasos:
registrar la adición al clúster (a través de cualquiera de sus miembros)
indicar al nuevo nodo que se una
Configure a Backup Passphrase¶
En primer lugar, asegúrese de que se ha configurado una frase de contraseña de seguridad en el nodo que se utilizará para registrar un nuevo carpintero (consulte la documentación de la API del punto final /config/backup-passphrase).
Registrar un nuevo nodo¶
Advertencia
El registro de un nodo introduce inmediatamente un nuevo nodo en el clúster, modificando el umbral de quórum, incluso si el nodo no se ha unido todavía. Esto puede inutilizar los nodos existentes hasta que el nuevo nodo se haya unido. Consulte la documentación de la API ` <https://nethsmdemo.nitrokey.com/api_docs/index.html>` __ y la sección Redundancia operativa de este documento.
Tenga a mano la IP del nodo que se unirá. La URL completa ** (también llamada peer URL en etcd terminología) de ese nodo será https://<IP_of_node>:2380 (por ejemplo https://192.168.1.1:2380). El puerto debe ser 2380, así que asegúrate de que cualquier cortafuegos entre los nodos permita el tráfico TCP en ese puerto.
Puede comprobar que la URL es correcta llamando a GET /cluster/members en el nodo que se espera que se una. Esto debería listar sólo un miembro: él mismo.
A continuación, registre esa URL esperada en cualquier nodo existente del clúster (si aún no tiene un clúster, hágalo en la NetHSM que servirá como nodo inicial del clúster). Para ello, utilice el punto final POST /cluster/members (consulte la documentación de la API ` <https://nethsmdemo.nitrokey.com/api_docs/index.html>` __), pasándole un cuerpo JSON que contenga la URL.
Si tiene éxito, devuelve un cuerpo JSON del formulario:
{
"members": [
{
"name": "",
"urls": [
"https://172.22.1.3:2380"
]
},
{
"name": "9ZVNM2MNWP",
"urls": [
"https://172.22.1.2:2380"
]
}
],
"joinerKit": "eyJiYWNrdXBfc2FsdCI6IkVlUzNPOEhHSEc5NnlNRktrdG1NZmc9PSIsInVubG9ja19zYWx0IjoiU3phMkEvYW13NlhxVWsrdHZMMmFubm5SZFlWd2ZQUjdpZ3IxK1RSdTdVaU14dmh3d0x2NWIvYVNkY2c9IiwibG9ja2VkX2RvbWFpbl9rZXkiOiIyMnNGVlkyelhQUVZ6S1pQenI3MmkwTk1WM3lmQ2k5dGwzeDhUbGtuOXM0WjFOd3JoZkRQTFZIVHp1WVl0YkQxaVZCMlovV3JHUHJlMXlwN0t4U0w4WkxjY2ZUTmUzcFg0WXE4YXNlY0wwREhXNGlIaXlPMlZnPT0ifQ=="
}
que contiene la información necesaria para que el nuevo nodo se una al clúster. En particular, enumera todos los miembros del clúster (donde el miembro con un nombre vacío es el nuevo miembro). También contiene la clave de dominio encriptada tanto por la contraseña de desbloqueo como por la de respaldo, por lo que es necesario haber configurado antes una contraseña de respaldo.
Guarda esa respuesta para el siguiente paso.
Unirse al clúster¶
Tome la respuesta del último paso y añádale un campo backupPassphrase que contenga la frase de contraseña de respaldo del nodo en el que se registró el nuevo miembro, y pase esos datos a una llamada a POST /cluster/join (consulte la documentación de la API ` <https://nethsmdemo.nitrokey.com/api_docs/index.html>` __) en el nodo que se espera que se una.
Suponiendo que tanto el clúster como el nodo puedan comunicarse entre sí, esto promulgará la unión real, borrando los datos del nuevo miembro para sincronizar su estado con el del clúster.
Dependiendo de las condiciones de la red y del clúster, esta operación puede tardar unas decenas de segundos. Si esta operación falla inmediatamente (por ejemplo, el clúster no era accesible o falló la autenticación), el estado de este nodo no se borrará y la unión se revertirá. Sin embargo, tan pronto como una primera unión tiene éxito, esta operación es definitiva y sólo puede ser revertida por un restablecimiento de fábrica.
Si esta unión tiene éxito, el nodo terminará en un estado Locked, y tiene que ser desbloqueado con la frase de contraseña de desbloqueo del nodo que se utilizó para el registro. Después, la contraseña de desbloqueo puede cambiarse (las contraseñas de desbloqueo son específicas de cada nodo y no se comparten entre nodos).
Nota
Incluso después de que la unión se haya realizado con éxito, si la base de datos del clúster es grande o si el clúster está ocupado, el nuevo miembro puede tardar algún tiempo en sincronizar completamente su estado. Durante ese tiempo, todos los nodos (incluido, en particular, el nuevo miembro) pueden responder menos o no responder. Por ejemplo, el nuevo ensamblador puede devolver errores al principio al intentar desbloquearlo. En ese caso, dale un poco de tiempo y vuelve a intentarlo.
Adding a Witness Node¶
Prepare a Witness¶
Necesitará un entorno con etcd v3.6 disponible, con una dirección IPv4 (al menos) alcanzable por los otros miembros de su cluster. Es necesario permitir el tráfico TCP hacia y desde el puerto 2380.
Crea un directorio vacío donde etcd almacenará sus datos, y escribe su ruta (nosotros usaremos /var/etcd/data). Asegúrate de que el usuario que lanzará el proceso tiene permiso para leer y escribir en el directorio.
Transfiera a la máquina el certificado CA que se va a utilizar para autenticar los nodos del cluster. Deberías haber creado uno en la sección Creating and Installing a CA. Lo almacenaremos en /var/etcd/CA.pem.
A continuación, tendrá que crear un certificado para el testigo, y firmarlo con la CA para que pueda comunicarse con sus pares. Esto puede hacerse, por ejemplo, a través de openssl:
# Create a key
$ openssl genrsa -out witness.key 2048
# Create a CSR with a SAN that corresponds to the witness's IP or hostname
$ openssl req -new -sha256 -key own.key -subj "/C=US/ST=CA/O=MyOrg, Inc./CN=witness" \
-addext "subjectAltName=IP:172.22.1.3" --out witness.csr
# Sign it
$ openssl x509 -req -days 1825 -in witness.csr -CA CA.pem -copy_extensions copy \
-CAkey CA.key -out witness.pem -set_serial 01 -sha256
Guarde también los resultados witness.key y witness.pem en /var/etcd.
Register Witness to Cluster¶
Siga las instrucciones normales de la sección Registering a New Node para indicar al cluster existente la adición de un nuevo miembro con la(s) URL(s) indicada(s).
Anota la respuesta del clúster: debe contener la lista de miembros del clúster y un kit de unión (no necesitarás esta parte).
Configure etcd¶
A diferencia de los NetHSM que eligen automáticamente un nombre de nodo para sí mismos (utilizando el ID de dispositivo), debe elegir un nombre para cada testigo que añada, asegurándose de que los nombres son únicos. Utilizaremos «witness1» en los siguientes ejemplos.
Con la respuesta de la NetHSM al registro del testigo, preparar las variables del formulario:
export ETCD_NAME="witness1"
export ETCD_DATA_DIR="/var/etcd/data"
export ETCD_INITIAL_CLUSTER="peer1=url1,peer1=url2,peer2=url1,peer2=url2,..."
export ETCD_INITIAL_ADVERTISE_PEER_URLS="my_url1,my_url2,..."
Suponiendo que la respuesta NetHSM se almacena en un archivo response.json, puede generar estas dos últimas variables automáticamente con las siguientes expresiones jq:
export ETCD_INITIAL_CLUSTER=$(jq --raw-output '[.members[] | ["\(if .name == "" then "witness1" else .name end)=\(.urls[])"]] | flatten | join(",")' < response.json)
export ETCD_INITIAL_ADVERTISE_PEER_URLS=$(jq --raw-output '.members[] | select(.name=="") | .urls | join(",")' < response.json)
Por ejemplo, con la respuesta de ejemplo proporcionada en la sección Registering a New Node, tendrá:
ETCD_NAME="witness1"
ETCD_DATA_DIR="/var/etcd/data"
ETCD_INITIAL_CLUSTER="witness1=https://172.22.1.3:2380,9ZVNM2MNWP=https://172.22.1.2:2380"
ETCD_INITIAL_ADVERTISE_PEER_URLS="https://172.22.1.3:2380"
Por último, cree un archivo etcd.conf.yml utilizando el archivo de plantilla proporcionado en docs/etcd_witness.conf.template:
$ envsubst < NETHSM_ROOT/docs/etcd_witness.conf.template > /var/etcd/witness.conf.yml
$ cat witness.conf.yml
Esto debería darle un archivo del formulario:
name: witness1
data-dir: /var/etcd/data
log-level: warn
log-format: console
listen-peer-urls: https://0.0.0.0:2380
listen-client-urls: http://localhost:2379
initial-advertise-peer-urls: https://172.22.1.3:2380
advertise-client-urls: http://localhost:2379
initial-cluster: witness1=https://172.22.1.3:2380,9ZVNM2MNWP=https://172.22.1.2:2380
initial-cluster-state: 'existing'
peer-transport-security:
cert-file: witness.pem
key-file: witness.key
client-cert-auth: true
trusted-ca-file: CA.pem
skip-client-san-verification: true
Start etcd¶
Inicie etcd de la forma que prefiera (manualmente, systemd servicio, contenedor, etc.), apuntando al archivo de configuración creado en el paso anterior:
$ cd /var/etcd
$ etcd --config-file witness.conf.yml
Deberías verlo arrancar, unirse al cluster y ponerse al día con los datos. Después de algún tiempo, usted debe ser capaz de comprobar que está sano con el etcdctl cliente:
etcdctl get /config/version
Esta clave debe existir y contener «1».
Asegúrese de que este proceso sigue en marcha, ya que ahora es un miembro más de su clúster. Si necesita retirarlo, primero elimínelo correctamente del clúster (consulte la sección dedicada). Si su IP accesible cambia, actualice su URL desde el clúster.
Operating a Cluster¶
Copia de seguridad y restauración¶
La operación de copia de seguridad funciona igual que sin clúster y puede solicitarse desde cualquier nodo del clúster. Realizará una copia de seguridad de los datos de todo el clúster, incluidos los campos específicos del nodo (aunque estos se ignorarán a menos que se restaure la copia de seguridad en un nodo no aprovisionado).
Una copia de seguridad realizada en un clúster puede restaurarse en el mismo clúster, incluso si desde entonces se han añadido o eliminado algunos nodos. Estas restauraciones realizadas en clústeres operativos no afectarán a los valores de configuración (solo claves, usuarios, espacios de nombres), como cualquier otra restauración parcial.
La restauración de una copia de seguridad en un nodo no aprovisionado restaurará los campos específicos del nodo (como la configuración de red, certificados, etc.) del nodo que se utilizó para crear la copia de seguridad.
La restauración de una copia de seguridad de gran tamaño puede saturar el clúster durante algún tiempo, mientras el nodo que aplica la restauración reenvía los cambios a los demás.
Esta operación sigue siendo compatible con las copias de seguridad realizadas en versiones anteriores de NetHSM.
Nota
Al restaurar en un nodo A una copia de seguridad realizada en otro nodo Z con una clave de dominio diferente, se reescribirá correctamente la clave de dominio de A, como antes. Sin embargo, si A estaba en un clúster con el nodo B, B quedará inoperativo, ya que la clave de dominio de Z no se restaurará en B.
En otras palabras, sólo realice una restauración en un clúster con copias de seguridad realizadas en el mismo clúster (aunque de nuevo los nodos pueden haber sido eliminados o añadidos desde entonces). Si quieres restaurar una copia de seguridad ajena en un nodo, primero elimínalo de forma segura de su clúster, luego restablécelo de fábrica y restaura la copia de seguridad.
Eliminar un nodo limpiamente¶
Mientras alguna parte del clúster siga reuniendo quórum, cualquiera de sus miembros puede utilizarse para eliminar otro nodo del clúster, tanto si este nodo ya es inalcanzable como si se espera que lo sea.
Primero tienes que saber el ID del nodo que quieres eliminar, listando todos los nodos a través de GET /cluster/members y buscando el correcto.
Entonces puede ser eliminado llamando a DELETE /cluster/members/<id>. Si el nodo en cuestión aún estaba sano, esto lo aislará del resto del clúster y lo dejará inoperativo.
Software Updates in Clusters¶
Las futuras actualizaciones se marcarán como «cluster-safe» (debería ser la mayoría) o «cluster-unsafe».
Las actualizaciones a prueba de clústeres pueden aplicarse a nodos que forman parte de un clúster sin eliminarlos primero del clúster. Sin embargo, como con todas las operaciones, debe asegurarse de hacerlo en un nodo a la vez, y en un clúster donde la eliminación de un nodo no vaya por debajo del quórum (por ejemplo, si la actualización falla).
Las actualizaciones no seguras para clústeres deben aplicarse a nodos aislados. Debe desmantelar el clúster (eliminando los nodos uno a uno), restablecer de fábrica todos los nodos menos uno, aplicar la actualización a todos los nodos y, a continuación, hacer que todos los nodos restablecidos se unan al nodo restante.
Asegúrese de realizar una copia de seguridad antes de este tipo de operaciones.
Reconfiguración de un clúster existente¶
Changing the Cluster CA¶
Un clúster existente (con dos o más nodos) no puede cambiar su CA de clúster mientras está en funcionamiento. Si necesita cambiar este certificado: elija un nodo, elimine todos los demás nodos, actualice la CA y, a continuación, haga que los demás miembros vuelvan a unirse.
Changing the Network Configuration of Nodes¶
La modificación de la configuración de red de un nodo (por ejemplo, cambiando su IP) informará automáticamente a los demás nodos de la actualización. Sin embargo, debes asegurarte de que sólo realizas este tipo de actualizaciones en un único nodo cada vez, y en un clúster en el que la pérdida de ese nodo no suponga la pérdida de quórum.