Cassandra VPN-i kaudu: eraldi juurdepääs klientidele ja sõlmedele

Cassandra juurutusel ei ole ühtset universaalset andmebaasivõrku. Rakendused räägivad klienditeenusega, klastri liikmed räägivad omavahel ja operaatorid kasutavad haldusliideseid, ning need kolm sihtrühma ei tohiks üksteise kättesaadavust pärida. Privaatne tee, näiteks VPN, on hea lähtepunkt, kuid see ei ole andmebaasi kasutajaidentiteet ega selle krüpteerimispoliitika. Käsitlege ühenduvuse otsust ja autoriseerimise otsust kahe eraldi ülevaatusena.

Iga kolmest sihtrühmast saab oma vastuse ja allolevad jaotised käsitlevad neid kokkupuute järjekorras.

Kolm sihtrühma, kolm otsust

Tehke kindlaks, mida iga rühm tegelikult vajab, enne kui reeglit puutute. Klientidel on vaja kliendikuulajat ja piisavalt teavet, et jõuda igasse sõlme, mille nad võivad saada, partner-sõlmedel on vaja üksteist sõlmedevahelisel pordil ja operaatoritel on vaja haldusliidest selle jaoks, mida runbook tegelikult nõuab. Kolm nimekirja, kolm sihtrühma, kolm usaldustaset.

Tavaline viga on ehitada üks lame privaatne segment ja eeldada, et VPN-i piir teeb ülejäänu. Selle sees jõuab rakendus, mis pääseb kliendipordile, tavaliselt ka sõlmedevahelisele pordile, ja operaatori haldustööriistad asuvad sageli samas hüppehostis kui rakendus. Nende kokku lamedaks muutmine tähendab, et kahjustatud rakenduse identiteedil on juba suurem ulatus kui tema enda päringutel. Joonistage kolm sihtrühma disainidokumenti kolme reana, igaüks koos reegliga, mis seda lubab, ja lüngad muutuvad nähtavaks enne, kui keegi need ehitab.

Mida kliendid vajavad, ja mitte rohkem

Lubage kavandatud rakenduse allikatel jõuda juurutatud versiooni kliendi lõpp-punktidesse ja hoidke mitteseotud klastri- ja haldusteenused sellest ulatusest väljas. Seejärel kontrollige, kuidas draiver sõlmi avastab. Kättesaadav esialgne kontaktpunkt ei tõenda, et iga sõlmeaadress, mille draiver seejärel valib, on sellest kliendikontekstist kättesaadav, sest draiver küsib klastrilt partnerid ja ühendub seejärel aadressidega, mida klaster reklaamib.

Seetõttu tekitab üks privaataadressi lahknevus tuttava mustri: edukas esimene ühendus, millele järgnevad aegumised. Seadistage reklaamitud aadressid ja kliendi marsruutimine teadlikult; kogu klastri internetti avaldamine ühe lahknevuse parandamiseks vahetab marsruutimisvea kokkupuute vastu, mida te tagasi võtta ei saa.

Hoidke ka rakenduse andmebaasi autentimine ja rolliõigused paigas. Jagatud tõlgitud VPN-aadress võib esindada paljusid kasutajaid või teenuseid, seega ei asenda see kunagi eraldi andmebaasi identiteete.

Krüpteerige klient-sõlm ja sõlmedevaheline liiklus eraldi

Apache'i turbedokumentatsioon käsitleb klient-sõlm ja sõlmedevahelist krüpteerimist eraldi konfiguratsioonidena ning ühe lubamine ei luba teist. See eristus kehtib ka VPN-i sees, sest tunnel kaitseb oma segmenti ega laiene automaatselt rakenduse protsessist andmebaasi protsessini ega iga klastriliikmete paari vahel.

Konfiguratsioon, mis lülitab mõlemad selgesõnaliselt sisse, mitte ei päri mallivaikeväärtust, näeb umbkaudu selline välja:

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

Serverikonfiguratsioonides, mis lubavad valikulist kliendikrüpteerimist, võib TLS-i vastuvõtmine eksisteerida koos krüpteerimata ühenduste vastuvõtmisega, seega lugege tegelikku poliitikat, mitte kavatsust. Planeerige sertifikaatide nimed, usalduse jaotus ja uuendamine nende lõpp-punktide jaoks, millega iga klient tegelikult ühendust võtab; hostinime asendamine IP-aadressiga muudab kliendi identiteedikontrolli, mitte ainult tema marsruuti.

Hoidke haldus omal teel

Sõlmedevaheline liiklus vajab lubatud partnerite kogumit ja oma kaitsetpoliitikat. Haldusjuurdepääs, sealhulgas JMX seal, kus seda kasutatakse, vajab eraldi sihtrühma ja oma autentimist. Rakendus, millel on lubatud tavalisi päringuid esitada, ei vaja seetõttu kõiki haldusvõimalusi, ja vastupidi on hullem: rakendusesegmendile avatud haldustee on lühim tee veast ülesehitamiseni. Kirjutage need kaks sihtrühma eraldi üles ja nimetage nende omanikud, sest tavaliselt on need erinevad meeskonnad, kelle reeglid said kogemata kokku pandud.

Hoidke kehtivad pilveereeglid, hostireeglid ja kuulaja konfiguratsioon kooskõlas. Privaatne kuulaja võib siiski olla avatud tahtmatu tõlke või puhverserveri kaudu, ja lai avalik reegel võib vaikselt seista kitsa VPN-reegli kõrval, kuni keegi auditeerib mõlemat korraga.

Kus operaatoritel on tõesti haldusteed vaja, andke sellele nimetatud omanik ja lühem volituste eluiga kui rakendusel. See hoiab delegeerimise nähtavana, kui järgmine inimene klastri pärib.

Mida disain lubab

Valideerige kõiki kolme lubadust päris rollidega, mitte ainult ühenduvustestidega. Kinnitatud rakendus peaks oma lubatud töö lõpetama ja mitte rohkem, välistatud allikas peaks kliendi sissepääsul ebaõnnestuma ja rakenduse identiteet tuleks reserveeritud haldusteede peal tagasi lükata. Lisage kliendi taasühendamine ja sõlme valik samasse juurutusesti, sest just seal tulevad avastusvead välja.

Lõpetage disainidokumendis kolme lausega: millised kliendid saavad pärida, millised sõlmed saavad suhelda ja millised operaatorid saavad hallata. VPN-i taga olemine on kasulik topoloogiateave, kuid see ei ole vastus ühelegi neist kolmest küsimusest.