RDS privé depuis EC2 : même VPC, peering ou autre chose ?

L’ordinateur portable du développeur atteint l’instance RDS privée via le VPN du personnel, mais l’application sur EC2 ne peut pas se connecter du tout. Ce n’est pas un déploiement cassé. Le portable dispose d’un tunnel que l’instance EC2 n’hérite jamais, et « privé » dans RDS signifie que la base de données n’a pas de point de terminaison public, pas que les utilisateurs humains du VPN soient les seuls appelants autorisés. L’application a besoin de sa propre route autorisée, de sa propre relation avec le groupe de sécurité et de sa propre identité de base de données, et l’ordre dans lequel vous choisissez ces trois éléments économise l’essentiel du débogage. Décidez d’abord la route, puis les autorisations, puis vérifiez depuis l’environnement déployé plutôt que depuis votre bureau.

Le VPN du portable n’est pas la route de l’application

Quoi que fasse le VPN du personnel pour les personnes, il ne fait rien pour une instance, sauf si cette instance fait explicitement partie du même chemin réseau. Une instance EC2 dans un sous-réseau privé atteint RDS via le routage VPC, les groupes de sécurité et les ACL réseau. Elle n’hérite pas du tunnel d’une personne, de la session d’une personne ni des identifiants d’une personne, et elle ne devrait pas : la connectivité des applications sans surveillance et l’accès distant du personnel doivent être exploitables indépendamment.

Cette indépendance est un atout. Quand le VPN tombe, l’application continue de fonctionner. Quand l’application se comporte mal, personne ne perd son accès distant. Les conceptions qui fusionnent les deux en une seule route se découvrent généralement lors d’un incident, au pire moment possible.

Décision 1 : même VPC, route directe

Lorsque l’application et la base de données sont dans le même VPC avec un routage direct et sans boîtier d’inspection entre elles, la route est simple et la référence au groupe de sécurité est l’outil le plus puissant disponible. Donnez à l’application son propre groupe, puis autorisez le port de la base de données depuis ce groupe plutôt que depuis une plage d’adresses :

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

Le port est illustratif et doit correspondre au moteur. Une référence de groupe autorise le trafic depuis les instances de l’application ; elle ne copie pas leurs règles et ne crée pas d’identifiant de base de données. Deux problèmes distincts, deux correctifs distincts.

Vérifiez ensuite le reste du chemin au lieu de vous arrêter à la règle que vous venez d’ajouter. La politique sortante de l’application, l’ensemble complet des groupes attachés à la base de données, les tables de routage du sous-réseau et toute ACL réseau doivent tous concorder. Les règles des groupes de sécurité sont à état, tandis qu’une ACL réseau personnalisée doit autoriser la requête et le trafic de retour dans des règles distinctes, ports éphémères compris. Une nouvelle règle étroite pour la base de données n’annule pas non plus une ancienne autorisation large déjà attachée.

Décision 2 : autre VPC ou autre compte

Si l’application est dans un autre VPC, les propriétaires du réseau choisissent une interconnexion privée prise en charge : peering, une conception de transit ou un accord de VPC partagé. Ensuite, les deux directions de routage doivent exister, la résolution de noms doit fonctionner pour le point de terminaison RDS, et la source évaluée par la politique de la base de données doit correspondre à ce qui arrive réellement. Des noms de compte identiques ou une relation de facturation partagée n’apportent rien de tout cela.

La référence au groupe de sécurité est la partie qui varie. Elle fonctionne dans plusieurs conceptions d’interconnexion privée, mais cesse de fonctionner dès qu’un boîtier intermédiaire réécrit la source ou termine la connexion, car la base de données voit alors le boîtier intermédiaire plutôt que votre groupe d’application. Les scénarios VPC de RDS séparent l’accès au sein du même VPC des autres dispositions, et il vaut la peine de vérifier votre topologie précise par rapport à eux avant de supposer qu’un style de règle se transpose.

Ne résolvez pas une route manquante en rendant la base de données accessible publiquement. C’est une autre décision d’exposition avec un autre propriétaire, et elle est généralement proposée par celui qui est le plus éloigné de la conséquence.

Décision 3 : quelle identité la base de données accepte

L’accès réseau et l’authentification de la base de données sont des couches distinctes, et les confondre produit les erreurs les plus trompeuses. Le rôle de l’instance est une identité AWS pour appeler les API AWS. Ce n’est pas un utilisateur de base de données. L’authentification de base de données IAM est une fonctionnalité prise en charge lorsque le moteur et la configuration le permettent, et elle reste une correspondance vers un utilisateur de base de données, pas un remplacement.

Utilisez le nom du point de terminaison RDS dans la configuration de l’application plutôt qu’une adresse capturée lors d’une seule recherche. Le basculement Multi-AZ change l’adresse derrière ce nom, et une application épinglée à une IP échouera exactement au moment où elle est nécessaire. Laissez la vérification TLS du moteur activée plutôt que de la désactiver pour faire disparaître une erreur, car un échec de vérification vous dit quelque chose sur le point de terminaison atteint.

Accordez ensuite au compte de base de données le minimum dont l’application a besoin, dans le schéma qu’elle utilise réellement. Ce travail est ennuyeux, il est auditable, et c’est la partie sur laquelle une revue d’incident posera des questions.

Vérifiez depuis l’environnement déployé

Testez depuis l’instance ou depuis une tâche s’exécutant avec le même groupe, le même sous-réseau et le même rôle. Quatre défaillances se ressemblent depuis un portable et se distinguent facilement depuis là : un nom qui ne se résout pas, une connexion qui expire, un échec de validation TLS et une connexion à la base de données refusée. Chacune pointe vers une frontière différente, et changer l’exposition de la base de données avant de savoir laquelle vous avez relève de la devinette.

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

Si la connexion réussit depuis l’instance et échoue depuis votre bureau, la route de l’application est bonne et c’est votre accès qu’il faut corriger. Si elle échoue des deux côtés, commencez par les contrôles de groupe et de route ci-dessus plutôt que par les identifiants. Cette seule comparaison évite la majeure partie de l’agitation que génèrent ces tickets.