Clustering¶
Poznámka
Tato funkce je v současné době technickým náhledem s následujícími dočasnými omezeními:
Pokud dojde ke ztrátě clusteru (ztrátě kvora), jediným způsobem obnovy je tovární reset + obnovení. Dbejte na časté zálohování. Budoucí verze budou obsahovat prostředky pro obnovu dat na disku.
Aktivní/pasivní nastavení pro podporu clusterů se dvěma uzly, a to buď pomocí etcd Learner, nebo Mirror, zatím není k dispozici.
Systémový čas mezi uzly musí být prozatím synchronizován ručně. Budoucí verze bude obsahovat automatickou synchronizaci hodin.
NetHSM od verze 4.0 podporuje clustering pro přímou synchronizaci dat mezi několika NetHSM. To podporuje vysokou frekvenci generování klíčů, realizuje vysokou dostupnost a vyrovnávání zátěže. Cluster NetHSM je založen na etcd, který používá konsensuální algoritmus Raft pro silnou konzistenci. Tím je zajištěno, že data (např. klíče) jsou ve všech NetHSM vždy správná.
Před nastavením clusteru NetHSM se seznamte s touto technologií a jejími omezeními, abyste předešli náhodnému výpadku a ztrátě dat. Kromě tohoto dokumentu se můžete podívat také do dokumentace etcd.
Operational Redundancy¶
„Uzlem“ budeme nazývat NetHSM, který má být součástí clusteru. Klastr N uzlů bude fungovat tak dlouho, dokud budou alespoň (N/2)+1 uzly zdravé a dosažitelné. Toto minimální množství zdravých a dosažitelných uzlů se nazývá kvorum.
Z toho vyplývají následující scénáře.
Výpadek jednoho uzlu a dosažení kvora¶
Pokud v clusteru se třemi uzly dojde k selhání jednoho uzlu (havárii nebo nedostupnosti v důsledku síťových podmínek), ostatní dva uzly budou nadále pracovat a obsluhovat požadavky.
Pokud je selhávající uzel stále zdravý (např. šlo pouze o problém se sítí), bude při izolaci nefunkční (ani pro čtení).
Pokud se však uzel zotaví, čistě se znovu synchronizuje se zbytkem clusteru a je opět provozuschopný, aniž by došlo ke ztrátě dat.
Pokud se neobnoví, je třeba jej vyjmout z clusteru (viz další část), obnovit tovární nastavení a projít procesem připojení znovu od začátku.
Dojde k rozdělení sítě a kvorum je stále dosaženo¶
Jedná se pouze o zobecnění předchozího scénáře. V clusteru s 5 uzly, kde jsou např. 3 uzly v jednom fyzickém umístění A a 2 uzly v jiném umístění B, by síťový problém izolující A a B znamenal následující:
Tři uzly v lokalitě A splňují kvorum (v tomto případě 3), takže pokračují v provozu.
Dva uzly v lokalitě B jsou nesplňují kvorum (stále 3), takže přestanou pracovat (i jen pro čtení).
Pokud je problém se sítí vyřešen, 2 uzly se čistě připojí zpět k ostatním 3 uzlům.
Kvorum je trvale ztraceno¶
Selhání, které způsobí, že všechny podmnožiny clusteru ztratí kvorum, způsobí, že cluster a jeho data budou zcela ztraceny, pokud se nepodaří selhání vyřešit. V takovém případě je nutné uzly resetovat z výroby a obnovit zálohu.
K tomu může dojít například při selhání jednoho uzlu v clusteru se dvěma uzly (kde je kvorum 2). V této situaci nelze selhávající uzel z clusteru dodatečně čistě odstranit, protože zbývající zdravý uzel je již nefunkční, protože ztratil kvorum.
Proto se doporučuje mít v clusteru vždy lichý počet uzlů a často zálohovat.
Aby bylo jasno, dočasně ztráta kvora (například pokud restartujete všechny uzly clusteru společně nebo pokud dojde k dočasnému selhání sítě, které uzly izoluje) není problém: jakmile se znovu připojí dostatečný počet uzlů (aniž by se musely ručně znovu připojovat), aby bylo dosaženo kvora, cluster bude pokračovat v normálním provozu. Pouze trvalé poruchy, jako je rozdělení sítě, chybná konfigurace sítě, problémy s ověřováním nebo selhání hardwaru, budou vyžadovat ruční zásah.
Další informace naleznete na adrese etcd v sekci ČASTO KLADENÉ DOTAZY.
Cluster se 2 uzly¶
Aktivní/pasivní cluster se dvěma uzly zatím není podporován a bude přidán v některé z budoucích verzí. Doporučujeme zavést třetí uzel, buď třetí NetHSM, nebo „svědka“ etcd, který by mohl být provozován na libovolném hostiteli. Viz další část „Svědek“.
Svědek¶
Povaha shlukování pomocí etcd je tím spolehlivější, čím více uzlů je ve shluku. Jak je vysvětleno v části Provozní redundance, clustery by měly mít v ideálním případě alespoň 3 uzly, aby měly prostor pro selhání, protože cluster se 2 uzly zcela selže, pokud selže pouze jeden.
Funkce je však navržena tak, že k dosažení stabilního počtu uzlů není nutné přidávat do clusteru plné, skutečné zařízení NetHSM. Místo toho můžete sami nasadit a přidat „svědecký“ uzel. Takovým uzlem je pouze instance etcd běžící na vámi zvoleném počítači (nebo v kontejneru) a připojená ke clusteru. Bude rozpoznán jako normální uzel od skutečných zařízení v clusteru a bude přijímat všechna data a aktualizace ze zařízení (ale samozřejmě s ním nebudete moci provádět žádné operace HSM - pouze ukládá data).
Security Considerations¶
Svědecký uzel (nebo kdokoli s přístupem k němu) má přímý přístup k úložišti všech uzlů v clusteru (např. můžete vypsat všechny záznamy a odpovídající hodnoty pomocí etcdctl get "/" "0").
S výjimkou verze konfigurace (/config/version, která by měla být vždy „1“) jsou však striktně všechny hodnoty šifrovány (buď klíčem zařízení pro hodnoty specifické pro uzel, nebo klíči domény pro ostatní hodnoty), což zajišťuje důvěrnost citlivých dat.
Všimněte si však, že škodlivý uzel může:
zapsat jako hodnotu libovolné položky v úložišti smetí, což způsobí, že uzly selžou při dešifrování (což může vést k pádu některých systémových položek).
názvy položek seznamu, jako jsou uživatelé, obory názvů a klíče, které můžete považovat za citlivé.
Creating a Cluster¶
Každý cluster bude zpočátku spuštěn z jediného uzlu. Nové uzly se ke clusteru připojují jeden po druhém.
Preparing Nodes¶
Síťový provoz mezi uzly je šifrován a ověřován pomocí jejich certifikátu TLS.
Všechny uzly, které mají být součástí stejného clusteru, musí nejprve nainstalovat společnou certifikační autoritu, která jim umožní ověřit, zda jsou ostatní uzly legitimní.
V následujícím textu předpokládáme, že všechny uzly jsou čerstvě zajištěny a funkční.
Networking¶
Nodes must first be reconfigured with their expected final network configuration using the /config/network endpoint (refer to the API documentation).
Vytvoření a instalace certifikační autority¶
Uživatelé by si měli vytvořit certifikační autoritu vlastními prostředky a podle vlastních provozních omezení a ujistit se, že umožňuje alespoň použití klíče keyCertSign.
Minimální certifikační autoritu lze například vytvořit pomocí adresy 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
Tato certifikační autorita musí být nyní nainstalována v každém uzlu.
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).
Poznámka
Pro správné ověření uzlů očekává backend clusteru (etcd), že každý uzel má certifikát se správně vyplněným polem Subject Alt Names (SAN). Zejména uzly, u nichž se očekává, že budou dosažitelné pouze prostřednictvím své IP adresy, musí mít v certifikátu správně vyplněnou IP SAN. IP SAN lze pro CSR vyžádat tak, že se ke jménům přidá předpona „IP:“, jako například openssl:
"subjectAltNames": [ "normalname.org", "IP:192.168.1.1" ]
Vzhledem k získanému CSR (nazvěme jej nethsm.csr) pro něj můžeme vygenerovat certifikát, který je připraven k instalaci. Například pomocí 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).
Nakonec lze nyní nainstalovat certifikační autoritu (CA.pem) pomocí koncového bodu /config/tls/cluster-ca.pem (viz dokumentace API ` <https://nethsmdemo.nitrokey.com/api_docs/index.html>` __). To je možné až po podepsání nainstalovaného certifikátu TLS. V opačném případě bude operace odmítnuta.
Poznámka
Tento postup je třeba opakovat pro každý uzel.
Synchronizace hodin¶
Ujistěte se, že každý uzel byl vybaven přesným systémovým časem. Pokud tomu tak není, upravte jejich hodiny pomocí koncového bodu /config/time.
Adding a New Node¶
Přidání uzlu do clusteru se provádí ve dvou krocích:
zaregistrovat přírůstek do clusteru (prostřednictvím některého z jeho členů).
sdělit novému uzlu, aby se připojil
Configure a Backup Passphrase¶
Nejprve se ujistěte, že je v uzlu, který bude použit k registraci nového joineru, nakonfigurována záložní přístupová fráze (viz dokumentace API koncového bodu /config/backup-passphrase).
Registrace nového uzlu¶
Varování
Registrací uzlu se do clusteru okamžitě zavede nový uzel, čímž se změní prahová hodnota kvora, i když se uzel ve skutečnosti ještě nepřipojil. To může způsobit nefunkčnost stávajících uzlů, dokud se nový uzel skutečně nepřipojí. Viz dokumentace rozhraní API ` <https://nethsmdemo.nitrokey.com/api_docs/index.html>` __ a část Provozní redundance tohoto dokumentu.
Mějte po ruce IP adresu uzlu, který se připojí. Úplné URL (v terminologii etcd se také nazývá peer URL ) tohoto uzlu bude https://<IP_of_node>:2380 (např. https://192.168.1.1:2380). Port musí být 2380, takže se ujistěte, že případný firewall mezi uzly povolí provoz TCP na tomto portu.
Správnost adresy URL můžete překontrolovat zavoláním adresy GET /cluster/members na uzlu, který se má připojit. To by mělo vypsat pouze jeden člen: sebe sama.
Poté zaregistrujte očekávanou adresu URL v libovolném existujícím uzlu clusteru (pokud ještě nemáte cluster, proveďte to v zařízení NetHSM, které bude sloužit jako počáteční uzel clusteru). To se provádí pomocí koncového bodu POST /cluster/members (viz dokumentace API ` <https://nethsmdemo.nitrokey.com/api_docs/index.html>` __), kterému předáte tělo JSON obsahující adresu URL.
V případě úspěchu se vrátí tělo JSON formuláře:
{
"members": [
{
"name": "",
"urls": [
"https://172.22.1.3:2380"
]
},
{
"name": "9ZVNM2MNWP",
"urls": [
"https://172.22.1.2:2380"
]
}
],
"joinerKit": "eyJiYWNrdXBfc2FsdCI6IkVlUzNPOEhHSEc5NnlNRktrdG1NZmc9PSIsInVubG9ja19zYWx0IjoiU3phMkEvYW13NlhxVWsrdHZMMmFubm5SZFlWd2ZQUjdpZ3IxK1RSdTdVaU14dmh3d0x2NWIvYVNkY2c9IiwibG9ja2VkX2RvbWFpbl9rZXkiOiIyMnNGVlkyelhQUVZ6S1pQenI3MmkwTk1WM3lmQ2k5dGwzeDhUbGtuOXM0WjFOd3JoZkRQTFZIVHp1WVl0YkQxaVZCMlovV3JHUHJlMXlwN0t4U0w4WkxjY2ZUTmUzcFg0WXE4YXNlY0wwREhXNGlIaXlPMlZnPT0ifQ=="
}
který obsahuje informace nezbytné pro připojení nového uzlu ke clusteru. Zejména obsahuje seznam všech členů clusteru (kde člen s prázdným jménem je nový člen). Obsahuje také doménový klíč zašifrovaný odemykací i záložní přístupovou frází - záložní přístupová fráze tedy musela být nakonfigurována dříve.
Tuto odpověď si ponechte pro další krok.
Skutečné připojení ke clusteru¶
Vezměte odpověď z posledního kroku a připojte k ní pole backupPassphrase obsahující záložní přístupovou frázi uzlu, na kterém byl nový spojovatel zaregistrován, a předejte tato data volání POST /cluster/join (viz dokumentace rozhraní API ` <https://nethsmdemo.nitrokey.com/api_docs/index.html>` __) na uzlu, který se má připojit.
Za předpokladu, že se cluster i uzel mohou navzájem spojit, dojde k vlastnímu připojení, přičemž se vymažou data nového připojeného uzlu a místo toho se synchronizuje jeho stav se stavem clusteru.
V závislosti na podmínkách sítě a clusteru může tato operace trvat několik desítek sekund. Pokud tato operace selže okamžitě (např. cluster nebyl dosažitelný nebo selhalo ověřování), stav tohoto uzlu nebude vymazán a připojení bude vráceno zpět. Jakmile je však první připojení úspěšné, je tato operace konečná a lze ji vrátit pouze obnovením továrního nastavení.
Pokud je toto připojení úspěšné, uzel se ocitne ve stavu Locked a musí být odemčen pomocí odemykací fráze uzlu, který byl použit pro registraci. Poté lze odemykací heslovou frázi změnit (odemykací heslové fráze zůstávají specifické pro daný uzel a nejsou sdíleny mezi uzly).
Poznámka
I po úspěšném připojení může v případě, že je databáze clusteru rozsáhlá nebo je cluster zaneprázdněn, nějakou dobu trvat, než nový připojený člen plně synchronizuje svůj stav. Během této doby mohou všechny uzly (včetně zejména nového připojeného uzlu) reagovat hůře nebo nereagovat vůbec. Zejména nový uzel může zpočátku vracet chyby například při pokusu o odemknutí. V takovém případě mu dejte nějaký čas a zkuste to znovu.
Adding a Witness Node¶
Prepare a Witness¶
Budete potřebovat prostředí s dostupnou verzí etcd v3.6 s adresou IPv4 (alespoň) dosažitelnou pro ostatní členy clusteru. Je třeba povolit provoz TCP na port 2380 a z něj.
Vytvořte prázdný adresář, do kterého se budou ukládat data etcd, a zapište k němu cestu (my použijeme /var/etcd/data). Zajistěte, aby uživatel, který bude proces spouštět, měl oprávnění ke čtení a zápisu do adresáře.
Přeneste do počítače certifikát certifikační autority, který se používá k ověřování uzlů v clusteru. Měli jste jej vytvořit v části Vytvoření a instalace certifikační autority. Uložíme jej do adresáře /var/etcd/CA.pem.
Poté je třeba vytvořit certifikát pro svědka a podepsat jej certifikační autoritou, aby mohl komunikovat se svými protějšky. To lze provést například pomocí 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
Výsledné witness.key a witness.pem uložte také do /var/etcd.
Register Witness to Cluster¶
Podle běžných pokynů v části Registrování nového uzlu signalizujte stávajícímu clusteru přidání nového člena s danou adresou URL.
Zapište si odpověď od clusteru: měla by obsahovat seznam členů clusteru a sadu pro připojení (tuto část nebudete potřebovat).
Configure etcd¶
Na rozdíl od zařízení NetHSM, která si automaticky vybírají název uzlu (pomocí ID zařízení), je nutné zvolit název pro každého přidaného svědka, a ujistit se, že názvy jsou jedinečné. V následujících příkladech budeme používat „witness1“.
S odpovědí NetHSM na registraci svědka připravte proměnné formuláře:
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,..."
Za předpokladu, že je odpověď NetHSM uložena v souboru response.json, můžete tyto dvě poslední proměnné generovat automaticky pomocí následujících výrazů 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)
Například v příkladu odpovědi uvedeném v části Registrování nového uzlu se zobrazí:
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"
Nakonec vytvořte soubor etcd.conf.yml pomocí šablony souboru uvedené v docs/etcd_witness.conf.template:
$ envsubst < NETHSM_ROOT/docs/etcd_witness.conf.template > /var/etcd/witness.conf.yml
$ cat witness.conf.yml
Tím se vám zobrazí soubor formuláře:
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¶
Spusťte etcd preferovaným způsobem (ručně, systemd služba, kontejner atd.) a nasměrujte jej na konfigurační soubor vytvořený v předchozím kroku:
$ cd /var/etcd
$ etcd --config-file witness.conf.yml
Mělo by se spustit, připojit ke clusteru a dohnat data. Po nějaké době byste měli být schopni zkontrolovat, zda je v pořádku, pomocí klienta etcdctl:
etcdctl get /config/version
Tento klíč by měl existovat a obsahovat hodnotu „1“.
Ujistěte se, že tento proces běží dál, protože je nyní řádným členem clusteru. Pokud jej potřebujete vyřadit z provozu, nejprve jej řádně odeberte z clusteru (viz část věnovaná tomuto procesu). Pokud se změní jeho dosažitelná IP adresa, aktualizujte jeho adresu URL z clusteru.
Operating a Cluster¶
Zálohování a obnovení¶
Operace zálohování funguje stejně jako bez clusteru a lze o ni požádat z kteréhokoli uzlu clusteru. Zálohuje data celého clusteru, včetně polí specifických pro uzel (ta však budou ignorována, pokud se záloha neobnovuje na nezálohovaném uzlu).
Zálohu provedenou na clusteru lze obnovit na stejném clusteru, i když byly některé uzly od té doby přidány nebo odebrány. Takové obnovení provedené na provozních clusterech neovlivní hodnoty konfigurace (pouze klíče, uživatele, jmenné prostory), stejně jako jakékoli jiné částečné obnovení.
Obnovení zálohy na neschváleném uzlu obnoví pole specifická pro uzel (jako je konfigurace sítě, certifikáty atd.) uzlu, který byl použit k vytvoření zálohy.
Obnovení rozsáhlé zálohy může na nějakou dobu zahltit cluster, zatímco uzel, který obnovu provádí, předává změny ostatním.
Tato operace zůstává kompatibilní se zálohami provedenými v předchozích verzích NetHSM.
Poznámka
Obnovení zálohy provedené v uzlu A v jiném uzlu Z s jiným klíčem domény správně přepíše klíč domény A jako dříve. Pokud však byl A v clusteru s uzlem B, stane se B nefunkčním, protože doménový klíč Z nebude na B obnoven.
Jinými slovy, obnovu provádějte pouze v clusteru se zálohami provedenými ve stejném clusteru (i když uzly mohly být od té doby odebrány nebo přidány). Pokud chcete obnovit cizí zálohu v uzlu, nejprve jej bezpečně odeberte z jeho clusteru, poté jej obnovte do továrního nastavení a obnovte zálohu.
Čisté odstranění uzlu¶
Dokud některá část clusteru stále splňuje kvorum, může být kterýkoli z jeho členů použit k odstranění jiného uzlu z clusteru, ať už je tento uzel již nedostupný, nebo se očekává, že bude.
Nejprve musíte znát ID uzlu, který chcete odstranit, a to tak, že si vylistujete všechny uzly přes GET /cluster/members a vyhledáte ten správný.
Pak jej lze odstranit voláním DELETE /cluster/members/<id>. Pokud byl dotyčný uzel dosud zdravý, dojde k jeho izolaci od zbytku clusteru a k jeho znefunkčnění.
Software Updates in Clusters¶
Budoucí aktualizace budou označeny jako „cluster-safe“ (to by měla být většina) nebo „cluster-unsafe“.
Na uzly, které jsou součástí clusteru, lze aplikovat aktualizace bezpečné pro cluster, aniž by byly z clusteru nejprve odstraněny. Stejně jako u všech operací byste však měli zajistit, aby se tak dělo vždy na jednom uzlu a v clusteru, kde odebráním uzlu nedojde k poklesu kvora (např. pokud se aktualizace nezdaří).
Aktualizace, které nejsou bezpečné pro cluster, musí být aplikovány na izolované uzly. Měli byste cluster rozložit (odebírat uzly jeden po druhém), obnovit tovární nastavení všech uzlů kromě jednoho, aplikovat aktualizaci na každý uzel a poté všechny obnovené uzly připojit ke zbývajícímu uzlu.
Před těmito operacemi nezapomeňte zálohovat.
Rekonfigurace stávajícího clusteru¶
Changing the Cluster CA¶
Existující cluster (se dvěma nebo více uzly) nemůže změnit svou certifikační autoritu clusteru za provozu. Pokud potřebujete tento certifikát změnit: vyberte uzel, odstraňte všechny ostatní uzly, aktualizujte certifikační autoritu a poté nechte ostatní členy znovu připojit.
Changing the Network Configuration of Nodes¶
Změna síťové konfigurace uzlu (např. změna jeho IP) automaticky informuje ostatní uzly o aktualizaci. Měli byste však zajistit, abyste takové aktualizace prováděli vždy pouze v jediném uzlu a v clusteru, jehož ztráta nezpůsobí ztrátu kvora.