RDS privado desde EC2: mesma VPC, peering ou outra cousa?

O portátil do desenvolvedor chega á instancia privada de RDS a través da VPN do persoal, pero a aplicación en EC2 non pode conectarse de ningún xeito. Iso non é un despregamento roto. O portátil ten un túnel que a instancia EC2 nunca herda, e «privado» en RDS significa que a base de datos non ten ningún punto de conexión público, non que os usuarios humanos da VPN sexan os únicos chamadores permitidos. A aplicación necesita a súa propia ruta autorizada, a súa propia relación co grupo de seguridade e a súa propia identidade de base de datos, e a orde na que escolle esas tres cousas aforra a maior parte da depuración. Decida a ruta primeiro, logo os permisos e por último verifique desde a contorna despregada en lugar de desde o seu escritorio.

A VPN do portátil non é a ruta da aplicación

Faga o que faga a VPN do persoal polas persoas, non fai nada por unha instancia a menos que esa instancia forme parte explícita da mesma ruta de rede. Unha instancia EC2 nunha subrede privada chega a RDS mediante o enrutamento de VPC, os grupos de seguridade e as ACL de rede. Non herda o túnel dunha persoa, a sesión dunha persoa nin as credenciais dunha persoa, e non debería: a conectividade de aplicacións sen supervisión e o acceso remoto do persoal deben poder operarse de forma independente.

Esa independencia é unha vantaxe. Cando a VPN falla, a aplicación segue funcionando. Cando a aplicación se comporta mal, ninguén perde o seu acceso remoto. Os deseños que fusionan ambas as cousas nunha soa ruta adoitan descubrirse durante un incidente, no peor momento posible.

Decisión 1: mesma VPC, ruta directa

Cando a aplicación e a base de datos están na mesma VPC con enrutamento directo e sen ningún dispositivo intermedio de inspección entre elas, a ruta é sinxela e a referencia ao grupo de seguridade é a ferramenta máis potente dispoñible. Dea á aplicación o seu propio grupo e logo permita o porto da base de datos desde ese grupo en lugar de desde un rango de enderezos:

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

O porto é ilustrativo e debe coincidir co motor. Unha referencia de grupo autoriza o tráfico desde as instancias da aplicación; non copia as súas regras nin crea un inicio de sesión na base de datos. Dous problemas separados, dúas solucións separadas.

Despois revise o resto da ruta en lugar de deterse na regra que acaba de engadir. A política de saída da aplicación, o conxunto completo de grupos conectados á base de datos, as táboas de rutas da subrede e calquera ACL de rede deben coincidir. As regras dos grupos de seguridade teñen estado, mentres que unha ACL de rede personalizada debe permitir a petición e o tráfico de retorno en regras separadas, incluídos os portos efímeros. Unha regra nova e estreita para a base de datos tampouco cancela unha autorización ampla anterior que xa estaba conectada.

Decisión 2: outra VPC ou outra conta

Se a aplicación está noutra VPC, os propietarios da rede elixen unha interconexión privada compatible: peering, un deseño de tránsito ou un acordo de VPC compartida. Entón deben existir ambas as direccións de enrutamento, a resolución de nomes debe funcionar para o punto de conexión de RDS, e a orixe que avalia a política da base de datos debe coincidir co que chega realmente. Os nomes de conta coincidentes ou unha relación de facturación compartida non achegan nada diso.

A referencia ao grupo de seguridade é a parte que varía. Funciona en varios deseños de interconexión privada, pero deixa de funcionar no momento en que un dispositivo intermedio reescribe a orixe ou termina a conexión, porque entón a base de datos ve o dispositivo intermedio en lugar do seu grupo de aplicación. Os escenarios de VPC de RDS separan o acceso dentro da mesma VPC dos demais arranxos, e paga a pena comprobar a súa topoloxía concreta con eles antes de supoñer que un estilo de regra se traslada.

Non resolva unha ruta que falta facendo que a base de datos sexa accesible publicamente. Esa é outra decisión de exposición con outro propietario, e normalmente propóna quen está máis lonxe da consecuencia.

Decisión 3: que identidade acepta a base de datos

O acceso de rede e a autenticación da base de datos son capas separadas, e confundilas produce os erros máis enganosos. O rol da instancia é unha identidade de AWS para chamar as API de AWS. Non é un usuario de base de datos. A autenticación de base de datos con IAM é unha función compatible onde o motor e a configuración o permiten, e segue sendo unha asignación a un usuario de base de datos, non un substituto.

Utilice o nome do punto de conexión de RDS na configuración da aplicación en lugar dun enderezo capturado dunha única consulta. A conmutación por erro de Multi-AZ cambia o enderezo detrás dese nome, e unha aplicación fixada a unha IP fallará exactamente no momento en que se necesite. Manteña activada a verificación TLS do motor en lugar de desactivala para facer desaparecer un erro, porque un fallo de verificación dille algo sobre o punto de conexión ao que chegou.

Despois conceda á conta de base de datos o mínimo que a aplicación necesita, no esquema que realmente utiliza. Ese traballo é aburrido, é auditable e é a parte que preguntará unha revisión de incidente.

Verifique desde a contorna despregada

Probe desde a instancia ou desde unha tarefa que se executa co mesmo grupo, subrede e rol. Catro fallos parecen iguais desde un portátil e distínguense con facilidade desde alí: un nome que non se resolve, unha conexión que expira, un fallo de validación TLS e un inicio de sesión rexeitado na base de datos. Cada un apunta a unha fronteira diferente, e cambiar a exposición da base de datos antes de saber cal ten é adiviñar.

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

Se a conexión funciona desde a instancia e falla desde o seu escritorio, a ruta da aplicación está ben e o seu acceso é o que hai que arranxar. Se falla desde ambos, comece polas comprobacións de grupo e ruta anteriores e non polas credenciais. Esa única comparación evita a maior parte do ruído que xeran estes tíckets.