Приватний 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, а джерело, яке оцінює політика бази даних, має відповідати тому, що справді надходить. Збіг назв облікових записів або спільні відносини виставлення рахунків не дають нічого з цього.

Посилання на групу безпеки — це та частина, яка змінюється. Воно працює в кількох проєктах приватних з'єднань, але перестає працювати в момент, коли проміжний пристрій переписує джерело або завершує з'єднання, бо тоді база даних бачить проміжний пристрій, а не вашу групу застосунку. Сценарії VPC для RDS відокремлюють доступ у межах однієї VPC від інших схем, і варто перевірити свою конкретну топологію щодо них, перш ніж припускати, що стиль правила переноситься.

Не вирішуйте проблему відсутнього маршруту, роблячи базу даних загальнодоступною. Це інше рішення про розкриття з іншим власником, і зазвичай його пропонує той, хто найдалі від наслідку.

Рішення 3: яку ідентичність приймає база даних

Мережевий доступ і автентифікація в базі даних — окремі рівні, і їхнє змішування породжує найбільш оманливі помилки. Роль екземпляра — це ідентичність AWS для виклику API AWS. Це не користувач бази даних. Автентифікація в базі даних через 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'

Якщо з'єднання успішне з екземпляра і невдале з вашого столу, шлях застосунку в порядку, і виправляти треба ваш доступ. Якщо воно невдале з обох, почніть із перевірок групи та маршруту вище, а не з облікових даних. Це єдине порівняння запобігає більшій частині метушні, яку створюють ці заявки.