Privata RDS el EC2: sama VPC, peering aŭ io alia?

La tekokomputilo de la programisto atingas la privatan RDS-instancon tra la VPN de la dungitaro, sed la aplikaĵo sur EC2 tute ne povas konektiĝi. Tio ne estas difektita deplojo. La tekokomputilo havas tunelon, kiun la EC2-instanco neniam heredas, kaj «privata» en RDS signifas, ke la datumbazo havas neniun publikan finpunkton, ne ke homaj VPN-uzantoj estas la solaj permesitaj alvokantoj. La aplikaĵo bezonas sian propran rajtigitan vojon, sian propran rilaton kun la sekureca grupo kaj sian propran datumbazan identecon, kaj la ordo, en kiu vi elektas tiujn tri, ŝparas la plej grandan parton de la sencimigado. Decidu unue pri la vojo, poste pri la permesoj, kaj poste kontrolu el la deplojita medio anstataŭ de via skribotablo.

La VPN de la tekokomputilo ne estas la vojo de la aplikaĵo

Kion ajn la VPN de la dungitaro faras por homoj, ĝi faras nenion por instanco, krom se tiu instanco estas eksplicite parto de la sama reta vojo. EC2-instanco en privata subreto atingas RDS per VPC-enkursigado, sekurecaj grupoj kaj retaj ACL-oj. Ĝi ne heredas homan tunelon, homan sesion aŭ homajn akreditaĵojn, kaj ĝi ne devus: senhoma aplikaĵa konekteco kaj la fora aliro de la dungitaro devas esti sendepende funkciigeblaj.

Tiu sendependeco estas avantaĝo. Kiam la VPN estas malsupre, la aplikaĵo daŭre funkcias. Kiam la aplikaĵo miskondutas, neniu perdas sian foran aliron. Dezajnoj, kiuj kunfandas la du en unu vojon, kutime malkovriĝas dum incidento, en la plej malbona ebla momento.

Decido 1: sama VPC, rekta vojo

Kiam la aplikaĵo kaj la datumbazo estas en la sama VPC kun rekta enkursigado kaj sen inspekta mezaparato inter ili, la vojo estas simpla kaj la referenco al sekureca grupo estas la plej forta disponebla ilo. Donu al la aplikaĵo sian propran grupon, poste permesu la datumbazan pordon el tiu grupo anstataŭ el adresaro:

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

La pordo estas ilustra kaj devas kongrui kun la motoro. Grupa referenco rajtigas trafikon el la instancoj de la aplikaĵo; ĝi ne kopias iliajn regulojn kaj ne kreas datumbazan ensaluton. Du apartaj problemoj, du apartaj solvoj.

Poste kontrolu la reston de la vojo anstataŭ halti ĉe la regulo, kiun vi ĵus aldonis. La elira politiko de la aplikaĵo, la plena aro de grupoj ligitaj al la datumbazo, la enkursigaj tabeloj de la subreto kaj eventualaj retaj ACL-oj ĉiuj devas kongrui. Sekurecaj grupoj konservas staton, dum propra reta ACL devas permesi la peton kaj la revenan trafikon en apartaj reguloj, inkluzive de efemeraj pordoj. Mallarĝa nova datumbaza regulo ankaŭ ne nuligas pli malnovan larĝan permeson, kiu jam estis ligita.

Decido 2: alia VPC aŭ alia konto

Se la aplikaĵo estas en alia VPC, la retposedantoj elektas subtenatan privatan interligon: peering, trafikan dezajnon aŭ komunan VPC-aranĝon. Tiam devas ekzisti ambaŭ direktoj de enkursigado, nomŝorbado devas funkcii por la RDS-finpunkto, kaj la fonto, kiun taksas la datumbaza politiko, devas kongrui kun tio, kio efektive alvenas. Kongruaj kontnomoj aŭ komuna faktura rilato donas neniun el tiuj.

La referenco al sekureca grupo estas la parto, kiu varias. Ĝi funkcias en pluraj dezajnoj de privata interligo, sed ĝi ĉesas funkcii en la momento, kiam mezaparato reskribas la fonton aŭ finas la konekton, ĉar tiam la datumbazo vidas la mezaparaton anstataŭ vian aplikaĵan grupon. La RDS VPC-scenaroj apartigas aliron ene de la sama VPC de la aliaj aranĝoj, kaj indas kontroli vian konkretan topologion kontraŭ ili antaŭ ol supozi, ke regulstilo translokiĝas.

Ne solvu mankan vojon farante la datumbazon publike alirebla. Tio estas alia ekspona decido kun alia posedanto, kaj ĝin kutime proponas tiu, kiu estas plej malproksime de la sekvo.

Decido 3: kian identecon la datumbazo akceptas

Reta aliro kaj datumbaza aŭtentikigo estas apartaj tavoloj, kaj ilia kunfandado produktas la plej misgvidajn erarojn. La instanca rolo estas AWS-identeco por alvoki AWS-API-ojn. Ĝi ne estas datumbaza uzanto. IAM-datumbaza aŭtentikigo estas subtenata trajto, kie la motoro kaj agordo permesas ĝin, kaj ĝi restas mapado al datumbaza uzanto anstataŭ anstataŭigo de ĝi.

Uzu la nomon de la RDS-finpunkto en la agordo de la aplikaĵo anstataŭ adreson kaptitan per unu serĉo. Multi-AZ-retroŝalto ŝanĝas la adreson malantaŭ tiu nomo, kaj aplikaĵo fiksita al IP malsukcesos ĝuste en la momento, kiam ĝi estas bezonata. Lasu la TLS-kontrolon de la motoro ŝaltita anstataŭ malŝalti ĝin por forigi eraron, ĉar kontrolmalsukceso diras al vi ion pri la finpunkto, kiun vi atingis.

Poste donu al la datumbaza konto la minimumon, kiun la aplikaĵo bezonas, en la skemo, kiun ĝi efektive uzas. Tiu laboro estas enuiga, ĝi estas auditela, kaj ĝi estas la parto, pri kiu incidenta revizio demandos.

Kontrolu el la deplojita medio

Testu el la instanco aŭ el tasko ruliĝanta kun la sama grupo, subreto kaj rolo. Kvar malsukcesoj aspektas similaj de tekokomputilo kaj facile distingeblas de tie: nomo, kiu ne solviĝas, konekto, kiu tempolimas, TLS-valida malsukceso kaj rifuzita datumbaza ensaluto. Ĉiu montras al alia limo, kaj ŝanĝi la eksponon de la datumbazo antaŭ ol scii, kiun vi havas, estas divenado.

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

Se la konekto sukcesas el la instanco kaj malsukcesas de via skribotablo, la vojo de la aplikaĵo estas en ordo kaj via aliro estas tio, kion oni devas ripari. Se ĝi malsukcesas de ambaŭ, komencu per la grupaj kaj vojaj kontroloj supre anstataŭ per la akreditaĵoj. Tiu unu komparo malhelpas la plej grandan parton de la ĥaoso, kiun tiuj biletoj kaŭzas.