RDS privat des d'EC2: mateix VPC, peering o una altra cosa?

L'ordinador del desenvolupador arriba a la instància RDS privada a través de la VPN del personal, i l'aplicació a EC2 no es pot connectar de cap manera. Això no és un desplegament trencat. L'ordinador té un túnel que la instància EC2 mai no hereta, i «privat» a RDS vol dir que la base de dades no té cap punt de connexió públic, no que els usuaris humans de la VPN siguin els únics que poden trucar. L'aplicació necessita la seva pròpia ruta autoritzada, la seva pròpia relació amb el grup de seguretat i la seva pròpia identitat a la base de dades, i l'ordre amb què trieu aquestes tres coses estalvia la major part de la depuració. Decidiu primer la ruta, després els permisos i, finalment, verifiqueu-ho des de l'entorn desplegat i no des del vostre escriptori.

La VPN de l'ordinador no és la ruta de l'aplicació

Facin el que facin la VPN del personal per a les persones, no fa res per a una instància tret que aquesta instància formi part explícitament del mateix camí de xarxa. Una instància EC2 en una subxarxa privada arriba a RDS a través de l'encaminament de VPC, els grups de seguretat i les ACL de xarxa. No hereta el túnel d'una persona, la sessió d'una persona ni les credencials d'una persona, i no ho hauria de fer: la connectivitat d'aplicacions sense supervisió i l'accés remot del personal han de ser operables de manera independent.

Aquesta independència és una característica. Quan la VPN està caiguda, l'aplicació continua funcionant. Quan l'aplicació es comporta malament, ningú no perd l'accés remot. Els dissenys que fusionen les dues coses en una sola ruta solen descobrir-se durant un incident, en el pitjor moment possible.

Decisió 1: mateix VPC, ruta directa

Quan l'aplicació i la base de dades són al mateix VPC amb encaminament directe i sense cap dispositiu intermedi d'inspecció entre elles, la ruta és senzilla i la referència al grup de seguretat és l'eina més potent disponible. Doneu a l'aplicació el seu propi grup i, després, permeteu el port de la base de dades des d'aquest grup en lloc d'un interval d'adreces:

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

El port és il·lustratiu i ha de coincidir amb el motor. Una referència de grup autoritza el trànsit de les instàncies de l'aplicació; no copia les seves regles ni crea un inici de sessió a la base de dades. Dos problemes separats, dues solucions separades.

Després reviseu la resta de la ruta en lloc d'aturar-vos a la regla que acabeu d'afegir. La política de sortida de l'aplicació, el conjunt complet de grups adjunts a la base de dades, les taules d'encaminament de la subxarxa i qualsevol ACL de xarxa han de coincidir. Les regles dels grups de seguretat tenen estat, mentre que una ACL de xarxa personalitzada ha de permetre la petició i el trànsit de retorn en regles separades, incloent-hi els ports efímers. Una regla nova i estreta per a la base de dades tampoc no cancel·la una autorització àmplia anterior que ja estava adjunta.

Decisió 2: un altre VPC o un altre compte

Si l'aplicació és en un altre VPC, els propietaris de la xarxa trien una interconnexió privada compatible: peering, un disseny de trànsit o un acord de VPC compartit. Aleshores han d'existir les dues direccions d'encaminament, la resolució de noms ha de funcionar per al punt de connexió de RDS i l'origen que avalua la política de la base de dades ha de coincidir amb el que arriba realment. Els noms de compte coincidents o una relació de facturació compartida no aporten res d'això.

La referència al grup de seguretat és la part que varia. Funciona en diversos dissenys d'interconnexió privada, però deixa de funcionar en el moment que un dispositiu intermedi reescriu l'origen o tanca la connexió, perquè llavors la base de dades veu el dispositiu intermedi i no el vostre grup d'aplicació. Els escenaris de VPC de RDS separen l'accés dins del mateix VPC de la resta d'arranjaments, i val la pena comprovar la vostra topologia concreta amb ells abans de donar per fet que un estil de regla es trasllada.

No resoleu una ruta que falta fent que la base de dades sigui accessible públicament. Aquesta és una altra decisió d'exposició amb un altre propietari, i normalment la proposa qui és més lluny de la conseqüència.

Decisió 3: quina identitat accepta la base de dades

L'accés de xarxa i l'autenticació de la base de dades són capes separades, i confondre-les produeix els errors més enganyosos. El rol de la instància és una identitat d'AWS per cridar les API d'AWS. No és un usuari de base de dades. L'autenticació de base de dades amb IAM és una funció compatible on el motor i la configuració ho permeten, i continua sent una assignació a un usuari de base de dades, no un substitut.

Feu servir el nom del punt de connexió de RDS a la configuració de l'aplicació en lloc d'una adreça capturada d'una sola consulta. La commutació per error de Multi-AZ canvia l'adreça darrere d'aquest nom, i una aplicació fixada a una IP fallarà exactament en el moment que calgui. Manteniu activada la verificació TLS del motor en lloc de desactivar-la per fer desaparèixer un error, perquè un fallo de verificació us diu alguna cosa sobre el punt de connexió que heu assolit.

Després concediu al compte de base de dades el mínim que l'aplicació necessita, a l'esquema que realment utilitza. Aquesta feina és avorrida, és auditable i és la part que una revisió d'incident preguntarà.

Verifiqueu-ho des de l'entorn desplegat

Proveu-ho des de la instància o des d'una tasca que s'executi amb el mateix grup, subxarxa i rol. Quatre fallades semblen iguals des d'un ordinador i es distingeixen fàcilment des d'allà: un nom que no es resol, una connexió que expira, una fallada de validació TLS i un inici de sessió rebutjat a la base de dades. Cadascuna assenyala una frontera diferent, i canviar l'exposició de la base de dades abans de saber quina teniu és endevinar.

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

Si la connexió funciona des de la instància i falla des del vostre escriptori, la ruta de l'aplicació està bé i el vostre accés és el que cal arreglar. Si falla des de tots dos, comenceu per les comprovacions de grup i ruta anteriors i no per les credencials. Aquesta única comparació evita la major part del soroll que generen aquests tiquets.