Présentation du processus de connexion

Cette page fournit un résumé des options de connexion à une instance Cloud SQL.

Présentation

Deux facteurs sont à prendre en compte lors de la connexion à une instance Cloud SQL :

  • Comment se connecter : chemin réseau à utiliser pour atteindre votre instance, soit une adresse IP externe accessible via Internet (publique), soit une adresse IP interne (privée) accessible uniquement via VPC.
  • Comment s'authentifier : connexions autorisées vous permettant de vous connecter à votre instance Cloud SQL.

Utilisez les informations ci-dessous pour identifier les options de connexion et d'authentification qui répondent le mieux à vos besoins.

Options de connexion

Adresse IP privée

Une adresse IP privée est une adresse IPv4 ou IPv6 accessible sur un cloud privé virtuel (VPC). Cette adresse vous permet de vous connecter à partir d'autres ressources ayant accès au VPC. Les connexions via une adresse IP privée offrent généralement une latence plus faible et des vecteurs d'attaque limités, car leur transit par Internet n'est pas nécessaire.

Les connexions à une instance Cloud SQL à l'aide d'une adresse IP privée sont automatiquement autorisées pour les plages d'adresses RFC 1918. De cette façon, tous les clients privés peuvent accéder à la base de données sans passer par le proxy. Les plages d'adresses non-RFC 1918 doivent être configurées en tant que réseaux autorisés.

Si vous le souhaitez, vous pouvez exiger que toutes les connexions utilisent le proxy Cloud SQL ou les certificats SSL autogérés.

Lorsque la connexion s'effectue à partir d'un client sur une ressource ayant accès à un réseau VPC, il est préférable d'utiliser une adresse IP privée. Pour en savoir plus sur les ressources pouvant utiliser une adresse IP privée, consultez la page Conditions requises pour utiliser une adresse IP privée. Pour obtenir des instructions sur l'ajout d'une adresse IP privée à votre instance, consultez la section Configurer la connectivité IP privée.

Adresse IP publique

Une adresse IP publique est une adresse IPv4 ou IPv6 accessible en externe sur l'Internet public. Cette adresse peut recevoir des connexions provenant d'appareils internes et externes au réseau Google, y compris depuis votre domicile ou votre bureau.

Pour sécuriser votre instance, les connexions à une instance Cloud SQL utilisant une adresse IP publique doivent être autorisées via le proxy Cloud SQL ou les certificats SSL autogérés.

Lorsque la connexion s'effectue à partir d'un client qui ne répond pas aux exigences d'un VPC, la connexion avec une adresse IP publique est préférable.

Pour savoir comment ajouter une adresse IP publique à votre instance, consultez la page Configurer la connectivité IP publique.

Options d'authentification

Proxy Cloud SQL

Le proxy Cloud SQL vous permet d'authentifier et de sécuriser vos connexions à l'aide des autorisations IAM (Identity and Access Management). Le proxy valide les connexions à l'aide des identifiants utilisateur ou du compte de service, et encapsule la connexion dans une couche SSL/TLS authentifiée pour une instance Cloud SQL. Pour en savoir plus sur le fonctionnement du proxy Cloud SQL, consultez la page À propos du proxy Cloud SQL.

L'utilisation du proxy Cloud SQL est recommandée pour l'authentification des connexions à une instance Cloud SQL, car il s'agit de la méthode la plus sécurisée.

Le proxy client est une bibliothèque Open Source distribuée en tant que binaire exécutable. Le proxy client agit comme serveur intermédiaire qui écoute les connexions entrantes, les encapsule dans la couche SSL/TLS, puis les transmet à une instance Cloud SQL.

En outre, il est possible pour certains langages d'utiliser une bibliothèque cliente. Vous pouvez utiliser ces bibliothèques directement à partir de l'environnement du langage. Elles fournissent la même authentification que le proxy, sans nécessiter de processus externe. Pour commencer, consultez les pages suivantes :

Certificats SSL/TLS autogérés

Au lieu d'utiliser le proxy Cloud SQL pour chiffrer vos connexions, il est possible de configurer des certificats SSL/TLS client/serveur spécifiques à une instance Cloud SQL. Ces certificats permettent à la fois de valider le client/serveur et de chiffrer les connexions entre eux.

Il est fortement recommandé d'utiliser des certificats SSL/TLS autogérés pour assurer le chiffrement lorsque vous n'utilisez pas le proxy Cloud SQL. À défaut, vos données sont transmises de manière non sécurisée, et peuvent être interceptées ou inspectées par un tiers.

Pour commencer à utiliser les certificats SSL/TLS autogérés, consultez la section Autoriser avec des certificats SSL/TLS.

Réseaux autorisés

À moins d'utiliser le proxy Cloud SQL, les connexions à l'adresse IP publique d'une instance ne sont autorisées que si elles proviennent d'un réseau autorisé. Les réseaux autorisés sont des adresses IP ou des plages spécifiées par l'utilisateur auxquelles il est possible de se connecter.

Pour commencer à utiliser les réseaux autorisés, consultez la page Autoriser avec des réseaux autorisés.

Dépannage

Cliquez sur les liens du tableau pour en savoir plus :

Pour ce problème... Le problème peut être... Essayez ce qui suit...
Erreurs Unauthorized to connect. Il peut y avoir de nombreuses causes premières. Consultez ces solutions possibles.
Échec d'association de réseau. L'API Service Networking API n'est pas activée dans le projet. Activez l'API Service Networking API dans le projet.
Remaining connection slots are reserved Le nombre maximal de connexions a été atteint. Augmentez la valeur de l'option max_connections.
Set Service Networking service account as servicenetworking.serviceAgent role on consumer project. Les autorisations réseau sur le compte de service sont manquantes ou incorrectes. Désactivez et réactivez l'API Service Networking.
error x509: certificate is not valid for any names, but wanted to match project-name:db-name. Problème connu : les appels de proxy Cloud SQL ne sont pas compatibles avec Go 1.15 pour le moment. En attendant, consultez cette discussion sur GitHub, qui inclut une solution de contournement.

Connexion annulée

Le message d'erreur Got an error reading communication packets ou Aborted connection xxx to db: DB_NAME s'affiche.

Cause possible

  • Instabilité du réseau.
  • Absence de réponse aux commandes keep-alive TCP (le client ou le serveur ne répond pas ou est peut-être surchargé).
  • La durée de vie de la connexion au moteur de base de données a été dépassée et le serveur met fin à la connexion.

Solutions possibles

Les applications doivent tolérer les défaillances du réseau et se baser sur les bonnes pratiques telles que le regroupement des connexions et les nouvelles tentatives. La plupart des regroupements de connexions interceptent ces erreurs lorsque cela est possible. Sinon, l'application doit réessayer ou échouer sans occasionner de blocage.

Pour effectuer de nouvelles tentatives de connexion, nous vous recommandons les techniques suivantes :

  1. Intervalle exponentiel entre les tentatives. Augmentez l'intervalle de temps entre chaque nouvelle tentative, de manière exponentielle.
  2. Ajoutez également un intervalle aléatoire.
La combinaison de ces techniques permet de réduire les limitations.


Connexion non autorisée

Le message d'erreur Unauthorized to connect s'affiche.

Cause possible

Il peut exister plusieurs causes, car l'autorisation se produit à plusieurs niveaux.

  • Au niveau de la base de données, il doit exister un utilisateur avec un mot de passe correspondant.
  • Au niveau du projet, l'utilisateur peut ne pas disposer des autorisations IAM appropriées.
  • Au niveau de Cloud SQL, la cause première peut dépendre de la façon dont vous vous connectez à votre instance. Si vous vous connectez directement à une instance via l'adresse IP publique, l'adresse IP source de la connexion doit se trouver dans le réseau autorisé de l'instance.

    La connectivité IP privée est autorisée par défaut, sauf si vous vous connectez à partir d'une adresse non-RFC 1918. Les adresses clientes non-RFC 1918 doivent être configurées en tant que réseaux autorisés.

    Par défaut, Cloud SQL n'apprend pas les routes de sous-réseau non-RFC 1918 à partir de votre VPC. Vous devez mettre à jour l'appairage de réseaux vers Cloud SQL pour exporter les routes non-RFC 1918. Exemple :

    gcloud compute networks peerings update cloudsql-sqlserver-googleapis-com --network=NETWORK --export-subnet-routes-with-public-ip --project=PROJECT
    

    Si vous vous connectez via le proxy Cloud SQL, assurez-vous d'avoir correctement configuré les autorisations IAM.

  • Au niveau du réseau, si l'instance Cloud SQL utilise une adresse IP publique, l'adresse IP source de la connexion doit se trouver dans un réseau autorisé.

Solutions possibles

  • Vérifiez le nom d'utilisateur et le mot de passe.
  • Vérifiez les rôles et les autorisations IAM de l'utilisateur.
  • Si vous utilisez une adresse IP publique, assurez-vous que la source se trouve dans les réseaux autorisés.

Échec d'association de réseau

Le message d'erreur Error: Network association failed due to the following error s'affiche indiquant de définir le compte de service Service Networking en tant que rôle servicenetworking.serviceAgent sur le projet client.

Cause possible

L'API Service Networking API n'est pas activée dans le projet.

Solutions possibles

Activez l'API Service Networking API dans votre projet. Si cette erreur s'affiche lorsque vous tentez d'attribuer une adresse IP privée à une instance Cloud SQL et que vous utilisez un VPC partagé, vous devez également activer l'API Service Networking API pour le projet hôte.


Les emplacements de connexion restants sont réservés

Le message d'erreur FATAL: remaining connection slots are reserved for non-replication superuser connections s'affiche.

Cause possible

Le nombre maximal de connexions a été atteint.

Solutions possibles

Modifiez la valeur de l'option max_connections. Augmenter max_connections au-delà d'une certaine valeur entraîne la perte de l'assistance liée au contrat de niveau de service.


Définir le compte de service Service Networking en tant que rôle servicenetworking.serviceAgent sur le projet client

Le message d'erreur set Service Networking service account as servicenetworking.serviceAgent role on consumer project. s'affiche.

Cause possible

Les autorisations des utilisateurs ou des comptes de service sont incorrectes. Cela peut se produire lors de l'exécution de scripts de configuration automatique, tels qu'un script de configuration Terraform.

Solutions possibles

Pour réparer les autorisations de service, désactivez l'API Service Networking API, attendez cinq minutes, puis réactivez-la.


Erreur x509 : le certificat n'est valide pour aucun nom

Le message d'erreur error x509: certificate is not valid for any names, but wanted to match project-name:db-name s'affiche.

Cause possible

Problème connu : les appels de proxy Cloud SQL ne sont pas compatibles avec Go 1.15 pour le moment.

Solutions possibles

En attendant que le bug soit corrigé, consultez cette discussion sur GitHub, qui inclut une solution de contournement.


Étapes suivantes