Приватен RDS од EC2: истиот VPC, peering или нешто друго?
Изберете ја рутата пред безбедносната група: истиот VPC, peering, споделен VPC или приватна врска.
Лаптопот на развивачот стигнува до приватната 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'
Ако врската успее од инстанцата, а не успее од вашата маса, патеката на апликацијата е во ред и вашиот пристап е она што треба да се поправи. Ако не успее од двете, почнете со проверките на групата и рутата погоре, а не со акредитивите. Таа единствена споредба го спречува најголемиот дел од метежот што го создаваат овие тикети.