Cloud SQL Auth Proxy ou route VPN directe vers la base de données
L'Auth Proxy et une route VPN directe résolvent deux moitiés différentes du même problème. Comparez d'abord l'autorisation du connecteur, les ports et la connexion à la base de données.
Il existe deux façons raisonnables d'atteindre une instance Cloud SQL privée depuis un ordinateur portable sur le VPN. L'une est une connexion directe à l'adresse privée de l'instance par la route que vous avez déjà. L'autre est le Cloud SQL Auth Proxy, qui écoute sur loopback et ouvre lui-même la connexion vers Cloud SQL. Ce ne sont pas tant des produits concurrents que deux réponses différentes à la question de savoir qui détient l'identifiant et qui détient la route. Un mauvais choix se manifeste généralement par une erreur d'autorisation qui se lit comme une erreur réseau.
Voici la comparaison que je mettrais devant une équipe, suivie des vérifications qui la tranchent réellement.
Deux chemins vers la même instance
Le chemin direct utilise la route private-services-access de votre réseau vers le VPC du projet. Votre client parle PostgreSQL à l'adresse privée de l'instance, et la connexion vit ou meurt selon le routage, les règles de pare-feu et les identifiants de la base.
Le chemin par le proxy utilise la même route mais ajoute un processus local. Le proxy s'authentifie auprès de l'API Google avec les identifiants par défaut de votre application, ouvre une connexion à l'instance via le connecteur et expose un port loopback que votre client traite comme PostgreSQL. Deux sauts deviennent trois, et celui du milieu porte l'autorisation IAM. La route VPN reste à votre charge, et le proxy ne la considère jamais comme un substitut à cette vérification.
Ce que chaque chemin autorise réellement
La distinction qui compte le plus est ce que chaque option peut autoriser pour vous :
| Question | Direct private IP | Auth Proxy |
|---|---|---|
| Who proves identity to the network | Your client, through the VPN and a database login | The proxy, through IAM to Google's API |
| IAM role needed for the connector | None | Cloud SQL Client or equivalent |
| Database user authentication | Always required | Still required unless IAM database authentication is enabled |
| Shape of the local leg | Client to instance | Client to loopback, proxy to instance |
La vérification IAM du proxy et la connexion à la base sont deux portes distinctes, et passer l'une n'ouvre pas l'autre. Une équipe qui active le proxy et suppose que le compte applicatif est désormais inutile passera un après-midi sur des échecs de mot de passe qui n'ont rien à voir avec le réseau.
Ports et routes, côte à côte
Le proxy a besoin de TCP 443 sortant pour l'API et de TCP 3307 pour la connexion à l'instance, tous deux décrits dans la présentation de l'Auth Proxy. Votre route VPN couvre le second ; le premier sort normalement par le chemin habituel.
Une connexion directe exige que le port PostgreSQL de l'instance soit joignable par la route privée, ce qui est une autre conversation de pare-feu. Si votre équipe réseau n'autorise que le 443 sortant depuis les sous-réseaux clients, le proxy convient sans changer de règle et le chemin direct non. Ce seul fait tranche le choix plus souvent que toute préférence architecturale.
Aucun des deux chemins n'exige que l'instance ait une adresse publique, et aucun ne justifie d'en ajouter une.
Là où le proxy n'aide pas
Le proxy ne répare pas une route manquante. Si la route private-services-access est absente, ou si le VPN ne la transporte pas, le connecteur échoue pendant que l'écouteur local reste là à écouter, et c'est la partie déroutante.
Il ne protège pas non plus le tronçon entre votre application et le proxy. Sur un portable, ce tronçon est en loopback et tout va bien. Si vous liez l'écouteur à une adresse wildcard pour qu'un collègue l'atteigne, vous avez construit une passerelle de base de données non authentifiée et vous l'avez appelée commodité. Gardez-le sur loopback et laissez le collègue obtenir son propre identifiant.
Et il ne rend pas Private Service Connect et private services access interchangeables. Une instance PSC a besoin de sa propre configuration DNS et de l'appel --psc plutôt que de la forme --private-ip.
Choisir, puis vérifier dans les deux cas
Choisissez le proxy quand vous voulez de l'IAM dans le chemin, des identifiants de courte durée et aucune modification du pare-feu entrant.
Choisissez la route directe quand un client pris en charge détient déjà de solides identifiants de base et que l'équipe réseau accepte d'ouvrir le port. Dans les deux cas, vérifiez avec une vraie requête plutôt qu'avec une connexion réussie : connectez-vous, exécutez une lecture sur une table connue et regardez ce que le serveur voit de votre session.
Après une reconnexion VPN, traitez un identifiant expiré, une route privée manquante et un refus de connexion à la base comme trois pannes différentes. Une seule est un problème réseau, et une seule devrait jamais conduire à modifier une règle de pare-feu.