Cassandra oer VPN: aparte tagong foar kliïnten en knopen

In Cassandra-útfiering hat net ien universeel databasetnetwurk. Applikaasjes prate mei de kliïnttsjinst, klusterleden prate mei elkoar en operators brûke bestjoerlike ynterfaces, en dy trije publykgroepen moatte net elkoars berikberens erve. In privee paad lykas in VPN is in goed útgongspunt, mar it is net de brûkersidentiteit fan de database en it is net syn fersiferingsbelied. Behanjele de beslissing oer ferbining en de beslissing oer autorisaasje as twee aparte resinsjes.

Elk fan de trije publykgroepen krijt syn eigen antwurd, en de seksjes hjirûnder behannelje se yn folchoarder fan bleatstelling.

Trije publyk, trije beslissingen

Bepale wat elke groep echt nedich hat foardat jo in regel oanreitsje. Kliïnten hawwe de kliïntlúster nedich en genôch ynformaasje om elke knoop te berikken dy't se krije kinne, peerknopen hawwe elkoar nedich op de tuskenknooppoarte, en operators hawwe it behearinterface nedich foar wat de runbook echt freget. Trije listen, trije publyk, trije nivo's fan fertrouwen.

De gewoane flater is ien plat privee segmint te bouwen en oan te nimmen dat de VPN-grins de rest docht. Derbinnen kin in applikaasje dy't de kliïntpoarte berikke kin meistentiids ek de tuskenknooppoarte berikke, en de bestjoerlike ark fan in operator steane faak op deselde springhost as de applikaasje. It plat meitsjen fan dy tegearre betsjut dat in komprommearre applikaasje-identiteit al mear berik hat as syn eigen queries. Tekenje de trije publykgroepen as trije rigen yn it ûntwerpdokumint, elk mei de regel dy't it tastiet, en de gatten wurde sichtber foardat immen se bout.

Wat kliïnten nedich hawwe, en net mear

Stean de bedoelde applikaasjeboarnen ta ta de kliïnteinenpunten foar de útfierde ferzje, en hâld net-relatearre kluster- en behearstsjinsten bûten dat berik. Kontrolearje dan hoe't de stjoerder knopen ûntdekt. In berikber earste kontaktpunt bewiist net dat elk knoopadres dat de stjoerder dêrnei kiest, berikber is fanút dy kliïntkontekst, omdat de stjoerder it kluster om peers freget en dan ferbynt mei hokker adressen it kluster ek oankundiget.

Dêrom jout ien mismatch fan in privee adres it bekende patroan: in suksesfolle earste ferbining folge troch time-outs. Konfigurearje oankundige adressen en kliïntrouting bewust; it hiele kluster op it ynternet pleatse om ien mismatch te reparearjen ruilet in routingflater foar in bleatstelling dy't jo net weromnimme kinne.

Hâld ek de database-autentikaasje en rolfergunningen fan de applikaasje yn plak. In dielde oersetten VPN-adres kin foar in protte brûkers of tsjinsten stean, dus it is nea in ferfanging foar aparte database-identiteiten.

Fersiferje kliïnt-oant-knoop en tuskenknopen apart

De feiligensdokumintaasje fan Apache behannelet kliïnt-oant-knoop- en tuskenknoop-fersifering as aparte konfiguraasjes, en it ynskeakeljen fan ien skakelt de oare net yn. Dat ûnderskie jildt noch hieltyd binnen in VPN, omdat de tunnel syn eigen segmint beskermet en him net automatysk útwreidet fan it applikaasjeproses nei it databseproses of tusken elk pear klusterleden.

In konfiguraasje dy't beide eksplisyt ynskeakelt, yn stee fan in sjabloanstandert te erven, sjocht der sa sawat út:

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

Op serverkonfiguraasjes dy't opsjonele kliïntfersifering tastean, kin it akseptearjen fan TLS bestean njonken it akseptearjen fan net-fersifere ferbiningen, lês dus it effektive belied yn stee fan de bedoeling. Plan namen fan sertifikaten, fertrouwensferdieling en fernijing foar de einpunten dy't elke kliïnt echt kontaktet; it ferfangen fan in hostnamme troch in IP-adres feroaret de identiteitskontrôle fan de kliïnt, net allinnich syn rûte.

Hâld behear op syn eigen paad

Tuskenknoopferkear hat de tastiene peerset en syn eigen beskermingsbelied nedich. Bestjoerlike tagong, ynklusyf JMX dêr't it brûkt wurdt, hat in apart publyk en syn eigen autentikaasje nedich. In applikaasje dy't gewoane queries dwaan mei, hat dêrtroch net elke behearfermogen nedich, en it omkearde is slimmer: in bestjoerlik paad dat oan it applikaasjesegmint bleatsteld is, is de koartste rûte fan in flater nei in werbou. Skriuw dy twa publykgroepen apart op en neam harren eigners, want it binne meistentiids ferskillende teams waans regels by ûngelok gearfoege binne.

Hâld effektive cloudregels, hostregels en lústerkonfiguraasje op ien line. In privee lúster kin noch hieltyd bleatsteld wurde fia in ûnbedoelde oersetting of proxy, en in brede iepenbiere regel kin stil njonken in smelle VPN-regel stean oant immen beide tagelyk auditet.

Dêr't operators echt in behearpaad nedich hawwe, jou it in neamde eigner en in koartere libbensdoer fan bewiisstikken as dy fan de applikaasje. Dat hâldt de delegaasje sichtber as de folgjende persoan it kluster erft.

Wat it ûntwerp belooft

Falidiearje alle trije beloften mei echte rollen yn stee fan allinnich mei ferbiningstests. In goedkarde applikaasje moat syn tastiene wurk foltôgje en net mear, in útsletten boarne moat by de kliïntyngong mislearje, en in applikaasje-identiteit moat wegere wurde op de reservearre behearspaden. Foegje kliïntfernijing en knoopseleksje ta oan deselde útroltest, want dêr komme ûntdekkingsflaters oan it ljocht.

Einigje mei trije sinnen yn it ûntwerpdokumint: hokker kliïnten queries dwaan meie, hokker knopen kommunisearje meie en hokker operators beheare meie. Efter in VPN sitte is nuttige topologyske ynformaasje, mar it is gjin antwurd op ien fan dy trije fragen.