Clustering¶
Nota
Questa funzione è attualmente un’anteprima tecnica con le seguenti limitazioni temporanee:
Se un cluster viene perso (si perde il quorum), l’unico mezzo di recupero è il reset di fabbrica + il ripristino. Assicurarsi di eseguire spesso il backup. Le versioni future includeranno mezzi per recuperare i dati su disco.
La configurazione attiva/passiva per supportare cluster a due nodi, utilizzando etcd Learner o Mirror, non è ancora disponibile.
Per ora l’ora del sistema tra i nodi deve essere sincronizzata manualmente. Una versione futura includerà la sincronizzazione automatica dell’orologio.
NetHSM 4.0 supporta il clustering per sincronizzare direttamente i dati tra diversi NetHSM. Questo supporta l’alta frequenza di generazione delle chiavi, realizza l’alta disponibilità e il bilanciamento del carico. Un cluster NetHSM è basato su etcd che utilizza l’algoritmo di consenso Raft per una forte coerenza. Questo garantisce che i dati (ad esempio le chiavi) siano sempre corretti in tutti i NetHSM.
Prima di configurare un cluster NetHSM, è necessario familiarizzare con questa tecnologia e con i suoi vincoli per evitare interruzioni accidentali e perdite di dati. Oltre a questo documento, si consiglia di consultare anche la documentazione di etcd.
Operational Redundancy¶
Chiameremo «nodo» un NetHSM che dovrebbe far parte di un cluster. Un cluster di N nodi continuerà a funzionare finché almeno (N/2)+1 nodi sono sani e raggiungibili. Questo numero minimo di nodi sani e raggiungibili è chiamato quorum.
Ciò implica i seguenti scenari.
Un nodo si guasta e il quorum è ancora raggiunto¶
In un cluster a tre nodi, se un nodo si guasta (si blocca o diventa irraggiungibile a causa delle condizioni della rete), gli altri due nodi continueranno a lavorare e a servire le richieste.
Se il nodo guasto è ancora sano (ad esempio, si è trattato solo di un problema di rete), sarà inutilizzabile mentre è isolato (nemmeno in sola lettura).
Tuttavia, se il nodo si riprende, si risincronizza in modo pulito con il resto del cluster e diventa nuovamente operativo, senza perdere i dati.
Se non si riprende, è necessario rimuoverlo dal cluster (vedere la sezione successiva), eseguire un reset di fabbrica e ripetere il processo di unione da zero.
Si verifica una partizione della rete e il quorum è ancora raggiunto¶
Questa è solo una generalizzazione dello scenario precedente. In un cluster di 5 nodi in cui, ad esempio, 3 nodi si trovano in una posizione fisica A e 2 nodi in un’altra posizione B, un problema di rete che isola A e B significherebbe quanto segue:
I 3 nodi della posizione A rispettano il quorum (3 in questo caso), quindi continuano a operare.
I 2 nodi nella posizione B non **** soddisfano il quorum (ancora 3), quindi smetteranno di funzionare (anche in sola lettura).
Se il problema di rete viene risolto, i 2 nodi si uniranno nuovamente agli altri 3 in modo pulito.
Il quorum è perso in modo duraturo¶
Un guasto che causa la perdita del quorum di tutti i sottoinsiemi del cluster renderà il cluster e i suoi dati completamente persi, a meno che il guasto non venga risolto. In questo caso, i nodi devono essere ripristinati in fabbrica e deve essere ripristinato un backup.
Questo può accadere, ad esempio, se un singolo nodo si guasta in un cluster di 2 nodi (dove il quorum è 2). In questa situazione, il nodo guasto non può essere rimosso dal cluster in modo pulito, perché il nodo sano rimanente è già inutilizzabile in quanto ha perso il quorum.
Per questo motivo si consiglia di avere sempre un numero dispari di nodi in un cluster e di eseguire spesso il backup.
Per essere chiari, temporaneamente perdere il quorum (ad esempio, se si riavviano tutti i nodi di un cluster insieme, o se un guasto temporaneo della rete isola i nodi) non è un problema: una volta che un numero sufficiente di nodi è stato ricollegato (senza doversi ricongiungere manualmente) per raggiungere il quorum, il cluster riprenderà il suo normale funzionamento. Solo i guasti permanenti, come partizioni di rete, errate configurazioni di rete, problemi di autenticazione o guasti hardware, richiedono un’azione manuale.
Per ulteriori informazioni, consultare le FAQ di etcd.
Cluster a 2 nodi¶
Un cluster attivo/passivo a due nodi non è ancora supportato e sarà aggiunto in una versione futura. Si consiglia di introdurre un terzo nodo, o un terzo NetHSM o un «testimone» etcd che potrebbe essere gestito su qualsiasi host. Vedere la sezione successiva «Witness».
Testimone¶
La natura del clustering con etcd rende più affidabile il numero di nodi presenti nel cluster. Come spiegato nella sezione Ridondanza operativa, i cluster dovrebbero idealmente avere almeno 3 nodi per avere spazio per i guasti, dato che un cluster di 2 nodi fallirà completamente se solo uno si guasta.
Tuttavia, il design della funzione è tale che non è necessario aggiungere un dispositivo NetHSM completo e reale al cluster per raggiungere un numero stabile di nodi. Si può invece distribuire e aggiungere un nodo «testimone». Tale nodo è solo un’istanza di etcd in esecuzione sulla macchina di vostra scelta (o in un container) e connessa al cluster. Verrà riconosciuto come un normale nodo dai dispositivi reali del cluster e riceverà tutti i dati e gli aggiornamenti dai dispositivi (ma naturalmente non sarà in grado di eseguire alcuna operazione HSM con esso - memorizza solo i dati).
Security Considerations¶
Il nodo testimone (o chiunque vi abbia accesso) ha accesso diretto al backend di memorizzazione di tutti i nodi del cluster (ad esempio, è possibile scaricare tutte le voci e i valori corrispondenti con etcdctl get "/" "0").
Tuttavia, con l’eccezione della versione di configurazione (/config/version, che dovrebbe essere sempre «1»), tutti i valori sono rigorosamente criptati (con una chiave di dispositivo per i valori specifici del nodo o con le chiavi di dominio per gli altri), garantendo la riservatezza dei dati sensibili.
Si noti tuttavia che un nodo maligno può:
scrivere spazzatura come valore per qualsiasi voce dell’archivio, il che farà sì che i nodi non riescano a decifrarla (il che può portare a crash per alcune voci di sistema).
elencare nomi di voci come utenti, spazi dei nomi e chiavi, che possono essere considerati sensibili.
Creating a Cluster¶
Ogni cluster partirà inizialmente da un singolo nodo. I nuovi nodi si uniranno al cluster uno alla volta.
Preparing Nodes¶
Il traffico di rete tra i nodi viene crittografato e autenticato utilizzando il loro certificato TLS.
Tutti i nodi che si prevede facciano parte dello stesso cluster devono prima installare un’autorità di certificazione (CA) comune che consenta loro di verificare che gli altri nodi siano legittimi.
Di seguito, si ipotizza che tutti i nodi siano appena forniti e operativi.
Networking¶
Nodes must first be reconfigured with their expected final network configuration using the /config/network endpoint (refer to the API documentation).
Creazione e installazione di una CA¶
Gli utenti devono creare una CA con i propri mezzi e in base ai propri vincoli operativi, assicurandosi che consenta almeno l’uso della chiave keyCertSign.
Ad esempio, una CA minima può essere creata 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
Questa CA deve essere installata su ogni 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
Per autenticare correttamente i nodi, il backend del clustering (etcd) si aspetta che ogni nodo abbia un certificato con un campo Subject Alt Names (SAN) correttamente compilato. In particolare, i nodi che devono essere raggiunti solo tramite il loro IP devono avere un SAN IP corretto nel loro certificato. I SAN IP possono essere richiesti per il CSR anteponendo «IP:» ai nomi, come in openssl:
"subjectAltNames": [ "normalname.org", "IP:192.168.1.1" ]
Dato il CSR ottenuto (chiamiamolo nethsm.csr), possiamo generare un certificato per esso, pronto per essere installato. Ad esempio 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).
Infine, la CA (CA.pem) può ora essere installata con l’endpoint /config/tls/cluster-ca.pem (fare riferimento alla documentazione dell’API ` <https://nethsmdemo.nitrokey.com/api_docs/index.html>` __). Questo è possibile solo quando il certificato TLS installato è firmato dalla CA. In caso contrario, l’operazione verrà rifiutata.
Nota
Questo processo deve essere ripetuto per ogni nodo.
Sincronizzazione dell’orologio¶
Assicurarsi che ogni nodo sia stato fornito di un orario di sistema preciso. In caso contrario, regolare gli orologi con l’endpoint /config/time.
Adding a New Node¶
L’aggiunta di un nodo a un cluster avviene in due fasi:
registrare l’aggiunta al cluster (attraverso uno qualsiasi dei suoi membri)
indicare al nuovo nodo di unirsi
Configure a Backup Passphrase¶
Per prima cosa, assicurarsi che una passphrase di backup sia configurata sul nodo che sarà usato per registrare un nuovo joiner (vedere la documentazione API dell’endpoint /config/backup-passphrase).
Registrazione di un nuovo nodo¶
Avvertimento
La registrazione di un nodo introduce immediatamente un nuovo nodo nel cluster, modificando la soglia di quorum, anche se il nodo non si è ancora unito. Questo può rendere inutilizzabili i nodi esistenti fino a quando il nuovo nodo non si è effettivamente unito. Consultare la documentazione API ` <https://nethsmdemo.nitrokey.com/api_docs/index.html>` __ e la sezione Operational Redundancy di questo documento.
Tenere a portata di mano l’IP del nodo che si unirà. L’URL completo (chiamato anche peer URL nella terminologia etcd) di tale nodo sarà https://<IP_of_node>:2380 (ad esempio https://192.168.1.1:2380). La porta deve essere 2380, quindi assicurarsi che qualsiasi firewall tra i nodi permetta il traffico TCP su tale porta.
Si può verificare che l’URL sia corretto chiamando GET /cluster/members sul nodo che ci si aspetta si unisca. Questo dovrebbe elencare un solo membro: se stesso.
Quindi registrare l’URL atteso su qualsiasi nodo esistente del cluster (se non si ha ancora un cluster, farlo sul NetHSM che servirà come nodo iniziale del cluster). Questo viene fatto usando l’endpoint POST /cluster/members (fare riferimento alla documentazione dell’API ` <https://nethsmdemo.nitrokey.com/api_docs/index.html>` __), passandogli un corpo JSON contenente l’URL.
In caso di successo, restituisce un corpo JSON del modulo:
{
"members": [
{
"name": "",
"urls": [
"https://172.22.1.3:2380"
]
},
{
"name": "9ZVNM2MNWP",
"urls": [
"https://172.22.1.2:2380"
]
}
],
"joinerKit": "eyJiYWNrdXBfc2FsdCI6IkVlUzNPOEhHSEc5NnlNRktrdG1NZmc9PSIsInVubG9ja19zYWx0IjoiU3phMkEvYW13NlhxVWsrdHZMMmFubm5SZFlWd2ZQUjdpZ3IxK1RSdTdVaU14dmh3d0x2NWIvYVNkY2c9IiwibG9ja2VkX2RvbWFpbl9rZXkiOiIyMnNGVlkyelhQUVZ6S1pQenI3MmkwTk1WM3lmQ2k5dGwzeDhUbGtuOXM0WjFOd3JoZkRQTFZIVHp1WVl0YkQxaVZCMlovV3JHUHJlMXlwN0t4U0w4WkxjY2ZUTmUzcFg0WXE4YXNlY0wwREhXNGlIaXlPMlZnPT0ifQ=="
}
che contiene le informazioni necessarie al nuovo nodo per unirsi al cluster. In particolare, elenca tutti i membri del cluster (dove il membro con un nome vuoto è il nuovo membro). Contiene anche la chiave di dominio criptata sia dalla passphrase di sblocco che da quella di backup, per cui deve essere stata configurata una passphrase di backup.
Conservate la risposta per la fase successiva.
L’effettiva adesione al cluster¶
Prendere la risposta dell’ultimo passo e aggiungervi un campo backupPassphrase contenente la passphrase di backup del nodo su cui è stato registrato il nuovo joiner, e passare questi dati a una chiamata a POST /cluster/join (fare riferimento alla documentazione dell’API ` <https://nethsmdemo.nitrokey.com/api_docs/index.html>` __) sul nodo che ci si aspetta si unisca.
Supponendo che sia il cluster che il nodo siano in grado di raggiungersi a vicenda, questa operazione attuerà l’unione vera e propria, cancellando i dati del nuovo membro per sincronizzare invece il suo stato con quello del cluster.
A seconda delle condizioni della rete e del cluster, questa operazione può richiedere alcune decine di secondi. Se l’operazione fallisce immediatamente (ad esempio, il cluster non era raggiungibile o l’autenticazione non è riuscita), lo stato del nodo non verrà cancellato e l’unione verrà ripristinata. Tuttavia, non appena una prima unione ha successo, l’operazione è definitiva e può essere annullata solo con un reset di fabbrica.
Se questa unione ha successo, il nodo finisce in uno stato Locked e deve essere sbloccato con la passphrase di sblocco del nodo usato per la registrazione. In seguito la passphrase di sblocco può essere cambiata (le passphrase di sblocco rimangono specifiche del nodo e non sono condivise tra i nodi).
Nota
Anche dopo che l’unione è riuscita, se il database del cluster è di grandi dimensioni o se il cluster è occupato, può essere necessario un po” di tempo perché il nuovo joiner sincronizzi completamente il suo stato. Durante questo periodo, tutti i nodi (compreso in particolare il nuovo joiner) potrebbero essere meno reattivi o non rispondere. In particolare, il nuovo joiner potrebbe inizialmente restituire errori quando si tenta di sbloccarlo, ad esempio. In questo caso, è necessario attendere un po” di tempo e riprovare.
Adding a Witness Node¶
Prepare a Witness¶
È necessario un ambiente con etcd v3.6 disponibile, con un indirizzo IPv4 (almeno) raggiungibile dagli altri membri del cluster. Il traffico TCP da e verso la porta 2380 deve essere consentito.
Creare una directory vuota in cui etcd memorizzerà i suoi dati e scrivere il suo percorso (noi useremo /var/etcd/data). Assicurarsi che l’utente che avvierà il processo abbia i permessi di lettura e scrittura sulla directory.
Trasferire alla macchina il certificato CA utilizzato per autenticare i nodi del cluster. Dovreste averne creato uno nella sezione Creazione e installazione di una CA. Lo memorizzeremo in /var/etcd/CA.pem.
Sarà quindi necessario creare un certificato per il testimone e firmarlo con la CA in modo che possa comunicare con i suoi pari. Questo può essere fatto, ad esempio, tramite 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
Memorizzare i risultati di witness.key e witness.pem anche in /var/etcd.
Register Witness to Cluster¶
Seguire le normali istruzioni della sezione Registrazione di un nuovo nodo per segnalare al cluster esistente l’aggiunta di un nuovo membro con l’URL indicato.
Scrivete la risposta del cluster: dovrebbe contenere l’elenco dei membri del cluster e un kit di adesione (questa parte non vi servirà).
Configure etcd¶
A differenza dei NetHSM che scelgono automaticamente il nome del nodo (utilizzando l’ID del dispositivo), è necessario scegliere un nome per ogni testimone aggiunto, assicurandosi che i nomi siano unici. Negli esempi che seguono utilizzeremo «witness1».
Con la risposta del NetHSM alla registrazione del testimone, preparare le variabili del modulo:
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,..."
Assumendo che la risposta di NetHSM sia memorizzata in un file response.json, è possibile generare automaticamente queste ultime due variabili con le seguenti espressioni 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)
Ad esempio, con l’esempio di risposta fornito nella sezione Registrazione di un nuovo nodo, si avrà:
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"
Infine, creare un file etcd.conf.yml utilizzando il file modello fornito in docs/etcd_witness.conf.template:
$ envsubst < NETHSM_ROOT/docs/etcd_witness.conf.template > /var/etcd/witness.conf.yml
$ cat witness.conf.yml
In questo modo si ottiene un file del modulo:
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¶
Avviare etcd nel modo preferito (manualmente, systemd servizio, container, ecc.), puntando al file di configurazione creato nel passo precedente:
$ cd /var/etcd
$ etcd --config-file witness.conf.yml
Si dovrebbe vedere che si avvia, si unisce al cluster e recupera i dati. Dopo un po” di tempo, si dovrebbe essere in grado di verificare che sia sano con il client etcdctl:
etcdctl get /config/version
Questa chiave deve esistere e contenere «1».
Assicurarsi che questo processo continui a funzionare, poiché ora è un membro effettivo del cluster. Se è necessario disattivarlo, prima rimuoverlo correttamente dal cluster (vedere la sezione dedicata). Se il suo IP raggiungibile cambia, aggiornare il suo URL dal cluster.
Operating a Cluster¶
Backup e ripristino¶
L’operazione di backup funziona come senza cluster e può essere richiesta da qualsiasi nodo del cluster. Verrà eseguito il backup dei dati dell’intero cluster, compresi i campi specifici del nodo (anche se questi verranno ignorati a meno che non si ripristini il backup su un nodo non approvato).
Un backup eseguito su un cluster può essere ripristinato sullo stesso cluster, anche se alcuni nodi sono stati aggiunti o rimossi da allora. Tali ripristini eseguiti su cluster operativi non influiscono sui valori di configurazione (solo chiavi, utenti, spazi dei nomi), come qualsiasi altro ripristino parziale.
Il ripristino di un backup su un nodo non provvisto ripristinerà i campi specifici del nodo (come la configurazione di rete, i certificati, ecc.) del nodo utilizzato per creare il backup.
Il ripristino di un backup di grandi dimensioni può sovraccaricare il cluster per qualche tempo, mentre il nodo che applica il ripristino inoltra le modifiche agli altri.
Questa operazione rimane compatibile con i backup effettuati su versioni precedenti di NetHSM.
Nota
Il ripristino su un nodo A di un backup eseguito su un altro nodo Z con una chiave di dominio diversa riscriverà correttamente la chiave di dominio di A, come prima. Tuttavia, se A si trovava in un cluster con il nodo B, B diventerà inutilizzabile, poiché la chiave di dominio di Z non verrà ripristinata su B.
In altre parole, eseguire un ripristino solo in un cluster con backup eseguiti nello stesso cluster (anche se i nodi potrebbero essere stati rimossi o aggiunti da allora). Se si desidera ripristinare un backup estraneo su un nodo, occorre prima rimuoverlo in modo sicuro dal suo cluster, quindi ripristinarlo e ripristinare il backup.
Rimuovere un nodo in modo pulito¶
Finché una parte del cluster soddisfa ancora il quorum, uno qualsiasi dei suoi membri può essere usato per rimuovere un altro nodo dal cluster, sia che questo nodo sia già irraggiungibile sia che si preveda che lo sarà.
Per prima cosa è necessario conoscere l’ID del nodo che si vuole rimuovere, elencando tutti i nodi attraverso GET /cluster/members e cercando quello giusto.
Quindi può essere rimosso chiamando DELETE /cluster/members/<id>. Se il nodo in questione era ancora sano, questo lo isolerà dal resto del cluster e lo renderà inutilizzabile.
Software Updates in Clusters¶
Gli aggiornamenti futuri saranno contrassegnati come «cluster-safe» (dovrebbe essere la maggioranza) o «cluster-unsafe».
Gli aggiornamenti sicuri per il cluster possono essere applicati ai nodi che fanno parte di un cluster senza rimuoverli prima dal cluster. Tuttavia, come per tutte le operazioni, è necessario assicurarsi di eseguire l’operazione su un nodo alla volta e in un cluster in cui la rimozione di un nodo non faccia scendere il quorum (ad esempio, se l’aggiornamento fallisce).
Gli aggiornamenti non sicuri per il cluster devono essere applicati a nodi isolati. È necessario smantellare il cluster (rimuovendo i nodi uno per uno), ripristinare tutti i nodi tranne uno, applicare l’aggiornamento a tutti i nodi, quindi fare in modo che tutti i nodi ripristinati si uniscano al nodo rimanente.
Assicuratevi di eseguire il backup prima di tali operazioni.
Riconfigurazione di un cluster esistente¶
Changing the Cluster CA¶
Un cluster esistente (con due o più nodi) non può cambiare la CA del cluster mentre è in funzione. Se è necessario modificare questo certificato: scegliere un nodo, rimuovere tutti gli altri nodi, aggiornare la CA, quindi far rientrare gli altri membri.
Changing the Network Configuration of Nodes¶
La modifica della configurazione di rete di un nodo (ad esempio, la modifica del suo IP) informerà automaticamente gli altri nodi dell’aggiornamento. Tuttavia, è necessario assicurarsi di eseguire tali aggiornamenti solo su un singolo nodo alla volta e in un cluster in cui la perdita di tale nodo non comporti la perdita del quorum.