En savoir plus sur l'utilisation des adresses IP privées

Cette page fournit des informations sur l'utilisation de la connectivité IP privée avec Cloud SQL. Pour obtenir des instructions détaillées sur la configuration d'une instance Cloud SQL en vue de l'utilisation d'une adresse IP privée, consultez la page Configurer une adresse IP privée.

Pour découvrir les solutions Terraform pour la mise en réseau Cloud SQL, consultez la page Solutions de mise en réseau simplifiées.

Présentation

La configuration d'une instance Cloud SQL pour qu'elle utilise une adresse IP privée nécessite un accès privé aux services. L'accès aux services privés vous permet de créer des connexions privées entre votre réseau VPC et le réseau VPC du producteur de services Google sous-jacent. Les entités Google qui offrent des services, tels que Cloud SQL, sont appelées producteurs de services. Chaque service Google crée un sous-réseau dans lequel le client peut provisionner des ressources. La plage d'adresses IP du sous-réseau est généralement un bloc CIDR de /24 choisi par le service et provenant de la plage d'adresses IP allouée.

Les connexions privées permettent d'accéder aux services sans passer par Internet ni utiliser d'adresses IP externes. Pour cette raison, l'adresse IP privée fournit une latence réseau inférieure à celle des adresses IP publiques.

L'accès aux services privés vous permet de vous connecter à des instances Cloud SQL :

Vous pouvez vous connecter via une adresse IP privée entre différentes régions. Vous pouvez également vous connecter par le biais d'un VPC partagé entre des projets.

Plages d'adresses IP allouées

Pour utiliser des instances Cloud SQL dans un réseau VPC avec une adresse IP privée, vous devez allouer des plages d'adresses IP afin de configurer l'accès privé aux services pour ce VPC. Pour organiser vos instances Cloud SQL, vous pouvez allouer plusieurs plages d'adresses IP pour la connexion privée. Lorsque vous configurez une instance Cloud SQL pour une adresse IP privée, vous pouvez sélectionner le réseau VPC et la plage d'adresses IP allouée.

Taille de la plage allouée

Veuillez allouer des plages d'adresses IP suffisamment grandes pour Cloud SQL et les autres services gérés par Google que vous prévoyez d'utiliser. Chacun d'entre eux nécessiterait des blocs d'adresses IP dédiés des plages allouées. La taille minimale est un bloc unique de /24 (256 adresses), mais la taille recommandée est un bloc de /16 (65 536 adresses).

Lorsque vous allouez une plage d'adresses IP, vous devez prendre en compte le nombre d'instances que vous prévoyez de créer.

Masque de sous-réseau Adresses Instances Cloud SQL utilisables
/2425650
/23512100
/221 024200
/212 048400
/204 096800

Cloud SQL utilise des plages CIDR /24 comme unité de plage, et chaque unité ne peut être utilisée que pour les instances Cloud SQL d'une seule région. Par exemple, si vous créez deux instances Cloud SQL, mais pour deux régions différentes, vous devez disposer d'au moins deux plages CIDR /24.

En outre, si un projet a commencé à utiliser Cloud SQL avant le 1er avril 2021, les instances Postgres ne peuvent pas partager la même unité de plage avec des instances MySQL et SQL Server, et ont besoin de leurs propres instances dans chaque région. Les projets plus récents ne sont pas soumis à cette limitation.

Configurer l'accès aux services privés pour votre réseau

Lorsque vous configurez la connectivité IP privée pour la première fois sur un réseau VPC donné, vous devez effectuer une procédure ponctuelle afin de mettre en place l'accès aux services privés pour Cloud SQL.

Une fois que vous avez établi l'accès aux services privés, vous pouvez créer une instance Cloud SQL configurée pour utiliser une adresse IP privée, ou bien configurer une adresse IP privée pour une instance Cloud SQL existante. Pour obtenir des instructions détaillées, consultez la page Configurer une adresse IP privée.

Chaque fois que vous modifiez une connexion établie, vous devez également mettre à jour vpc-peerings.

Configuration requise pour les adresses IP privées

Pour utiliser des adresses IP privées, votre réseau et votre environnement d’application doivent répondre aux exigences décrites ci-après. En outre, la configuration initiale d'adresses IP privées nécessite certaines autorisations IAM spécifiques.

Exigences relatives à l'environnement d'application

  • Si vous vous connectez depuis GKE, vous devez en exécuter la version 1.8 ou une version ultérieure sur un cluster de VPC natif.

Exigences relatives à l'API et à IAM

  • Vous devez activer l'API Service Networking pour votre projet.

    • Si vous utilisez un réseau VPC partagé, vous devez également activer l'API Service Networking pour le projet hôte.

  • Pour gérer une connexion d'accès aux services privés, votre utilisateur doit disposer des autorisations IAM suivantes. Si l'utilisateur ne dispose pas des autorisations requises, vous pouvez obtenir des erreurs d'autorisations insuffisantes.
    • compute.networks.list
    • compute.addresses.create
    • compute.addresses.list
    • servicenetworking.services.addPeering

    Si vous utilisez un réseau VPC partagé, vous devez également ajouter le même utilisateur et attribuer les mêmes autorisations sur le projet hôte.

Exemple

Dans l'exemple suivant, le réseau VPC du client a alloué la plage d'adresses 10.240.0.0/16 aux services Google et a établi une connexion privée utilisant cette plage. Chaque service Google (par exemple, Cloud SQL) crée un sous-réseau à partir du bloc alloué pour provisionner de nouvelles ressources dans une région donnée, telles que des instances Cloud SQL.

Diagramme de configuration d'adresses IP privées

  • La connexion privée se voit attribuer la plage 10.240.0.0/16. À partir de cette allocation, les services Google peuvent créer des sous-réseaux où de nouvelles ressources sont provisionnées.
  • Du côté des services Google de la connexion privée, Google crée un projet pour le client. Le projet est isolé, ce qui signifie qu'il n'est partagé avec aucun autre client, et le client est facturé à hauteur des seules ressources qu'il fournit.
  • Chaque service Google crée un sous-réseau dans lequel le client peut provisionner des ressources. La plage d'adresses IP du sous-réseau est généralement un bloc CIDR de /24 choisi par le service et provenant de la plage d'adresses IP allouée. Vous ne pouvez pas modifier le sous-réseau du producteur de services. Un service provisionne de nouvelles ressources dans les sous-réseaux régionaux existants précédemment créés par ce service. Si un sous-réseau est saturé, le service crée un nouveau sous-réseau dans la même région.
  • Les instances de VM du réseau du client peuvent accéder aux ressources de service de n'importe quelle région si le service est compatible. Cependant, certains services peuvent ne pas être compatibles avec la communication interrégionale. Consultez la documentation du service concerné pour plus d'informations.
  • Les coûts du transfert de données sortantes pour le trafic interrégional, dans lequel une instance de VM communique avec des ressources situées dans une région différente, continuent de s'appliquer.
  • L'instance Cloud SQL se voit attribuer l'adresse IP 10.240.0.2. Dans le réseau VPC du client, les requêtes dont la destination est 10.240.0.2 sont acheminées vers la connexion privée via le réseau du producteur de services. Lorsque les requêtes ont atteint le réseau de service, celui-ci contient des routes qui les dirigent vers la ressource appropriée.
  • Le trafic entre les réseaux VPC circule en interne au sein du réseau de Google et non via l'Internet public.

Problèmes de réseau

Cloud SQL alloue un sous-réseau de taille /24 appartenant à la plage d'adresses IP d'accès aux services privés pour chaque région. Par exemple, pour placer des instances SQL Server dans deux régions, la plage d'adresses IP allouée doit contenir au moins deux sous-réseaux de taille /24.

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 manière, tous les clients privés peuvent accéder à la base de données sans passer par le proxy d'authentification Cloud SQL.

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.

Sécurité

Un certain niveau de chiffrement est fourni pour le trafic circulant via l'accès aux services privés. Pour en savoir plus, consultez la page Chiffrement et authentification du réseau virtuel de Google Cloud.

Vous pouvez configurer le proxy d'authentification Cloud SQL pour qu'il se connecte via une adresse IP privée et fournisse une authentification à l'aide d'identifiants IAM, ainsi qu'un chiffrement de bout en bout utilisant un certificat SSL/TLS en rotation.

Si vous gérez vous-même vos certificats SSL/TLS afin de répondre à des exigences de sécurité spécifiques, consultez les instructions fournies sur la page Configurer SSL/TLS.

La création d'un réseau VPC pour chaque instance avec une adresse IP privée offre une meilleure isolation du réseau plutôt que de placer toutes les instances dans le réseau VPC "par défaut".

Connectivité avec plusieurs VPC

Cloud SQL est compatible avec les adresses IP privées via l'accès aux services privés. Lorsque vous créez une instance Cloud SQL, Cloud SQL la crée dans son propre cloud privé virtuel (VPC), appelé VPC Cloud SQL. L'activation d'une adresse IP privée nécessite la configuration d'une connexion d'appairage entre le VPC Cloud SQL et votre réseau VPC. Cela permet aux ressources de votre réseau VPC d'accéder aux adresses IP internes de vos ressources Cloud SQL sur le réseau VPC Cloud SQL.

En utilisant l'appairage de réseaux VPC, Cloud SQL met en œuvre l'accès aux services privés en interne, ce qui permet aux adresses IP internes de se connecter à deux réseaux VPC, qu'ils appartiennent ou non au même projet ou à la même organisation. Cependant, comme l'appairage de réseaux VPC n'est pas transitif, il ne diffuse que des routes entre les deux VPC directement appairés. Si vous disposez d'un VPC supplémentaire, il ne pourra pas accéder à vos ressources Cloud SQL à l'aide de la connexion configurée avec votre VPC d'origine.

Pour contourner cette limitation et connecter votre instance Cloud SQL à plusieurs VPC à l'aide d'adresses IP privées, vous pouvez utiliser les options de connexion suivantes :

  • Se connecter à l'aide de routes annoncées personnalisées
  • Se connecter à l'aide d'un proxy intermédiaire (SOCKS5)
  • Se connecter à l'aide du proxy d'authentification Cloud SQL en tant que service

Pour en savoir plus sur la connexion de plusieurs VPC, consultez la section Connecter votre instance à plusieurs VPC.

Aide-mémoire des rubriques concernant les adresses IP privées

Si vous gérez des instances Cloud SQL utilisant des adresses IP privées, certaines des thématiques suivantes peuvent vous intéresser :

Sujet Discussion
Réseaux VPC partagés Vous pouvez créer des instances Cloud SQL dotées d'adresses IP privées dans un réseau VPC partagé. Cependant, vous ne pouvez pas attribuer à une instance Cloud SQL existante une adresse IP privée dans un réseau VPC partagé.
Régions Vous pouvez vous connecter via une adresse IP privée entre différentes régions.
Anciens réseaux Vous ne pouvez pas vous connecter à l'adresse IP privée d'une instance Cloud SQL depuis un ancien réseau. Les anciens réseaux ne sont pas compatibles avec l’appairage de réseaux VPC ni avec l’accès privé aux services.
Suppression d'une adresse IP privée Une fois que vous avez configuré une instance Cloud SQL pour qu'elle utilise une adresse IP privée, vous ne pouvez pas retirer la fonctionnalité d'adresse IP privée de cette instance.
Adresses IP publique et privée Vous pouvez utiliser à la fois une adresse IP publique et une adresse IP privée pour vous connecter à la même instance Cloud SQL. Ces deux méthodes de connexion ne sont pas incompatibles.
Instances Cloud SQL existantes Vous pouvez configurer une instance pour qu'elle utilise une adresse IP privée au moment de sa création. Vous pouvez également configurer une instance existante de sorte qu'elle utilise une adresse IP privée. Lorsque vous configurez une instance existante pour qu'elle utilise une adresse IP privée ou que vous modifiez le réseau auquel elle est connectée, l'instance redémarre, ce qui entraîne un temps d'arrêt de quelques minutes.
Adresses IP statiques Pour les adresses IP privées et publiques, l'adresse entrante de l'instance Cloud SQL est statique ; elle ne change pas. L'adresse sortante n'est pas toujours statique, sauf pour les adresses IP publiques sortantes des instances répliquées de serveurs externes, qui sont toujours statiques.
Instances répliquées Les instances dupliquées héritent du même état de connectivité IP privée que l'instance principale. Vous ne pouvez pas configurer une adresse IP privée directement sur une instance dupliquée. Si vous vous connectez à une instance dupliquée à l'aide d'une adresse IP privée, vous n'avez pas besoin de créer une connexion VPC privée supplémentaire pour l'instance dupliquée, car elle est héritée de l'instance principale.
Proxy d'authentification Cloud SQL Pour permettre la connexion à une instance Cloud SQL à l'aide d'une adresse IP privée, le proxy d'authentification Cloud SQL doit se trouver sur une ressource ayant accès au même réseau VPC que l'instance. Si les deux types d'adresses IP sont activés sur l'instance, le proxy d'authentification Cloud SQL utilise par défaut l'adresse IP publique. Pour vous assurer qu'elle utilise une adresse IP privée, vous devez transmettre l'option -ip_address_types=PRIVATE au proxy d'authentification Cloud SQL. En savoir plus
Accès au VPC sans serveur Pour vous connecter à partir d'une source sans serveur, telle que l'environnement standard App Engine, Cloud Run ou Cloud Functions, votre application ou fonction se connecte directement à votre instance via l'accès au VPC sans serveur, sans proxy d'authentification Cloud SQL.
Appairage de réseaux VPC Une connexion utilisant l'accès aux services privés repose sur l'appairage de réseaux VPC. Cependant, vous ne créez pas explicitement l'appairage de réseaux VPC, car celui-ci est interne à Google Cloud. Après avoir créé la connexion d'accès aux services privés, vous pouvez voir son appairage au réseau VPC sous-jacent sur la page Appairage de réseaux VPC de la console Google Cloud. Ne supprimez pas cet appairage, sauf si vous souhaitez supprimer la connexion privée.

Apprenez-en plus sur l'appairage de réseaux VPC.
VPC Service Controls VPC Service Controls améliore votre capacité à limiter le risque d'exfiltration des données. Cette solution vous permet de créer des périmètres autour de l'instance Cloud SQL. VPC Service Controls limite l'accès depuis l'extérieur aux ressources situées dans le périmètre. Seuls les clients et les ressources situés dans le périmètre peuvent interagir entre eux. Pour en savoir plus, consultez la page Présentation de VPC Service Controls. Consultez également les limites applicables à Cloud SQL lors de l'utilisation de VPC Service Controls. Pour utiliser VPC Service Controls avec Cloud SQL, consultez la page Configurer VPC Service Controls.
Appairage transitif Seuls les réseaux directement appairés peuvent communiquer. L'appairage transitif n'est pas compatible. En d'autres termes, si le réseau VPC N1 est appairé à N2 et N3, mais que N2 et N3 ne sont pas directement connectés, le réseau VPC N2 ne peut pas communiquer avec le réseau VPC N3 via l'appairage de réseaux VPC.

Les clients d'un projet donné peuvent se connecter aux instances Cloud SQL dans d'autres projets à l'aide des réseaux VPC partagés.
Déplacement d'instances Cloud SQL Les instances Cloud SQL ne peuvent être déplacées qu'entre des réseaux appartenant au projet dans lequel elles résident. Par ailleurs, il n'est pas possible de déplacer des instances Cloud SQL d'un projet à l'autre, ni entre des réseaux hébergés par des projets différents.

Étape suivante