Zasebni RDS iz EC2: ista VPC, peering ali kaj drugega?

Prenosnik razvijalca doseže zasebno instanco RDS prek VPN osebja, aplikacija na EC2 pa se sploh ne more povezati. To ni pokvarjena namestitev. Prenosnik ima tunel, ki ga instanca EC2 nikoli ne podeduje, in »zasebno« v RDS pomeni, da baza nima javne končne točke, ne pa da so človeški uporabniki VPN edini dovoljeni klicatelji. Aplikacija potrebuje lastno odobreno pot, lasten odnos z varnostno skupino in lastno identiteto v bazi, in vrstni red izbire teh treh prihrani večino odpravljanja napak. Najprej se odločite za pot, nato za dovoljenja in na koncu preverite iz nameščenega okolja, ne s svoje mize.

VPN prenosnika ni pot aplikacije

Karkoli VPN osebja počne za ljudi, za instanco ne počne ničesar, razen če je ta instanca izrecno del iste omrežne poti. Instanca EC2 v zasebni podomrežji doseže RDS prek usmerjanja VPC, varnostnih skupin in omrežnih ACL. Ne podeduje človeškega tunela, človeške seje ali človeških poverilnic in tega tudi ne bi smela: nenadzorovana povezljivost aplikacij in oddaljeni dostop osebja morata delovati neodvisno.

Ta neodvisnost je prednost. Ko VPN pade, aplikacija še naprej deluje. Ko se aplikacija vede slabo, nihče ne izgubi oddaljenega dostopa. Zasnove, ki oboje zlijeta v eno pot, se običajno odkrijejo med incidentom, v najslabšem možnem trenutku.

Odločitev 1: ista VPC, neposredna pot

Ko sta aplikacija in baza v isti VPC z neposrednim usmerjanjem in brez vmesne naprave za pregledovanje med njima, je pot preprosta in sklic na varnostno skupino najmočnejše razpoložljivo orodje. Dajte aplikaciji lastno skupino, nato dovolite vrata baze iz te skupine namesto iz razpona naslovov:

aws ec2 authorize-security-group-ingress --group-id sg-0db123   --protocol tcp --port 5432 --source-group sg-0app456

aws rds describe-db-instances --db-instance-identifier prod-db   --query 'DBInstances[0].{Endpoint:Endpoint.Address,Port:Endpoint.Port,Public:PubliclyAccessible,Groups:VpcSecurityGroups}'

Vrata so ponazoritev in se morajo ujemati z motorjem. Sklic na skupino dovoljuje promet iz instanc aplikacije; ne kopira njihovih pravil in ne ustvari prijave v bazo. Dve ločeni težavi, dve ločeni rešitvi.

Nato preverite preostanek poti, namesto da bi se ustavili pri pravilu, ki ste ga pravkar dodali. Odhodna politika aplikacije, celoten nabor skupin, povezanih z bazo, tabele usmerjanja podomrežja in vsi omrežni ACL se morajo ujemati. Pravila varnostnih skupin so stanjska, medtem ko mora omrežni ACL po meri dovoliti zahtevo in povratni promet v ločenih pravilih, vključno z efemernimi vrati. Ozko novo pravilo baze tudi ne razveljavi starejšega širokega dovoljenja, ki je bilo že povezano.

Odločitev 2: druga VPC ali drug račun

Če je aplikacija v drugi VPC, lastniki omrežja izberejo podprto zasebno povezavo: peering, tranzitno zasnovo ali dogovor o deljeni VPC. Nato morata obstajati obe smeri usmerjanja, razreševanje imen mora delovati za končno točko RDS, in vir, ki ga ocenjuje politika baze, se mora ujemati s tem, kar dejansko prispe. Ujemajoča imena računov ali skupno razmerje obračunavanja ne ponujajo nič od tega.

Sklic na varnostno skupino je del, ki se razlikuje. Deluje v več zasnovah zasebne povezave, vendar preneha delovati v trenutku, ko vmesna naprava prepiše vir ali zaključi povezavo, ker baza takrat vidi vmesno napravo in ne vaše skupine aplikacije. Scenariji VPC v RDS ločujejo dostop v isti VPC od drugih ureditev in vredno je preveriti svojo konkretno topologijo proti njim, preden domnevate, da se slog pravila prenese.

Manjkajoče poti ne rešujte tako, da bazo naredite javno dostopno. To je druga odločitev o izpostavljenosti z drugim lastnikom in običajno jo predlaga tisti, ki je najdlje od posledice.

Odločitev 3: kakšno identiteto baza sprejme

Omrežni dostop in preverjanje pristnosti baze sta ločeni plasti, njuno mešanje pa ustvari najbolj zavajajoče napake. Vloga instance je identiteta AWS za klicanje API-jev AWS. Ni uporabnik baze. Preverjanje pristnosti baze prek IAM je podprta funkcija, kjer to dovoljujeta motor in konfiguracija, in je še vedno preslikava na uporabnika baze, ne njegova zamenjava.

V konfiguraciji aplikacije uporabite ime končne točke RDS namesto naslova, pridobljenega z enim iskanjem. Preklop ob napaki Multi-AZ spremeni naslov za tem imenom in aplikacija, pripeta na IP, bo spodletela točno v trenutku, ko je potrebna. Pustite preverjanje TLS motorja vključeno, namesto da bi ga izklopili, da napaka izgine, ker vam neuspeh preverjanja nekaj pove o končni točki, ki ste jo dosegli.

Nato dodelite računu baze minimum, ki ga aplikacija potrebuje, v shemi, ki jo dejansko uporablja. To delo je dolgočasno, je revizijsko in je del, po katerem bo vprašal pregled incidenta.

Preverite iz nameščenega okolja

Preizkusite iz instance ali iz opravila, ki teče z isto skupino, podomrežjem in vlogo. Štiri napake so s prenosnika videti podobno in jih je od tam zlahka ločiti: ime, ki se ne razreši, povezava, ki poteče, neuspeh preverjanja TLS in zavrnjena prijava v bazo. Vsaka kaže na drugo mejo, spreminjanje izpostavljenosti baze, preden veste, katero imate, pa je ugibanje.

psql "host=prod-db.abc123.eu-west-1.rds.amazonaws.com port=5432 dbname=app sslmode=verify-full" -c 'select 1'

Če povezava uspe iz instance in spodleti z vaše mize, je pot aplikacije v redu in vaš dostop je tisto, kar je treba popraviti. Če spodleti iz obeh, začnite s preverjanji skupine in poti zgoraj in ne s poverilnicami. Ta ena primerjava prepreči večino zmede, ki jo ustvarijo te zahteve.