Soukromý RDS z EC2: stejný VPC, peering, nebo něco jiného?

Notebook vývojáře se dostane k privátní instanci RDS přes zaměstnaneckou VPN, ale aplikace na EC2 se nedokáže připojit vůbec. To není rozbité nasazení. Notebook má tunel, který instance EC2 nikdy nedědí, a „privátní“ u RDS znamená, že databáze nemá žádný veřejný koncový bod, ne to, že jedinými povolenými volajícími jsou lidští uživatelé VPN. Aplikace potřebuje vlastní autorizovanou cestu, vlastní vztah s bezpečnostní skupinou a vlastní identitu v databázi, a pořadí, ve kterém tyto tři věci zvolíte, ušetří většinu ladění. Nejprve rozhodněte trasu, potom oprávnění a potom ověřujte z nasazeného prostředí, ne od svého stolu.

VPN notebooku není cesta aplikace

Ať už zaměstnanecká VPN pro lidi dělá cokoli, pro instanci nedělá nic, pokud tato instance není výslovně součástí stejné síťové cesty. Instance EC2 v privátní podsíti dosáhne RDS přes směrování VPC, bezpečnostní skupiny a síťové ACL. Nedědí lidský tunel, lidskou relaci ani lidské přihlašovací údaje a neměla by: neobsluhované připojení aplikací a vzdálený přístup zaměstnanců musí být nezávisle provozovatelné.

Tato nezávislost je přednost. Když VPN nefunguje, aplikace dál pracuje. Když se aplikace chová špatně, nikdo neztratí vzdálený přístup. Návrhy, které obojí slévají do jedné cesty, se obvykle odhalí během incidentu, v nejhorší možný okamžik.

Rozhodnutí 1: stejný VPC, přímá cesta

Když jsou aplikace a databáze ve stejném VPC s přímým směrováním a bez inspekčního zařízení mezi nimi, je cesta jednoduchá a odkaz na bezpečnostní skupinu nejsilnějším dostupným nástrojem. Dejte aplikaci vlastní skupinu a potom povolte port databáze z této skupiny místo z rozsahu adres:

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

Port je ilustrativní a musí odpovídat enginu. Odkaz na skupinu autorizuje provoz z instancí aplikace; nekopíruje jejich pravidla a nevytváří přihlášení do databáze. Dva oddělené problémy, dvě oddělená řešení.

Potom zkontrolujte zbytek cesty, místo abyste se zastavili u pravidla, které jste právě přidali. Odchozí politika aplikace, úplná sada skupin připojených k databázi, směrovací tabulky podsítě a všechny síťové ACL musí souhlasit. Pravidla bezpečnostních skupin jsou stavová, zatímco vlastní síťová ACL musí povolit požadavek a zpětný provoz v samostatných pravidlech, včetně efemérních portů. Úzké nové pravidlo databáze také neruší starší široké povolení, které už bylo připojeno.

Rozhodnutí 2: jiný VPC nebo jiný účet

Pokud je aplikace v jiném VPC, vlastníci sítě zvolí podporované privátní propojení: peering, tranzitní návrh nebo uspořádání se sdíleným VPC. Pak musí existovat oba směry směrování, překlad názvů musí fungovat pro koncový bod RDS a zdroj, který vyhodnocuje politika databáze, musí odpovídat tomu, co skutečně přichází. Shoda názvů účtů nebo sdílený vztah pro fakturaci nic z toho neposkytuje.

Odkaz na bezpečnostní skupinu je část, která se liší. Funguje v několika návrzích privátního propojení, ale přestane fungovat ve chvíli, kdy mezilehlé zařízení přepíše zdroj nebo ukončí spojení, protože databáze pak vidí mezilehlé zařízení, a ne vaši skupinu aplikace. Scénáře VPC pro RDS oddělují přístup ve stejném VPC od ostatních uspořádání a vyplatí se ověřit svou konkrétní topologii proti nim, než předpokládáte, že se styl pravidla přenese.

Neřešte chybějící trasu tím, že databázi zpřístupníte veřejně. To je jiné rozhodnutí o vystavení s jiným vlastníkem a obvykle ho navrhuje ten, kdo je od důsledku nejdál.

Rozhodnutí 3: jakou identitu databáze přijímá

Síťový přístup a ověřování v databázi jsou oddělené vrstvy a jejich slučování vytváří nejzavádějící chyby. Role instance je identita AWS pro volání rozhraní AWS API. Není to uživatel databáze. Ověřování v databázi přes IAM je podporovaná funkce tam, kde to engine a konfigurace dovolují, a stále jde o mapování na uživatele databáze, ne o jeho nahrazení.

V konfiguraci aplikace používejte název koncového bodu RDS místo adresy získané jediným vyhledáním. Přepnutí při selhání Multi-AZ mění adresu za tímto názvem a aplikace připnutá k IP selže přesně ve chvíli, kdy je potřeba. Ponechte ověřování TLS enginu zapnuté, místo abyste ho vypínali, aby chyba zmizela, protože selhání ověření vám něco říká o koncovém bodu, kterého jste dosáhli.

Potom přidělte účtu databáze minimum, které aplikace potřebuje, ve schématu, které skutečně používá. Ta práce je nudná, je auditovatelná a je to část, na kterou se bude ptát přehled incidentu.

Ověřte z nasazeného prostředí

Testujte z instance nebo z úlohy, která běží se stejnou skupinou, podsítí a rolí. Čtyři selhání vypadají z notebooku podobně a odtud se snadno rozeznají: název, který se nepřeloží, spojení, které vyprší, selhání ověření TLS a odmítnuté přihlášení do databáze. Každé ukazuje na jinou hranici a měnit vystavení databáze dřív, než zjistíte, které máte, je hádání.

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

Pokud spojení uspěje z instance a selže od vašeho stolu, cesta aplikace je v pořádku a opravit je potřeba váš přístup. Pokud selže z obou míst, začněte kontrolami skupiny a trasy výše, ne přihlašovacími údaji. Toto jediné srovnání zabrání většině zmatků, které tyto tikety vytvářejí.