Cassandra přes VPN: oddělený přístup pro klienty a uzly

Nasazení Cassandra nemá jednu univerzální databázovou síť. Aplikace mluví s klientskou službou, členové clusteru mluví mezi sebou a operátoři používají administrativní rozhraní, a tyto tři skupiny by po sobě neměly dědit dosažitelnost. Soukromá cesta, jako je VPN, je dobrý výchozí bod, ale není to identita uživatele databáze a není to její politika šifrování. Berte rozhodnutí o konektivitě a rozhodnutí o autorizaci jako dvě samostatné revize.

Každé ze tří publik dostává vlastní odpověď a části níže je probírají v pořadí podle vystavení.

Tři publika, tři rozhodnutí

Než se dotknete jakéhokoli pravidla, určete, co každá skupina skutečně potřebuje. Klienti potřebují klientský listener a dost informací, aby dosáhli na každý uzel, který jim může být přidělen, partnerské uzly potřebují jeden druhého na mezouzlovém portu a operátoři potřebují rozhraní pro správu pro to, co runbook skutečně vyžaduje. Tři seznamy, tři publika, tři úrovně důvěry.

Častou chybou je postavit jeden plochý soukromý segment a předpokládat, že hranice VPN udělá zbytek. Uvnitř něj aplikace, která dosáhne na klientský port, obvykle dosáhne i na mezouzlový port, a administrativní nástroje operátora často sedí na stejném jump hostu jako aplikace. Srovnání těchto vrstev do jedné znamená, že kompromitovaná identita aplikace má už větší dosah než její vlastní dotazy. Nakreslete tři publika jako tři řádky v návrhovém dokumentu, každé s pravidlem, které ho povoluje, a mezery budou vidět dřív, než je někdo postaví.

Co klienti potřebují, a nic víc

Povolte zamýšleným zdrojům aplikace přístup ke klientským koncovým bodům pro nasazenou verzi a držte nesouvisející clusterové a správní služby mimo tento dosah. Potom zkontrolujte, jak ovladač objevuje uzly. Dostupný počáteční kontaktní bod nedokazuje, že každá adresa uzlu, kterou ovladač následně zvolí, je z tohoto klientského kontextu dostupná, protože ovladač se clusteru ptá na partnery a potom se připojuje k adresám, které cluster inzeruje.

Proto jeden nesoulad soukromé adresy vytváří známý vzorec: úspěšné první připojení následované vypršením časového limitu. Inzerované adresy a klientský routing konfigurujte záměrně; zveřejnění celého clusteru na internetu, abyste opravili jeden nesoulad, vymění chybu routingu za vystavení, které už nelze vzít zpět.

Zachovejte také databázové ověřování aplikace a oprávnění rolí. Sdílená přeložená adresa VPN může zastupovat mnoho uživatelů nebo služeb, takže nikdy nenahrazuje odlišné databázové identity.

Šifrujte odděleně klient-uzel a mezouzlovou komunikaci

Dokumentace zabezpečení Apache bere šifrování klient-uzel a mezouzlové šifrování jako samostatné konfigurace a zapnutí jednoho nezapne druhé. Tento rozdíl platí i uvnitř VPN, protože tunel chrání svůj vlastní segment a automaticky se nerozšiřuje z procesu aplikace do procesu databáze ani mezi každou dvojici členů clusteru.

Konfigurace, která obojí zapíná výslovně, místo aby dědila výchozí hodnotu šablony, vypadá zhruba takto:

client_encryption_options:
  enabled: true
  optional: false
server_encryption_options:
  internode_encryption: all

U serverových konfigurací, které povolují volitelné klientské šifrování, může přijímání TLS existovat vedle přijímání nešifrovaných připojení, takže čtěte skutečnou politiku, ne úmysl. Naplánujte názvy certifikátů, distribuci důvěry a obnovu pro koncové body, se kterými každý klient skutečně komunikuje; nahrazení názvu hostitele adresou IP mění kontrolu identity klienta, ne jen jeho trasu.

Držte administraci na vlastní cestě

Mezouzlový provoz potřebuje povolenou množinu partnerů a vlastní politiku ochrany. Administrativní přístup, včetně JMX tam, kde se používá, potřebuje samostatné publikum a vlastní ověřování. Aplikace s povolením vydávat běžné dotazy tím nezískává každou možnost správy a opak je horší: administrativní cesta vystavená segmentu aplikací je nejkratší trasa od chyby k přebudování. Zapište tato dvě publika odděleně a pojmenujte jejich vlastníky, protože to bývají různé týmy, jejichž pravidla se sloučila omylem.

Držte skutečná cloudová pravidla, pravidla hostitele a konfiguraci listeneru v souladu. Soukromý listener může být stále vystaven neúmyslným překladem nebo proxy a široké veřejné pravidlo může tiše sedět vedle úzkého pravidla VPN, dokud někdo neaudituje obojí najednou.

Tam, kde operátoři skutečně potřebují cestu pro správu, dejte jí pojmenovaného vlastníka a kratší životnost přihlašovacích údajů, než má aplikace. To udržuje delegování viditelné, když cluster zdědí další člověk.

Co design slibuje

Ověřte všechny tři sliby skutečnými rolemi, ne jen testy konektivity. Schválená aplikace má dokončit svou povolenou práci a nic víc, vyloučený zdroj má selhat na klientském vstupu a identita aplikace má být odmítnuta na vyhrazených administrativních cestách. Přidejte opětovné připojení klienta a výběr uzlu do stejného testu nasazení, protože právě tam se chyby objevování projeví.

Uzavřete to třemi větami v návrhovém dokumentu: kteří klienti mohou dotazovat, které uzly mohou komunikovat a kteří operátoři mohou spravovat. Být za VPN je užitečná informace o topologii, ale není odpovědí na žádnou z těchto tří otázek.