Частен RDS от EC2: същият 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, собствениците на мрежата избират поддържана частна връзка: пиъринг, транзитен дизайн или схема със споделен VPC. Тогава трябва да съществуват и двете посоки на маршрутизиране, разрешаването на имена трябва да работи за крайната точка на RDS, а източникът, който оценява политиката на базата данни, трябва да съответства на това, което реално пристига. Съвпадащи имена на акаунти или споделени отношения за фактуриране не осигуряват нищо от това.

Препратката към група за сигурност е частта, която варира. Тя работи в няколко дизайна на частна връзка, но спира да работи в момента, в който междинно устройство пренапише източника или прекрати връзката, защото тогава базата данни вижда междинното устройство, а не групата на приложението ви. Сценариите на VPC за RDS отделят достъпа в един и същ 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'

Ако връзката е успешна от екземпляра и се проваля от бюрото ви, пътят на приложението е наред и достъпът ви е това, което трябва да се поправи. Ако се проваля и от двете, започнете с проверките на групата и маршрута по-горе, а не с идентификационните данни. Това единствено сравнение предотвратява по-голямата част от объркването, което тези заявки създават.