Приватни RDS из EC2: исти VPC, peering или нешто друго?

Лаптоп програмера долази до приватне RDS инстанце преко VPN-а за особље, али апликација на EC2 не може уопште да се повеже. То није покварено постављање. Лаптоп има тунел који EC2 инстанца никада не наслеђује, а „приватно“ у RDS-у значи да база података нема јавну завршну тачку, а не да су људски корисници VPN-а једини дозвољени позиваоци. Апликацији треба сопствена одобрена путања, сопствени однос са безбедносном групом и сопствени идентитет у бази података, а редослед којим бирате та три штеди већи део отклањања грешака. Прво одлучите руту, затим дозволе, а затим проверите из постављеног окружења, а не са свог радног стола.

VPN лаптопа није путања апликације

Шта год VPN за особље чини за људе, не чини ништа за инстанцу осим ако је та инстанца изричито део исте мрежне путање. EC2 инстанца у приватној подмрежи долази до RDS-а кроз VPC усмеравање, безбедносне групе и мрежне ACL-ове. Не наслеђује човеков тунел, човекову сесију ни човекове акредитиве, и не треба: надзирана повезаност апликација и удаљени приступ особља морају бити независно оперативни.

Та независност је предност. Када VPN не ради, апликација наставља да ради. Када се апликација понаша лоше, нико не губи удаљени приступ. Дизајни који спајају то двоје у једну путању обично се открију током инцидента, у најгорем могућем тренутку.

Одлука 1: исти VPC, директна путања

Када су апликација и база података у истом VPC-у са директним усмеравањем и без посредничког уређаја за инспекцију између њих, путања је једноставна, а референца на безбедносну групу најјачи је доступни алат. Дајте апликацији сопствену групу, па дозволите порт базе података са те групе уместо из опсега адреса:

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

Порт је илустративан и мора да одговара механизму. Референца на групу одобрава саобраћај са инстанци апликације; не копира њихова правила и не ствара пријаву у базу података. Два одвојена проблема, два одвојена решења.

Затим проверите остатак путање уместо да се зауставите на правилу које сте управо додали. Излазна политика апликације, комплетан скуп група повезаних са базом података, табеле усмеравања подмреже и сви мрежни ACL-ови морају да се слажу. Правила безбедносних група имају стање, док прилагођени мрежни ACL мора да дозволи захтев и повратни саобраћај у засебним правилима, укључујући ефемерне портове. Уско ново правило базе података такође не поништава старије широко одобрење које је већ било повезано.

Одлука 2: други VPC или други налог

Ако је апликација у другом VPC-у, власници мреже бирају подржану приватну везу: peering, транзитни дизајн или договор о заједничком VPC-у. Тада морају да постоје оба смера усмеравања, разрешавање имена мора да ради за RDS завршну тачку, а извор који процењује политика базе података мора да одговара ономе што стварно стиже. Подударање назива налога или заједнички однос наплате не даје ништа од тога.

Референца на безбедносну групу је део који варира. Ради у неколико дизајна приватне везе, али престаје да ради у тренутку када посреднички уређај препише извор или прекине везу, јер база података тада види посреднички уређај, а не вашу апликациону групу. RDS VPC сценарији одвајају приступ унутар истог VPC-а од осталих аранжмана и вреди проверити своју конкретну топологију према њима пре него што претпоставите да се стил правила преноси.

Не решавајте недостајућу руту тако што ћете базу података учинити јавно доступном. То је друга одлука о излагању са другим власником и обично је предлаже онај који је најдаље од последице.

Одлука 3: који идентитет база података прихвата

Мрежни приступ и аутентикација у бази података су одвојени слојеви, а њихово мешање ствара највише заваравајућих грешака. Рола инстанце је AWS идентитет за позивање AWS API-ја. Она није корисник базе података. IAM аутентикација базе података је подржана функција где то механизам и конфигурација дозвољавају и још увек је мапирање на корисника базе података, а не његова замена.

Користите назив RDS завршне тачке у конфигурацији апликације уместо адресе узете из једног претраживања. Multi-AZ пребацивање мења адресу иза тог назива, а апликација везана за IP неће успети тачно у тренутку када је потребна. Оставите TLS проверу механизма укљученом уместо да је искључите како би грешка нестала, јер неуспех провере говори вам нешто о завршној тачки до које сте дошли.

Затим доделите налогу базе података минимум који апликација треба, у шеми коју стварно користи. Тај посао је досадан, ревидиран је и део је о којем ће преглед инцидента питати.

Проверите из постављеног окружења

Тестирајте са инстанце или са задатка који ради са истом групом, подмрежом и ролом. Четири неуспеха изгледају слично са лаптопа и лако се разликују одатле: назив који се не разрешава, веза која истиче, неуспех TLS провере и одбијена пријава у базу података. Сваки упућује на другу границу, а мењање изложености базе података пре него што сазнате који имате је нагађање.

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

Ако веза успе са инстанце, а не успе са стола, путања апликације је у реду и ваш приступ је оно што треба поправити. Ако не успе са оба, почните са проверама групе и руте изнад, а не са акредитивима. То једно поређење спречава већи део застоја које ти тикети стварају.