Privatni RDS iz EC2: isti VPC, peering ili nešto drugo?

Prijenosno računalo developera dolazi do privatne RDS instance preko VPN-a za osoblje, a aplikacija na EC2 ne može se uopće povezati. To nije pokvareno postavljanje. Prijenosno računalo ima tunel koji EC2 instanca nikada ne nasljeđuje, a „privatno“ u RDS-u znači da baza podataka nema javnu završnu točku, a ne da su ljudi korisnici VPN-a jedini dopušteni pozivatelji. Aplikaciji treba vlastita odobrena putanja, vlastiti odnos sa sigurnosnom grupom i vlastiti identitet u bazi podataka, a redoslijed kojim birate ta tri štedi veći dio otklanjanja pogrešaka. Prvo odlučite rutu, zatim dopuštenja, a zatim provjerite iz postavljenog okruženja, a ne sa svog radnog stola.

VPN prijenosnog računala nije putanja aplikacije

Šta god VPN za osoblje čini za ljude, ne čini ništa za instancu, osim ako je ta instanca izričito dio iste mrežne putanje. EC2 instanca u privatnoj podmreži dolazi do RDS-a kroz VPC usmjeravanje, sigurnosne grupe i mrežne ACL-ove. Ne nasljeđuje čovjekov tunel, čovjekovu sesiju ni čovjekove vjerodajnice, i ne treba: nadzirana povezanost aplikacija i udaljeni pristup osoblja moraju biti neovisno operativni.

Ta neovisnost je prednost. Kad VPN ne radi, aplikacija nastavlja raditi. Kad se aplikacija ponaša loše, nitko ne gubi udaljeni pristup. Dizajni koji spajaju to dvoje u jednu putanju obično se otkriju tijekom incidenta, u najgorem mogućem trenutku.

Odluka 1: isti VPC, izravna putanja

Kad su aplikacija i baza podataka u istom VPC-u s izravnim usmjeravanjem i bez posredničkog uređaja za inspekciju između njih, putanja je jednostavna, a referenca na sigurnosnu grupu najjači je dostupni alat. Dajte aplikaciji vlastitu grupu, pa dopustite port baze podataka s te grupe umjesto iz raspona adresa:

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}'

Port je ilustrativan i mora odgovarati mehanizmu. Referenca na grupu odobrava promet s instanci aplikacije; ne kopira njihova pravila i ne stvara prijavu u bazu podataka. Dva odvojena problema, dva odvojena rješenja.

Zatim provjerite ostatak putanje umjesto da se zaustavite na pravilu koje ste upravo dodali. Izlazna politika aplikacije, kompletan skup grupa povezanih s bazom podataka, tablice usmjeravanja podmreže i svi mrežni ACL-ovi moraju se slagati. Pravila sigurnosnih grupa imaju stanje, dok prilagođeni mrežni ACL mora dopustiti zahtjev i povratni promet u zasebnim pravilima, uključujući efemerne portove. Uska nova pravila baze podataka također ne poništavaju starije široko dopuštenje koje je već bilo povezano.

Odluka 2: drugi VPC ili drugi račun

Ako je aplikacija u drugom VPC-u, vlasnici mreže biraju podržanu privatnu vezu: peering, tranzitni dizajn ili dogovor o zajedničkom VPC-u. Tada moraju postojati oba smjera usmjeravanja, razrješavanje imena mora raditi za RDS završnu točku, a izvor koji procjenjuje politika baze podataka mora odgovarati onome što stvarno stiže. Podudaranje naziva računa ili zajednički odnos naplate ne daje ništa od toga.

Referenca na sigurnosnu grupu je dio koji varira. Radi u nekoliko dizajna privatne veze, ali prestaje raditi u trenutku kad posrednički uređaj prepiše izvor ili prekine vezu, jer baza podataka tada vidi posrednički uređaj, a ne vašu grupu aplikacije. RDS VPC scenariji odvajaju pristup unutar istog VPC-a od ostalih aranžmana i vrijedi provjeriti svoju konkretnu topologiju prema njima prije nego pretpostavite da se stil pravila prenosi.

Ne rješavajte nedostajuću rutu tako što ćete bazu podataka učiniti javno dostupnom. To je druga odluka o izlaganju s drugim vlasnikom i obično je predlaže onaj koji je najdalje od posljedica.

Odluka 3: koji identitet baza podataka prihvaća

Mrežni pristup i provjera autentičnosti u bazi podataka odvojeni su slojevi, a njihovo miješanje stvara najviše zavaravajućih pogrešaka. Rola instance je AWS identitet za pozivanje AWS API-ja. Ona nije korisnik baze podataka. IAM provjera autentičnosti baze podataka podržana je značajka gdje to mehanizam i konfiguracija dopuštaju i još uvijek je mapiranje na korisnika baze podataka, a ne njegova zamjena.

Koristite naziv RDS završne točke u konfiguraciji aplikacije umjesto adrese uzete iz jednog pretraživanja. Multi-AZ prebacivanje mijenja adresu iza tog naziva, a aplikacija vezana uz IP neće uspjeti točno u trenutku kad je potrebna. Ostavite TLS provjeru mehanizma uključenom umjesto da je isključite kako bi pogreška nestala, jer neuspjeh provjere govori vam nešto o završnoj točki do koje ste došli.

Zatim dodijelite računu baze podataka minimum koji aplikacija treba, u shemi koju stvarno koristi. Taj je posao dosadan, revidiran je i dio je o kojem će pregled incidenta pitati.

Provjerite iz postavljenog okruženja

Testirajte s instance ili sa zadatka koji radi s istom grupom, podmrežom i rolom. Četiri neuspjeha izgledaju slično s prijenosnog računala i lako se razlikuju odatle: naziv koji se ne razrješava, veza koja istječe, neuspjeh TLS provjere i odbijena prijava u bazu podataka. Svaki upućuje na drugu granicu, a mijenjanje izloženosti baze podataka prije nego saznate koji imate je nagađanje.

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

Ako veza uspije s instance, a ne uspije sa stola, putanja aplikacije je u redu i vaš pristup je ono što treba popraviti. Ako ne uspije s oba, počnite s provjerama grupe i rute iznad, a ne s vjerodajnicama. Ta jedna usporedba sprječava većinu zastoja koje ti tiketi stvaraju.