Cassandra over VPN: separat tilgang for klienter og noder

En Cassandra-utrulling har ikke ett universelt databasenettverk. Applikasjoner snakker med klienttjenesten, klyngemedlemmer snakker med hverandre, og operatører bruker administrative grensesnitt, og disse tre publikummene bør ikke arve hverandres rekkevidde. En privat sti som et VPN er et godt utgangspunkt, men den er ikke brukeridentiteten til databasen og heller ikke krypteringspolicyen dens. Behandle tilkoblingsbeslutningen og autorisasjonsbeslutningen som to separate vurderinger.

Hvert av de tre publikummene får sitt eget svar, og avsnittene nedenfor tar dem i rekkefølge etter eksponering.

Tre publikummer, tre beslutninger

Identifiser hva hver gruppe faktisk trenger før du rører en regel. Klienter trenger klientlytteren og nok informasjon til å nå hver node de kan bli tildelt, partnernoder trenger hverandre på internode-porten, og operatører trenger administrasjonsgrensesnittet for det runbooken faktisk krever. Tre lister, tre publikummer, tre tillitsnivåer.

Den vanlige feilen er å bygge ett flatt privat segment og anta at VPN-grensen gjør resten. Inne i det kan en applikasjon som når klientporten, vanligvis også nå internode-porten, og administrasjonsverktøyene til en operatør sitter ofte på samme hoppvert som applikasjonen. Å flate disse ut sammen betyr at en kompromittert applikasjonsidentitet allerede har større rekkevidde enn sine egne spørringer. Tegn de tre publikummene som tre rader i designdokumentet, hver med regelen som tillater den, og hullene blir synlige før noen bygger dem.

Hva klientene trenger, og ikke noe mer

Tillat de tiltenkte applikasjonskildene mot klientendepunktene for den utrullede versjonen, og hold urelaterte klynge- og administrasjonstjenester utenfor den rekkevidden. Sjekk deretter hvordan driveren oppdager noder. Et nåbart første kontaktpunkt viser ikke at hver nodeadresse driveren velger etterpå er nåbar fra den klientkonteksten, for driveren spør klyngen om partnere og kobler seg så til adressene klyngen annonserer.

Derfor gir én feil i private adresser det kjente mønsteret med en vellykket første tilkobling etterfulgt av tidsavbrudd. Konfigurer annonserte adresser og klientruter med vilje; å publisere hele klyngen på internett for å reparere én feil bytter en rutefeil mot en eksponering du ikke kan ta tilbake.

Hold også databaseautentiseringen og rolletillatelsene til applikasjonen på plass. En delt oversatt VPN-adresse kan stå for mange brukere eller tjenester, så den er aldri en erstatning for egne databaseidentiteter.

Krypter klient-til-node og internode hver for seg

Apache sin sikkerhetsdokumentasjon behandler klient-til-node- og internode-kryptering som separate konfigurasjoner, og å slå på den ene slår ikke på den andre. Denne forskjellen gjelder fortsatt inne i et VPN, for tunnelen beskytter sitt eget segment og strekker seg ikke automatisk fra applikasjonsprosessen til databaseprosessen eller mellom hvert par av klyngemedlemmer.

En konfigurasjon som slår på begge eksplisitt, i stedet for å arve en malstandard, ser omtrent slik ut:

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

På serverkonfigurasjoner som tillater valgfri klientkryptering, kan aksept av TLS leve sammen med aksept av ukrypterte tilkoblinger, så les den effektive policyen og ikke intensjonen. Planlegg sertifikatnavn, tillitsdistribusjon og fornyelse for endepunktene hver klient faktisk kontakter; å bytte ut et vertsnavn med en IP-adresse endrer identitetssjekken til klienten, ikke bare ruten.

Hold administrasjon på sin egen sti

Internode-trafikk trenger det tillatte partnersettet og sin egen vernepolicy. Administrativ tilgang, inkludert JMX der det brukes, trenger et eget publikum og egen autentisering. En applikasjon som får lov til å sende vanlige spørringer trenger ikke dermed enhver administrasjonsevne, og det motsatte er verre: en administrativ sti som er eksponert mot applikasjonssegmentet, er den korteste veien fra en feil til en ombygging. Skriv de to publikummene ned hver for seg, og navngi eierne deres, for de er vanligvis ulike team der reglene har blitt slått sammen ved et uhell.

Hold effektive skyregler, vertsregler og lytterkonfigurasjon på linje. En privat lytter kan fortsatt bli eksponert gjennom en utilsiktet oversettelse eller en proxy, og en bred offentlig regel kan sitte stille ved siden av en smal VPN-regel til noen reviderer begge samtidig.

Der operatører virkelig trenger en administrativ sti, gi den en navngitt eier og kortere levetid for påloggingsdetaljer enn applikasjonens. Det holder delegeringen synlig når neste person overtar klyngen.

Hva designet lover

Valider alle tre løftene med virkelige roller i stedet for bare med tilkoblingstester. En godkjent applikasjon skal fullføre det tillatte arbeidet sitt og ikke noe mer, en utestengt kilde skal feile mot klientinngangen, og en applikasjonsidentitet skal bli avvist på de reserverte administrative stiene. Legg klientgjenoppkobling og nodevalg til den samme utrulleringstesten, for det er der oppdagelsesfeil kommer fram.

Avslutt med tre setninger i designdokumentet: hvilke klienter som kan spørre, hvilke noder som kan kommunisere, og hvilke operatører som kan administrere. Å stå bak et VPN er nyttig topologiinformasjon, men det er ikke et svar på noen av de tre spørsmålene.