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

Prenosni računar programera dolazi do privatne RDS instance preko VPN-a za osoblje, ali aplikacija na EC2 ne može da se poveže uopšte. To nije pokvareno postavljanje. Laptop ima tunel koji EC2 instanca nikada ne nasleđuje, a „privatno“ u RDS-u znači da baza podataka nema javnu završnu tačku, a ne da su ljudski korisnici VPN-a jedini dozvoljeni pozivaoci. Aplikaciji treba sopstvena odobrena putanja, sopstveni odnos sa sigurnosnom grupom i sopstveni identitet u bazi podataka, a redosled kojim birate ta tri štedi veći deo otklanjanja grešaka. Prvo odlučite rutu, zatim dozvole, a zatim proverite iz postavljenog okruženja, a ne sa svog radnog stola.

VPN laptopa nije putanja aplikacije

Šta god VPN za osoblje čini za ljude, ne čini ništa za instancu osim ako je ta instanca izričito deo iste mrežne putanje. EC2 instanca u privatnoj podmreži dolazi do RDS-a kroz VPC usmeravanje, sigurnosne grupe i mrežne ACL-ove. Ne nasleđuje čovekov tunel, čovekovu sesiju ni čovekove akreditive, i ne treba: nadzirana povezanost aplikacija i udaljeni pristup osoblja moraju biti nezavisno operativni.

Ta nezavisnost je prednost. Kada VPN ne radi, aplikacija nastavlja da radi. Kada se aplikacija ponaša loše, niko ne gubi udaljeni pristup. Dizajni koji spajaju to dvoje u jednu putanju obično se otkriju tokom incidenta, u najgorem mogućem trenutku.

Odluka 1: isti VPC, direktna putanja

Kada su aplikacija i baza podataka u istom VPC-u sa direktnim usmeravanjem 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 sopstvenu grupu, pa dozvolite port baze podataka sa te grupe umesto iz opsega 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 da odgovara mehanizmu. Referenca na grupu odobrava saobraćaj sa instanci aplikacije; ne kopira njihova pravila i ne stvara prijavu u bazu podataka. Dva odvojena problema, dva odvojena rešenja.

Zatim proverite ostatak putanje umesto da se zaustavite na pravilu koje ste upravo dodali. Izlazna politika aplikacije, kompletan skup grupa povezanih sa bazom podataka, tabele usmeravanja podmreže i svi mrežni ACL-ovi moraju da se slažu. Pravila sigurnosnih grupa imaju stanje, dok prilagođeni mrežni ACL mora da dozvoli zahtev i povratni saobraćaj u zasebnim pravilima, uključujući efemerne portove. Usko novo pravilo baze podataka takođe ne poništava starije široko odobrenje koje je već bilo povezano.

Odluka 2: drugi VPC ili drugi nalog

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 da postoje oba smera usmeravanja, razrešavanje imena mora da radi za RDS završnu tačku, a izvor koji procenjuje politika baze podataka mora da odgovara onome što stvarno stiže. Podudaranje naziva naloga ili zajednički odnos naplate ne daje ništa od toga.

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

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

Odluka 3: koji identitet baza podataka prihvata

Mrežni pristup i autentikacija u bazi podataka su odvojeni slojevi, a njihovo mešanje stvara najviše zavaravajućih grešaka. Rola instance je AWS identitet za pozivanje AWS API-ja. Ona nije korisnik baze podataka. IAM autentikacija baze podataka je podržana funkcija gde to mehanizam i konfiguracija dozvoljavaju i još uvek je mapiranje na korisnika baze podataka, a ne njegova zamena.

Koristite naziv RDS završne tačke u konfiguraciji aplikacije umesto adrese uzete iz jednog pretraživanja. Multi-AZ prebacivanje menja adresu iza tog naziva, a aplikacija vezana za IP neće uspeti tačno u trenutku kada je potrebna. Ostavite TLS proveru mehanizma uključenom umesto da je isključite kako bi greška nestala, jer neuspeh provere govori vam nešto o završnoj tački do koje ste došli.

Zatim dodelite nalogu baze podataka minimum koji aplikacija treba, u šemi koju stvarno koristi. Taj posao je dosadan, revidiran je i deo je o kojem će pregled incidenta pitati.

Proverite iz postavljenog okruženja

Testirajte sa instance ili sa zadatka koji radi sa istom grupom, podmrežom i rolom. Četiri neuspeha izgledaju slično sa laptopa i lako se razlikuju odatle: naziv koji se ne razrešava, veza koja ističe, neuspeh TLS provere i odbijena prijava u bazu podataka. Svaki upućuje na drugu granicu, a menjanje izloženosti baze podataka pre nego što 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 uspe sa instance, a ne uspe sa stola, putanja aplikacije je u redu i vaš pristup je ono što treba popraviti. Ako ne uspe sa oba, počnite sa proverama grupe i rute iznad, a ne sa akreditivima. To jedno poređenje sprečava veći deo zastoja koje ti tiketi stvaraju.