Présentation de l'accès aux services privés dans Cloud SQL

Ce document explique comment l'accès aux services privés fournit une connectivité IP privée pour Cloud SQL. Il aborde l'allocation d'adresses IP, les considérations de réseau et de sécurité, ainsi que la connectivité multi-VPC.

L'accès aux services privés est mis en œuvre sous la forme d'une connexion d'appairage de réseaux VPC entre le réseau VPC et le réseau VPC du fournisseur de services où réside votre instance Cloud SQL. Cette connexion réseau privée permet aux instances de VM de votre réseau VPC de communiquer avec les Google Cloudservices auxquels vous accédez exclusivement à l'aide d'adresses IP privées avec votre instance Cloud SQL. Les instances de VM n'ont pas besoin d'accès Internet ni d'adresses IP externes pour accéder aux services disponibles via l'accès aux services privés.

Adresses IP

Pour utiliser l'accès aux services privés dans un réseau VPC, une ou plusieurs plages d'adresses IP doivent être disponibles pour le VPC (pour en savoir plus sur les adresses IP, consultez Adresses IP). Ces plages doivent être suffisamment grandes pour Cloud SQL et tous les autres Google Cloud services gérés que vous prévoyez d'utiliser. Cloud SQL et d'autres Google Cloud services nécessitent chacun des blocs IP dédiés à partir des plages allouées. La taille minimale de ces blocs est de 256 adresses (longueur de préfixe /24), bien que la taille recommandée soit de 65 536 adresses (longueur de préfixe /16).

Si vous souhaitez créer des instances dans plusieurs régions ou pour différents types de bases de données, vous devez disposer d'une plage d'adresses IP d'au moins /24 pour chaque région ou type de base de données. Cela inclut d'autres applications telles que Filestore ou Memorystore.

Lorsque vous configurez l'accès aux services privés, vous pouvez sélectionner une plage existante ou en allouer une nouvelle. Si vous laissez Google Cloud allouer la plage pour vous, comme décrit dans la section suivante, alors Google Cloud alloue une plage de longueur de préfixe /24 sous le nom default-ip-range.

Quand utiliser des plages CIDR distinctes

Étant donné que Cloud SQL utilise des plages CIDR /24 comme unité de plage IP, plusieurs conditions nécessitent des plages /24 distinctes.

  • Séparation régionale : si vous créez deux instances Cloud SQL dans deux régions distinctes, vous devez allouer au moins deux plages CIDR /24 distinctes. Chaque unité de plage IP ne peut être utilisée que pour les instances Cloud SQL d'une seule région.
  • Séparation forcée de l'architecture réseau: les instances que vous créez à l'aide de l'indicateur --enforce-new-sql-network-architecture (ou du champ d'API équivalent) ne peuvent pas partager la même unité de plage IP avec les instances du même projet qui utilisent l'ancienne architecture réseau. Les instances que vous créez avec la nouvelle architecture réseau nécessitent leurs propres plages /24 dédiées dans chaque région.

Exemple d'accès aux services privés

Dans cet exemple, le réseau VPC a alloué la plage d'adresses 10.240.0.0/16 aux Google Cloud services et a établi une connexion privée à l'aide de cette plage. Chaque Google Cloud service (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

Le schéma illustre les aspects suivants de la configuration d'accès aux services privés :

  • La connexion privée se voit attribuer la plage 10.240.0.0/16. Grâce à cette allocation, Google Cloud les services peuvent créer des sous-réseaux dans lesquels de nouvelles ressources sont provisionnées.
  • Du côté des Google Cloud services de la connexion privée, Google Cloud 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 Google Cloud service 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 (Classless Inter-Domain Routing) /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. Pour en savoir plus, consultez la documentation du service concerné.
  • 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 à destination de 10.240.0.2 sont acheminées vers la connexion privée via le réseau du producteur de services. Une fois la requête parvenue au réseau de services, celui-ci contient des routes qui dirigent la requête vers la ressource appropriée.
  • Le trafic entre les réseaux VPC transite en interne au sein du Google Cloud réseau, et non via l'Internet public.

Considérations de réseau

Cloud SQL alloue un sous-réseau /24 à partir de la plage d'adresses IP d'accès aux services privés pour chaque région. Par exemple, pour placer des instances MySQL 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.

Points à noter concernant la 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 Google Cloud Chiffrement et authentification du réseau virtuel.

Vous pouvez configurer le proxy d'authentification Cloud SQL pour qu'il se connecte à l'aide de l'accès aux services privés 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é multi-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 réseau 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 Connecter votre instance à plusieurs réseaux VPC.

Étape suivante