Pribadong RDS mula sa EC2: parehong VPC, peering o iba pa?

Naabot ng laptop ng developer ang pribadong RDS instance sa pamamagitan ng VPN ng staff, ngunit ang application sa EC2 ay hindi makakonekta talaga. Hindi ito sirang deployment. Ang laptop ay may tunnel na hindi kailanman namamana ng EC2 instance, at ang «pribado» sa RDS ay nangangahulugang walang pampublikong endpoint ang database, hindi na ang mga taong VPN user ang tanging pinapayagang tumawag. Kailangan ng application ang sarili nitong awtorisadong landas, ang sarili nitong relasyon sa security group at ang sarili nitong pagkakakilanlan sa database, at ang pagkakasunod-sunod kung saan pinipili mo ang tatlong ito ay nakakatipid sa karamihan ng debugging. Magpasya muna sa ruta, pagkatapos sa mga pahintulot, at pagkatapos ay i-verify mula sa na-deploy na environment sa halip na mula sa iyong mesa.

Ang VPN ng laptop ay hindi ang landas ng application

Anuman ang ginagawa ng VPN ng staff para sa mga tao, wala itong ginagawa para sa isang instance maliban kung ang instance na iyon ay tahasang bahagi ng parehong network path. Ang EC2 instance sa isang pribadong subnet ay umabot sa RDS sa pamamagitan ng VPC routing, mga security group at network ACL. Hindi nito namamana ang tunnel ng tao, session ng tao o mga kredensyal ng tao, at hindi dapat: ang koneksyon ng application na walang pangangasiwa at ang malayuang pag-access ng staff ay dapat na independiyenteng mapatakbo.

Ang kalayaan na iyon ay isang katangian. Kapag bumaba ang VPN, patuloy na gumagana ang application. Kapag mali ang pag-uugali ng application, walang nawawalan ng malayuang pag-access. Ang mga disenyong pinagsasama ang dalawa sa isang landas ay karaniwang natutuklasan sa panahon ng insidente, sa pinakamasamang sandali.

Desisyon 1: parehong VPC, direktang landas

Kapag ang application at ang database ay nasa parehong VPC na may direktang routing at walang inspection middlebox sa pagitan nila, ang landas ay simple at ang reference sa security group ang pinakamalakas na tool na magagamit. Bigyan ang application ng sarili nitong grupo, pagkatapos ay payagan ang port ng database mula sa grupong iyon sa halip na mula sa isang hanay ng address:

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

Ang port ay ilustratibo lamang at dapat tumugma sa engine. Ang reference ng grupo ay nagpapahintulot ng trapiko mula sa mga instance ng application; hindi nito kinokopya ang kanilang mga patakaran at hindi ito gumagawa ng pag-login sa database. Dalawang magkahiwalay na problema, dalawang magkahiwalay na pag-aayos.

Pagkatapos ay suriin ang natitirang landas sa halip na huminto sa patakarang idinagdag mo lang. Ang outbound policy ng application, ang buong set ng mga grupong nakakabit sa database, ang mga routing table ng subnet at anumang network ACL ay dapat magkasundo lahat. Ang mga patakaran ng security group ay may estado, samantalang ang custom na network ACL ay dapat pumayag sa kahilingan at sa trapikong pabalik sa magkahiwalay na patakaran, kabilang ang mga ephemeral port. Ang isang bagong makitid na patakaran ng database ay hindi rin nagkakansela ng isang mas lumang malawak na pahintulot na nakakabit na.

Desisyon 2: ibang VPC o ibang account

Kung ang application ay nasa ibang VPC, pinipili ng mga may-ari ng network ang isang sinusuportahang pribadong interkoneksyon: peering, disenyo ng transit o kasunduan sa shared VPC. Pagkatapos ay dapat umiral ang parehong direksyon ng routing, dapat gumana ang resolusyon ng pangalan para sa endpoint ng RDS, at ang source na sinusuri ng patakaran ng database ay dapat tumugma sa aktwal na dumarating. Ang magkatugmang pangalan ng account o shared na relasyon sa pagsingil ay wala sa mga iyon.

Ang reference sa security group ang bahaging nag-iiba. Gumagana ito sa ilang disenyo ng pribadong interkoneksyon, ngunit tumitigil ito sa paggana sa sandaling muling isulat ng middlebox ang source o tapusin ang koneksyon, dahil nakikita ng database ang middlebox sa halip na ang iyong application group. Ang mga senaryo ng RDS VPC ay naghihiwalay ng pag-access sa loob ng parehong VPC mula sa iba pang mga kaayusan, at sulit na suriin ang iyong partikular na topolohiya laban sa mga iyon bago ipagpalagay na naililipat ang isang istilo ng patakaran.

Huwag lutasin ang nawawalang ruta sa pamamagitan ng paggawang pampublikong maa-access ang database. Iba iyon na desisyon sa pag-expose na may ibang may-ari, at karaniwang iminumungkahi ito ng taong pinakamalayo sa kahihinatnan.

Desisyon 3: anong pagkakakilanlan ang tinatanggap ng database

Ang pag-access sa network at pagpapatotoo ng database ay magkahiwalay na layer, at ang paghahalo sa mga ito ay lumilikha ng pinaka-nakalilitong mga error. Ang role ng instance ay isang pagkakakilanlang AWS para tumawag ng mga API ng AWS. Hindi ito isang database user. Ang pagpapatotoo ng database sa IAM ay isang sinusuportahang feature kung saan pinapayagan ng engine at configuration, at ito ay nananatiling mapping sa isang database user, hindi isang kapalit.

Gamitin ang pangalan ng endpoint ng RDS sa configuration ng application sa halip na isang address na nakuha mula sa isang paghahanap. Binabago ng Multi-AZ failover ang address sa likod ng pangalang iyon, at ang application na naka-pin sa isang IP ay mabibigo sa eksaktong sandaling kailangan ito. Iwanang bukas ang TLS verification ng engine sa halip na patayin ito para mawala ang isang error, dahil may sinasabi sa iyo ang pagkabigo ng verification tungkol sa endpoint na naabot mo.

Pagkatapos ay bigyan ang database account ng minimum na kailangan ng application, sa schema na aktwal na ginagamit nito. Ang gawaing iyon ay nakakabagot, naa-audit, at ito ang bahaging tatanungin ng isang pagsusuri ng insidente.

I-verify mula sa na-deploy na environment

Subukan mula sa instance o mula sa gawaing tumatakbo kasama ang parehong grupo, subnet at role. Apat na pagkabigo ang magkamukha mula sa laptop at madaling makilala mula doon: isang pangalang hindi nagre-resolve, isang koneksyong nag-time out, isang pagkabigo sa TLS validation at isang tinanggihang pag-login sa database. Ang bawat isa ay tumuturo sa ibang hangganan, at ang pagbabago ng pag-expose ng database bago malaman kung alin ang mayroon ka ay hulaan.

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

Kung nagtatagumpay ang koneksyon mula sa instance at nabibigo mula sa iyong mesa, maayos ang landas ng application at ang iyong pag-access ang kailangang ayusin. Kung nabibigo ito mula sa pareho, magsimula sa mga pagsusuri ng grupo at ruta sa itaas sa halip na sa mga kredensyal. Ang nag-iisang paghahambing na iyon ay pumipigil sa karamihan ng gulo na nililikha ng mga ticket na ito.